Re: Sitegroup issue!

Jukka Zitting wrote:
> Hi,
> 
> Responding in here to Tarjei's comment about setsitegroup():
> 
> On 3/7/06, Tarjei Huse <tarjei-y/[email protected]> 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 = ...;
>     $object->update();
> 
> is that it is conceptually very much different from
> 
>     $object = ...;
>     $object->someproperty = ...;
>     $object->update();
> 
> 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
> question.
> 
> 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 
links?

> 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
> account.

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 
implement it.

Tarjei



> BR,
> 
> Jukka Zitting
> 
> --
> Yukatan - http://yukatan.fi/ - [email protected]
> Software craftsmanship, JCR consulting, and Java development