Well, you can always write your own tasks for more complicated cases;
the default provided tasks can't cover all possible use-cases;) See
the other magnolia modules for some examples.
Regarding your issue, all operations *should* happen in the same jcr
session, so you shouldn't have visibility issues. (the idea being
that we'll only save once all tasks for a given module have been
successfully executed)
Cheers
g
On Oct 30, 2007, at 10:07 , Anthony Ogier wrote:
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
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------
