cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: [RT] was: [PROPOSAL] mulitple actions per class
Date Fri, 15 Feb 2002 08:24:07 GMT
On 14.Feb.2002 -- 01:20 PM, Torsten Curdt wrote:
> On Thu, 14 Feb 2002, Christian Haul 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
> > > > parameter. E.g.: /customer/add, /customer/update, etc. This can be used
> > > > 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).
> You must have gotten something wrong. Noone wants to abandone the
> action-sets :)

Well, I wouldn't mind ;-)

> > 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.
> Although what you are talking about seems to be useful, too. This doesn't
> solve the problems I am talking about. Especially think of the i18n
> problem I was talking about...

I should have been more verbose on it. The i18n issue stems from the
fact, that -- when using an action set -- currently the only way to
distinguish which submit button was pressed is by matching on the
visual label of that button. Every other necessary information (for
all possible cases) could be stored in hidden fields.

But what if you could chose the action according to the presence of a
request parameter? Suddenly the visual label does not matter at all,
but the name of the submit button. There's an example in the
scratchpad section (webapp/mount/mod-db) that uses that technique.
(Not a good example as that uses an action to decide which action to

Having arbitrary rules to select the action in a set would even allow
to depend it on additional information like previous page (request
header, referer) or specific values in the request parameters. Well,
you could even ask an external entity for advice if you write such a

And if we allow to have arbitrary code in an action-set, there's no
reason (I can think of, at least) to limit it to action-sets.

> Indeed this would be cool. Right now we are using XML entities for that.
> Auuuah - ugly ;)

See? I once suggested to be able to apply logicsheets to sitemaps but
(I think) Stefano objected the reason being people will lose the
ability to understand the original, fundamental sitemap language but
only use some high level abstraction syntax.

Personally, I disagree and would like to see that. At least there
would not be a need for using XML entities or action-sets.


C h r i s t i a n       H a u l
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

To unsubscribe, e-mail:
For additional commands, email:

View raw message