Jukka Zitting wrote:
> Responding in here to Tarjei's comment about setsitegroup():
> On 3/7/06, Tarjei Huse <email@example.com...> wrote:
>> Torben Nehmer wrote:
>>> The short version: API consistency and Ease of Use.
>> I agree with torben. For the same reason, I would also like to have the
>> simple object->sitegroup usage instead of todays setsitegroup().
> The problem with
> $object = ...;
> $object->sitegroup = ...;
> is that it is conceptually very much different from
> $object = ...;
> $object->someproperty = ...;
> Normal property updates are simple to handle because they only affect
> the object in question. The sitegroup change however affects not only
> the object in question but also all parameters, attachments, child
> objects, and any objects that have a link to or from the object in
> If we limit the update() method to just change the sitegroup of a
> single object, then we essentially allow update() to break database
> consistency. But if we allow update() to cascade the sitegroup change,
> the method becomes much more complex than before. Such use also makes
> update() access controls more complex as they'd then need to take the
> sitegroup administration rights into account as well. The sitegroup
> property (or in fact any of the metadata properties) does *not* behave
> like a normal property.
Isn't this something you can say for most update operations that work on
> To summarize, such a sitegroup update feature might be easy to use but
> it certainly wouldn't help API consistency. Just imagine writing a
> test case or API document that takes all the special cases (e.g.
> should a parent link be cleared when changing the sitegroup!) into
I can see your point.
Is it possible for php to define some properties as read only - so that
you at least can get a notice when trying to set the sitegroup?
Also, the most important thing now is to decide on one method and