>
> <snip/>
>
> > > The /[parameter] could be optional and be translated into an action
> > > parameter named "cocoon-action-parameter". What do you think?
> >
> > Yes, this is a way to solve this, but why not simply use something like
an
> > ActionSelector, which can be used to extract request params in any way
you
> > like and expose them to sitemap. E.g.:
> >
> > <map:act name="ActionSelector">
> >     <map:action-set name="my-actions">
> >         <map:parameter name="method" value="{method-name}" />
> >     </map:action-set>
> > </map:act>
> >
> > See my previous mail about conditional action-sets.
>
> Well, of course you *can* solve even the i18n problem with this ... by
> translating the values back .... but that would be damn ugly!
>

A little bit nicer version (previsous is a little incorrect):

<map:match pattern="/formaction"
    <map:act set="my-actions">
        <map:parameter name="method" value="parameter('method-name')" />
    </map:action-set>
    ...
</map:match>

So, there is no need in an additional selector action. I've seen somewhere
this syntax: parameter(param_name). Anybody know is it supported now? The
same way could be 'session()', 'header()' and 'cookie()' used.


> Sure once the i18n thing is solved (I guess) the parameter stuff could be
> solved by the following action-set (not sure!)
>
> <action-set name="myActions">
>   <action type="multiaction" action="add">
>     <parameter name="method" value="add"/>
>   </action>
>   <action type="multiaction" action="delete">
>     <parameter name="method" value="delete"/>
>   </action>
> </action-set>
>
> But providing an optional parameter with the new cocoon-action syntax can
> make this less verbose and maybe is useful for other stuff as well...
> ...don't blame it on the FS - altough I tend to have it:)
>
> > > ...with the URL method... yes, this should work. But I had to
restructure
> > > all our sitemaps :(
> >
> > You should do it anyway if you extend sitemap syntax.
>
> uahh *snief* I know :(
>
> ...but let it be for good reason then :)

So, let's see what is the others good reasons ;)

Speaking frankly, I don't use Cocoon anymore in my projects and one of the
reasons was it's poor action handling (there were also other political
reasons, though). Hope someday I'll be back to Cocoon again, that's why I'm
here.

Konstantin

> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to