cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piroumian, Konstantin" <KPiroum...@flagship.ru>
Subject Re: [RT] was: [PROPOSAL] mulitple actions per class
Date Thu, 14 Feb 2002 12:18:50 GMT
> 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?

>
> > > So, why not to have a AbstractMultiAction class that will get method
name as
> > > a parameter? And all the descendant actions will only extend it will
the
> > > acting methods. What about this?
> >
> > ...with the URL method... yes, this should work. But I had to
restructure
> > all our sitemaps :(
>
> IMHO such a multi-action does not need to be supported by the
> sitemap. We have the ability to pass arbitrary parameters to an
> action. An action is able to dispatch arbitrary methods. The problem
> lies in the restricted flexibility of action-sets.
>
> Thus I propose to have
>
>   <map:pipeline-fragments>
>      <map:pipeline-fragment name="action-set-foo">
>          <!-- anything that is allowed to be in a pipeline -->
>      </map:pipeline-fragment>
>      <!-- more fragments -->
>   </map:pipeline-fragments>
>
> with
>
>   <map:match ....>
>       <!-- ... -->
>       <map:use-fragment name="action-set-foo"/>
>       <!-- ... -->
>   </map:match>
>
> and (in sitemap.xsl):
>
>   <xsl:apply-template
select="/map:sitemap/map:pipeline-fragments/map:pipeline-fragment[name="@nam
e"]/>
>
> Don't know sitemap.xsl good enough by heart whether this would suffice.
>
> 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?

>
> Chris.
>
> --
> C h r i s t i a n       H a u l
> haul@informatik.tu-darmstadt.de
>     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message