Jukka Zitting wrote:
> Hi,
>
> Responding in here to Tarjei's comment about setsitegroup():
>
> On 3/7/06, Tarjei Huse <
tarjei@nu.n...> 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/ -
info@yuka...
> Software craftsmanship, JCR consulting, and Java development
---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@midg...
For additional commands, e-mail:
dev-help@midg...
opensubscriber is not affiliated with the authors of this message nor responsible for its content.