On 14.Feb.2002 -- 03:18 PM, Piroumian, Konstantin wrote:
> > On 14.Feb.2002 -- 12:17 PM, Torsten Curdt wrote:
> > > On Thu, 14 Feb 2002, Piroumian, Konstantin wrote:
> > > >
> > > > 1) URL token: '/customer/*' -> action/method will be selected with {1}
> > > > parameter. E.g.: /customer/add, /customer/update, etc. This can be
> used in
> > > > links or 'action' attribute of HTML form.
> >
> > I agree that actions-sets do have some shortcomings. But I would
> > argue that they should be abandoned instead of tinkered with. Instead,
> > a macro like system would be more useful: something like a resource
> > but that does _return_ (OK, you *could* use XML entities for that).
> >
> > It would give you any flexibility you want and wouldn't be limited to
> > actions-sets. For those, you could use any selector that uses whatever
> > scheme you would like to use.
> >
> > I am quite sure that having that ability would solve many if not all
> > problems that you are facing.
>
> Did I understand right, that you propose to use selectors inside of action
> sets? (Sorry, English is not my native language). Currently, it's possible
> to use a selector to choose the action-set to be used, but is it possible to
> use a selector inside of an action set? How can it look like?
Well, yes. But I would favour using this for more than actions. OK, to
use standardized transformations to documents is well catered for by
resources, so I'm having difficulties coming up with an example to use
this that does not involve actions.
My vision is to allow arbitrary code in such a fragment i.e. matchers,
selectors and actions. Thus the usage pattern would be exactly like
using e.g. a selector in a main pipeline to select different actions.
<map:fragment name="database-interaction">
<map:select type="request">
<map:when test="insert">
<map:act type="db-all-in-one">
<map:parameter name="do" value="add"/>
</map:act>
</map:when>
<map:when test="delete">
<map:act type="db-all-in-one">
<map:parameter name="do" value="del"/>
</map:act>
</map:when>
<!-- ... -->
</map:select>
</map:fragment>
<map:pipeline>
<map:match pattern="user-details">
<map:use-fragment name="database-interaction"/>
<map:generate src="{0}"/>
<map:call-resource name="deliver-dynamic-page"/>
</map:match>
</map:pipeline>
> > There's one shortcoming, though. Today, it is possible for action-sets
> > to have nested elements whose execution is conditional. It appears
> > difficult to have this with my suggestion. I'm not sure whether people
> > use that feature, though.
> For conditional actions it'd be fine to have something like named templated
> in XSL, e.g.:
>
> <map:action-set name="action-set-foo">
> <map:parameter name="user-role">guest</map:parameter>
> <map:act type="MyAction" />
> <map:if test="user-role = 'admin'">
> <map:act type="CoolAction" />
> </map:if>
> </map:action-set>
>
> So, you can use this action set with runtime params in any place you need
> it.
> What about this?
OK, like having a default value and being able to overide it when
calling. Perhaps having this parameter replace the role of the
"cocoon-action" request parameter. But this way the logic to determine
the parameter is still distributed over all pipelines. I think having
this logic in a single place would be more desirable.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
