I would just like to add another use case : a module now have a new
implementation of a handler, and we want that handler to be the default one.
We want also that this handler passes its responsability on the former
implementation (perhaps user-defined) if it knows the request doesn't
contain the parameter(s) it needs.
A way to do that is to create a node with the new class at the same
place of the former class declaration, and to move the former one to
make it as a child of the new one... I didn't find the tasks required to
do that... what do you think of that use case ?
Actually, I tried with a MoveNodeTask to rename the old one, chained
with an AddNodeTask for the new one, and a last MoveNodeTask to make the
old one the child of the new one. But I had a problem because the
HierarchyManager wasn't saved between the AddNodeTask and the last
MoveNodeTask, so that one couldn't see the node renamed by the first
MoveNodeTask ...
Anthony
Grégory Joseph a écrit :
On Oct 29, 2007, at 21:50 , Fabrizio Giustina wrote:
On 10/29/07, Grégory Joseph <[email protected]> wrote:
Fabrizio, doesn't this duplicate NewPropertyTask and/or
CheckOrCreatePropertyTask ?
NewPropertyTask only creates a new property and
CheckOrCreatePropertyTask expect to modify a known previous value.
None of them can be used to simply set a (maybe not existing)
property to a defined value. So no, it doesn't actually duplicate any
of them...
I know I'm picky but I like to understand: my uses cases were, until
now: either you're 1) installing or updating a module which has new
features, thus new configuration properties: you would then add a new
unexisting property 2) updating a module where the configuration
layout or syntax has changed, and you would then modify a property,
but making sure, for instance, that it has the default value, to avoid
overriding a user's customization. (The idea being generally to avoid
losing non-default values that users might have changed)
I assume you'd find using the conditional tasks delegator a bit too
verbose ? ;) I'm just concerned that with tasks like these (i.e where
care is not taken about existing potential customizations), we'll see
bad practices pop up; by restricting the api to safer behaviors, we're
probably going down a safer road, avoiding silly mistakes. Now I'm
also starting to be concerned by the growing number of existing tasks
- we should probably review some of them: renaming and repackaging
might also help giving more clarity.
wdyt ?
g
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------
