You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Torsten Curdt <tc...@dff.st> on 2002/02/12 14:34:26 UTC
[PROPOSAL] mulitple actions per class
While working with actions something bugs me more and more... For each
very simple action you need to have a new class. Although it might be just
a few lines for each, it becomes really ugly when you share code with
other actions or need to call an action from an action. Plus having
thousand of action class for a single webapp. Sure this all possible and
one can say: then use helper classes that hold all the shared code. But
well - possible does not mean confortable.
IIRC with Turbine e.g. it is way more confortable. They use
"methods as actions":
class SomeActions {
public void doMyAction(..) {
...
(I'm not quite sure about the arguments and stuff though)
This helps to have all related code at a glance.
Although I'm not yet sure what syntax should be prefered
1. <map:action type="SomeActions.doMyAction">
<!-- directly use the method -->
2. <map:action type="SomeActions.MyAction">
<!-- have a fix prefix like "do" -->
3. <map:action type="SomeActions" method="doMyAction">
4. <map:action type="SomeActions" method="MyAction">
Of course this will require the use of the reflection API
for those actions using the new method syntax. (All others
will not be effected and treated as usual)
I have made some tests: if we use some intelligent
caching for the reflection API there will be only little
to no performance loss compared to the old mechanism.
What do guys think?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] mulitple actions per class
Posted by Torsten Curdt <tc...@dff.st>.
On Tue, 12 Feb 2002, Nicola Ken Barozzi wrote:
>
> > Although I'm not yet sure what syntax should be prefered
> >
> > 1. <map:action type="SomeActions.doMyAction">
> > <!-- directly use the method -->
> >
> > 2. <map:action type="SomeActions.MyAction">
> > <!-- have a fix prefix like "do" -->
> >
> > 3. <map:action type="SomeActions" method="doMyAction">
> >
> > 4. <map:action type="SomeActions" method="MyAction">
> >
> > Of course this will require the use of the reflection API
> > for those actions using the new method syntax. (All others
> > will not be effected and treated as usual)
>
> You can also use inner classes.
I have been thinking about this, too
There are quite some ways to do this... but as I said:
will this be confortable?
> > I have made some tests: if we use some intelligent
> > caching for the reflection API there will be only little
> > to no performance loss compared to the old mechanism.
>
> Jdk 1.4 has way higher performance in using reflection.
Cool.
> IMHO a ClassMethodAction, with class name and methos name as parameters,
> would suffice.
...but how to use the "cocoon-action" parameter then?
If you have a form with multiple input buttons with action
bound to them you only have a single parameter:
<form>
<input type="submit" name="cocoon-action" value="update">
<input type="submit" name="cocoon-action" value="delete">
<input type="submit" name="cocoon-action" value="add">
</form>
To change a hidden input field with javascript is not an option.
So the information which mehtod to be called must be encoded inside the
value which is currently the name of the action.
That's why I came up with something like this
<form>
<input type="submit" name="cocoon-action" value="usermanager.update">
<input type="submit" name="cocoon-action" value="usermanager.delete">
<input type="submit" name="cocoon-action" value="usermanager.add">
</form>
Unfortunately I think this must be handled from Cocoon and just an
ClassMethodAction will not be enough
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] mulitple actions per class
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Torsten Curdt" <tc...@dff.st>
To: <co...@xml.apache.org>
Sent: Tuesday, February 12, 2002 2:34 PM
Subject: [PROPOSAL] mulitple actions per class
> Although I'm not yet sure what syntax should be prefered
>
> 1. <map:action type="SomeActions.doMyAction">
> <!-- directly use the method -->
>
> 2. <map:action type="SomeActions.MyAction">
> <!-- have a fix prefix like "do" -->
>
> 3. <map:action type="SomeActions" method="doMyAction">
>
> 4. <map:action type="SomeActions" method="MyAction">
>
> Of course this will require the use of the reflection API
> for those actions using the new method syntax. (All others
> will not be effected and treated as usual)
You can also use inner classes.
> I have made some tests: if we use some intelligent
> caching for the reflection API there will be only little
> to no performance loss compared to the old mechanism.
Jdk 1.4 has way higher performance in using reflection.
IMHO a ClassMethodAction, with class name and methos name as parameters,
would suffice.
--
Nicola Ken Barozzi krysalis.org@nicolaken.com
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] mulitple actions per class
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> While working with actions something bugs me more and more... For each
> very simple action you need to have a new class. Although it might be just
> a few lines for each, it becomes really ugly when you share code with
> other actions or need to call an action from an action. Plus having
> thousand of action class for a single webapp. Sure this all possible and
> one can say: then use helper classes that hold all the shared code. But
> well - possible does not mean confortable.
Another possibility is to use a request or sitemap parameter with an
aggregated Action, e.g.:
<map:match="cart/*">
<map:act name="CartAction">
<map:parameter name="action" value="{0}" />
</map:act>
</map:match>
So, for requests like: 'cart/add', 'cart/remove', 'cart/update' you can use
a single action that performs something like:
act(...) {
if (ADD_ACTION.equals(actionName) {
// do addition
} else {
...
}
// etc.
}
>
> IIRC with Turbine e.g. it is way more confortable. They use
> "methods as actions":
>
> class SomeActions {
>
> public void doMyAction(..) {
> ...
>
> (I'm not quite sure about the arguments and stuff though)
> This helps to have all related code at a glance.
> Although I'm not yet sure what syntax should be prefered
>
> 1. <map:action type="SomeActions.doMyAction">
> <!-- directly use the method -->
>
> 2. <map:action type="SomeActions.MyAction">
> <!-- have a fix prefix like "do" -->
>
> 3. <map:action type="SomeActions" method="doMyAction">
>
> 4. <map:action type="SomeActions" method="MyAction">
I would use a substitution param for setting the 'method' value. You can
select the action to be performed based on request path, request parameter,
maybe even another action. E.g. depending on the time of day or the day of
week you can perform the action in a different way and another action will
define what method to perform.
>
> Of course this will require the use of the reflection API
> for those actions using the new method syntax. (All others
> will not be effected and treated as usual)
>
> I have made some tests: if we use some intelligent
> caching for the reflection API there will be only little
> to no performance loss compared to the old mechanism.
>
> What do guys think?
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] mulitple actions per class
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 12.Feb.2002 -- 02:34 PM, Torsten Curdt wrote:
> While working with actions something bugs me more and more... For each
> very simple action you need to have a new class. Although it might be just
> a few lines for each, it becomes really ugly when you share code with
> other actions or need to call an action from an action. Plus having
> thousand of action class for a single webapp. Sure this all possible and
> one can say: then use helper classes that hold all the shared code. But
> well - possible does not mean confortable.
>
> IIRC with Turbine e.g. it is way more confortable. They use
> "methods as actions":
>
> class SomeActions {
>
> public void doMyAction(..) {
> ...
>
> (I'm not quite sure about the arguments and stuff though)
> This helps to have all related code at a glance.
> Although I'm not yet sure what syntax should be prefered
>
> 1. <map:action type="SomeActions.doMyAction">
> <!-- directly use the method -->
>
> 2. <map:action type="SomeActions.MyAction">
> <!-- have a fix prefix like "do" -->
>
> 3. <map:action type="SomeActions" method="doMyAction">
>
> 4. <map:action type="SomeActions" method="MyAction">
>
5. <map:act type="SomeAction>
<map:parameter name="do" value="MyAction"/>
</map:action>
Which is currently possible. Afterall, no one prevents you from
dispatching different methods from your act method. It might be nice
to have a sample implementation, though.
You could even have an default value for @do and define several
actions...
This has two short comings:
a) syntax is too verbose
b) when creating multiple "aliases" for an action with different
default values for @do it would result in seperate instance of that
class while Torsten's proposal would share the same
instance. (Hence the term "alias" is not correct!)
IMHO it would be cool to have a simple syntax for handing *exactly
one* parameter to any component without the need to nest a
<map:parameter/> element.
But then, the sitemap is probably going to be edited with a tool
anyway. Plus the syntax as is is clear and changes would need to
achieve the same clarity.
Just my 2¢
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
Re: AW: [OT] who reads documentation
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Matthew Langham wrote:
>In that sense, the integration of Lucene in Cocooon 2.0.1 is certainly
>a Good Thing - IMHO what you want to give to your users is a searchable
>website of your docs, that lives and grows as you expand the system
>being built.
><<
>
>Documentation On Demand :-). See:
>http://www.need-a-cake.com/2002/02/13.html#a47
>
>Ok - enough of that. Back to work
>
We use nearly similar things in our products : when an error occurs for
which there are some known causes, a special exception is thrown that
contains detailed informations on what occured and how to solve the
problem. It is then neatly formatted on the screen in replacement of the
standard exception page. Users like it !
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [OT] who reads documentation
Posted by Matthew Langham <ml...@s-und-n.de>.
>>
In that sense, the integration of Lucene in Cocooon 2.0.1 is certainly
a Good Thing - IMHO what you want to give to your users is a searchable
website of your docs, that lives and grows as you expand the system
being built.
<<
Documentation On Demand :-). See:
http://www.need-a-cake.com/2002/02/13.html#a47
Ok - enough of that. Back to work.
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
Weblogging at: http://www.need-a-cake.com
=================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [OT] who reads documentation / Lucene (Was:[PROPOSAL] mulitple actions per class)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Wednesday 13 February 2002 14:58, Matthew Langham wrote:
>. . .
> We wrote quite a bit of documentation to go with the work we do - all
> nicely done in XML and then generated into HTML or PDF - using Cocoon
> (of course).
>
> BUT NO ONE READS IT! That's the sad truth (and probably the same
> everywhere).
>. . .
I think people are getting used to "googling" through docs: search a
few keywords and get a list of documents.
In that sense, the integration of Lucene in Cocooon 2.0.1 is certainly
a Good Thing - IMHO what you want to give to your users is a searchable
website of your docs, that lives and grows as you expand the system
being built.
- Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [PROPOSAL] mulitple actions per class
Posted by Matthew Langham <ml...@s-und-n.de>.
You know...
>>
> which contains everything, but I personally would like to directly see it
in
> the sitemap as a requirement. documentation is the part of a project where
> never anyone has time for.
I know...*sigh* good for us at least the basic javadocs are generated
automagically :)
<<
Quite OT - but we have found the following:
We wrote quite a bit of documentation to go with the work we do - all nicely
done in XML and then generated into HTML or PDF - using Cocoon (of course).
BUT NO ONE READS IT! That's the sad truth (and probably the same
everywhere).
If you have no documentation - everyone complains
If you have documentation - no one reads it
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
Weblogging at: http://www.need-a-cake.com
=================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] mulitple actions per class
Posted by Torsten Curdt <tc...@dff.st>.
> > <snip>
> >
> > :) ...no, I meant the syntax only - as you have given your +1 for use in
> > the action-sets. (BTW: I'd prefer the "action.method" syntax)
> >
> Ah, ok. I think the additional method attribute is more painless. I'm not
> sure, but I think I can currently define an action named "hello.you" which
> with your syntax would be handled as a multiaction.
Makes sense!
> > > If I have a chance to see by looking into the sitemap which methods the
> > > multiaction exposes (or which values are valid for the method attribute)
> > > then I will change this to +0.
> >
> > But this means that you once define what is available inside the java code
> > and need to mirror this inside the sitemap. This is more work than
> > necessary and one of idoms of the sitemap was: (quoting Stefano from the
> > docs) "minimal verbosity is of maximum importance" If someone is writing
> > an webapp he should know about the classes he is using! If not - he could
> > easily look this up in the javadocs. Actually I see this verbosity more as
> > burden than helping.
> >
> > I guess it really depends on how the team is organized. Who is using
> > these multiactions? And what goes in there? Actually I think these actions
> > are different from the general purpose action that come with cocoon. They
> > can be used to bind a java mehod directly to button on a web page.
> > This becomes even more interesting if we also could use JavaScriptActions
> > this way.
> >
> Ok, you're right that it depends on how the team is organized. I'm always
> thinking of SoC, so one team writing java components and another team
> "writing" the webapp by using the provided components. This second team
> has no knowledge of Java and they don't know how to look into JavaDocs etc.
> Now, it is of course possible to hand them documentation about the
> multiaction
I hear you. SoC are important but I'm wondering: isn't it a bit over
separating and hindering if you always have to ask for the specific
actions and wait for the java team to write them?At least for us here
there are no such clear distinc groups to separate...
Lets say they need action that is supposed to check a request value if
lesser than, greater than or equal 0. This what we call flow actions. They
are really REALLY simple and a component for such simple flow decisions
doesn't make much sense. (That's why I came up with this idea;)
> which contains everything, but I personally would like to directly see it in
> the sitemap as a requirement. documentation is the part of a project where
> never anyone has time for.
I know...*sigh* good for us at least the basic javadocs are generated
automagically :)
> > Of course having this inside action-sets is better than nothing...
> > ...so if noone objects I'd like to implement at least this new feature.
>
> +1 (for action-sets)
ok :)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by Stefano Mazzocchi <st...@apache.org>.
Christian Haul wrote:
> > 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.
Please, people, consider what Ovidiu is doing on Schecoon and consider
the fact that if we get anymore 'flow logic' into the sitemap, we'll
have to support it forever (or at least, for years to come) while we
might well, one day, have the ability to have the sitemap include
description of the pipelines and resources and the flowmap the 'flow
logic' behind them (and possibly, deprecate the 'action' concept in the
sitemap).
I'm not saying that the sitemap is good for handling webapp flow logic,
actually I'm even more critical than you all on that (I still don't like
the action concept, even if I see its current usefulness).
But, please, *PLEASE*, don't add things now that we might need to
deprecate in 6 months.
Ovidiu, do you have any comment on this?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] was: [PROPOSAL] mulitple actions per class
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
>
> On 14.Feb.2002 -- 01:20 PM, Torsten Curdt wrote:
> > On Thu, 14 Feb 2002, Christian Haul wrote:
<snip/>
> > 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
Hm. The code is there. I did not come up with the logicsheet to test
this, though...
> (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.
It is there, and was there. Try it, might work.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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 {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).
>
> 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
execute.)
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
selector.
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.
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
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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
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
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> 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
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 14.Feb.2002 -- 04:27 PM, Torsten Curdt wrote:
> On Thu, 14 Feb 2002, Vadim Gritsenko wrote:
> > > From: Torsten Curdt [mailto:tcurdt@dff.st]
> >
> > <snip/>
> >
> > > > 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>
> > >
> > > Indeed this would be cool. Right now we are using XML entities for
> > that.
> > > Auuuah - ugly ;)
> >
> > To me this looks very familiar... It reminds me of resources. Shouldn't
> > be then resources tinkered with instead of adding the whole new concept
> > of fragments?
>
> True!
Indeed, both are very similar. My reasoning was that it is easier to
introduce something new than to change behaviour in an unexpected
way. If resources suddenly do return how many sitemaps would be
broken? If a return element is introduced, would it be more irritating
and more difficult to implement? I'm not sure about this.
Besides "resource" describes the current design very good. A resource
is something complete, a new destination. A fragment, however,
explicitly says "I'm incomplete".
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
RE: [RT] was: [PROPOSAL] mulitple actions per class
Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 14 Feb 2002, Vadim Gritsenko wrote:
> > From: Torsten Curdt [mailto:tcurdt@dff.st]
>
> <snip/>
>
> > > 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>
> >
> > Indeed this would be cool. Right now we are using XML entities for
> that.
> > Auuuah - ugly ;)
>
> To me this looks very familiar... It reminds me of resources. Shouldn't
> be then resources tinkered with instead of adding the whole new concept
> of fragments?
True!
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] was: [PROPOSAL] mulitple actions per class
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Torsten Curdt [mailto:tcurdt@dff.st]
<snip/>
> > 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>
>
> Indeed this would be cool. Right now we are using XML entities for
that.
> Auuuah - ugly ;)
To me this looks very familiar... It reminds me of resources. Shouldn't
be then resources tinkered with instead of adding the whole new concept
of fragments?
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by Torsten Curdt <tc...@dff.st>.
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 {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).
You must have gotten something wrong. Noone wants to abandone the
action-sets :)
> 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...
> > > 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.
yes... with my last proposed idea the sitemap will not explicitly
support the multi-action but give another intelligent method that will
make our life's easier. ...and it will remove the i18n sitemap
dependency!!
> 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>
Indeed this would be cool. Right now we are using XML entities for that.
Auuuah - ugly ;)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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.
> > 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="@name"]/>
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.
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
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by Torsten Curdt <tc...@dff.st>.
> > 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.
...guess we are loosing quite a couple of users because of that!
I also was tempted to look for something else...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
>
> <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: 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
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by Torsten Curdt <tc...@dff.st>.
<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!
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 :)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> On Thu, 14 Feb 2002, Piroumian, Konstantin wrote:
>
> > Hi!
> >
> > Btw, there were a discussion on a topic related to action selection
based
> > not only 'cocoon-action' attribute value, but in many other ways, e.g.
one
> > can select an action/method to execute based on:
> >
> > 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.
>
> Hm... I should play around with this one...
>
> > 2) Request param value (current implementation):
> > /customer?cocoon-action=Add - this has disadvantages, see below.
> >
> > 3) Request param presence: /customer?addBtn=Add: in this case checked
the
> > param name, not the value, so you can have multiple submit buttons on
the
> > screen: <input name="addBtn" value="Add" />, <input name="updateBtn"
> > value="Update" />
> >
> > 4) Any other value, e.g. sitemap param maybe returned from another
action or
> > session/header/cookie, etc.
> >
> > > > > <snip>
> > > > >
> > > > > :) ...no, I meant the syntax only - as you have given your +1 for
use
> > in
> > > > > the action-sets. (BTW: I'd prefer the "action.method" syntax)
> > > > >
> > > > Ah, ok. I think the additional method attribute is more painless.
I'm
> > not
> > > > sure, but I think I can currently define an action named "hello.you"
> > which
> > > > with your syntax would be handled as a multiaction.
> > >
> > > Carsten, I slept over this... and I found the attribute to be
confusing.
> > > Here comes why: The original problem is that we want to pass more
> > > information via the one request parameter "cocoon-action" than the
single
> > > name of the action. But all we have is *one* string. So for the
request we
> > > can only choose from:
> > >
> > > <!-- java object syntax -->
> > > <input type="submit" name="cocoon-action"
value="usermanagement.add">
> > > <!-- html anchor syntax -->
> > > <input type="submit" name="cocoon-action"
value="usermanagement#add">
> > > <!-- java inner class syntax -->
> > > <input type="submit" name="cocoon-action"
value="usermanagement$add">
> > > <!-- (x)path syntax -->
> > > <input type="submit" name="cocoon-action"
value="usermanagement/add">
> > >
> >
> > So, what will the end user see on his screen in this case? Buttons with
ugly
> > names and what will you do in a multilanguage web application? You'll
get
> > multilanguage method names ;)
>
> *doh* me stupid! We cannot use the value for that. The information must be
> hidden inside the name... damn - this is embarrasing
>
> But hey, this reveals a i18n problem with actions! The value must be a
> i18n value. So you would need action-sets for each language!! This must be
> changed anyway! I guess we need to do this somehow like the turbine guys:
>
> <input type="submit" name="cocoon-action-[actionname]"
value="Hinzufuegen">
>
> While changing this I could easily add the paramter stuff to work the same
> way as you propose with URL stuff below.
>
> <input type="submit" name="cocoon-action-[actionname]/[parameter]"
value="Hinzufuegen">
>
> 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.
>
> > > ...some kind of that. Of course we *could* use a different syntax in
the
> > > sitemap but for consistancy reasons I would prefer to go with the java
> > > syntax and keep it through all the site. But this still brings up some
> > > confusion....
> > >
> > > Another thing is we have to be careful with the contract definition.
> > > What exactly is an action? Actually I think the current contract is
not
> > > exactly what people would expect. Actions are expected to be executed.
A
> > > component cannot be executed - a *method* of component can be
executed.
> > > Unfortunately we cannot change this anymore... but people seem to get
used
> > > to it:)
> > >
> > > But what if we would come up with event definitions? (this is borrowed
> > > from turbine ;) So a method is more an event on an action?
> > >
> > > *If* we change something on the current action handling or not. What I
> > > really like to see is get some additional information from the
> > > cocoon-action request parameter into the the action.
> > >
> > > Another idea: Maybe we could remove a postfix from the cocoon-action
an
> > > add it as action parameter:
> > >
> > > <input type="submit" name="cocoon-action"
value="usermanagement/add">
> > >
> > > Will result in a call of action usermanagement with parameter
> > > "cocoon-action-parameter" set to "add"
> > >
> > > Mulitple actions per class could be implemented easily then...
> >
> > 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 :(
You should do it anyway if you extend sitemap syntax.
Konstantin
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 14 Feb 2002, giacomo wrote:
> > > So, what will the end user see on his screen in this case? Buttons with ugly
> > > names and what will you do in a multilanguage web application? You'll get
> > > multilanguage method names ;)
>
> Oops, this is a very ugly bug in the concept of actions/action-sets.
:)
<snip/>
> This could be a way to go but I propose to slightly change it into:
>
> <input type="submit" name="cocoon-action[-actionname[/parameter]]" value="Hinzufuegen">
>
> This will maintain backward compatability at the produced HTML level.
Of course :)
...just about do commit it. Just want to check it first
> > The /[parameter] could be optional and be translated into an action
> > parameter named "cocoon-action-parameter". What do you think?
>
> We could also add a new ParametrizedAction interface extending the original one and add that parameter to the method sinature.
Hm... sounds good. I'll look into that :)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by giacomo <gi...@apache.org>.
On Thu, 14 Feb 2002, Torsten Curdt wrote:
> On Thu, 14 Feb 2002, Piroumian, Konstantin wrote:
>
> > So, what will the end user see on his screen in this case? Buttons with ugly
> > names and what will you do in a multilanguage web application? You'll get
> > multilanguage method names ;)
Oops, this is a very ugly bug in the concept of actions/action-sets.
> *doh* me stupid! We cannot use the value for that. The information must be
> hidden inside the name... damn - this is embarrasing
>
> But hey, this reveals a i18n problem with actions! The value must be a
> i18n value. So you would need action-sets for each language!! This must be
> changed anyway!
Yes, seems so.
> I guess we need to do this somehow like the turbine guys:
>
> <input type="submit" name="cocoon-action-[actionname]" value="Hinzufuegen">
>
> While changing this I could easily add the paramter stuff to work the same
> way as you propose with URL stuff below.
>
> <input type="submit" name="cocoon-action-[actionname]/[parameter]" value="Hinzufuegen">
This could be a way to go but I propose to slightly change it into:
<input type="submit" name="cocoon-action[-actionname[/parameter]]" value="Hinzufuegen">
This will maintain backward compatability at the produced HTML level.
> The /[parameter] could be optional and be translated into an action
> parameter named "cocoon-action-parameter". What do you think?
We could also add a new ParametrizedAction interface extending the original one and add that parameter to the method sinature.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 14 Feb 2002, Piroumian, Konstantin wrote:
> Hi!
>
> Btw, there were a discussion on a topic related to action selection based
> not only 'cocoon-action' attribute value, but in many other ways, e.g. one
> can select an action/method to execute based on:
>
> 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.
Hm... I should play around with this one...
> 2) Request param value (current implementation):
> /customer?cocoon-action=Add - this has disadvantages, see below.
>
> 3) Request param presence: /customer?addBtn=Add: in this case checked the
> param name, not the value, so you can have multiple submit buttons on the
> screen: <input name="addBtn" value="Add" />, <input name="updateBtn"
> value="Update" />
>
> 4) Any other value, e.g. sitemap param maybe returned from another action or
> session/header/cookie, etc.
>
> > > > <snip>
> > > >
> > > > :) ...no, I meant the syntax only - as you have given your +1 for use
> in
> > > > the action-sets. (BTW: I'd prefer the "action.method" syntax)
> > > >
> > > Ah, ok. I think the additional method attribute is more painless. I'm
> not
> > > sure, but I think I can currently define an action named "hello.you"
> which
> > > with your syntax would be handled as a multiaction.
> >
> > Carsten, I slept over this... and I found the attribute to be confusing.
> > Here comes why: The original problem is that we want to pass more
> > information via the one request parameter "cocoon-action" than the single
> > name of the action. But all we have is *one* string. So for the request we
> > can only choose from:
> >
> > <!-- java object syntax -->
> > <input type="submit" name="cocoon-action" value="usermanagement.add">
> > <!-- html anchor syntax -->
> > <input type="submit" name="cocoon-action" value="usermanagement#add">
> > <!-- java inner class syntax -->
> > <input type="submit" name="cocoon-action" value="usermanagement$add">
> > <!-- (x)path syntax -->
> > <input type="submit" name="cocoon-action" value="usermanagement/add">
> >
>
> So, what will the end user see on his screen in this case? Buttons with ugly
> names and what will you do in a multilanguage web application? You'll get
> multilanguage method names ;)
*doh* me stupid! We cannot use the value for that. The information must be
hidden inside the name... damn - this is embarrasing
But hey, this reveals a i18n problem with actions! The value must be a
i18n value. So you would need action-sets for each language!! This must be
changed anyway! I guess we need to do this somehow like the turbine guys:
<input type="submit" name="cocoon-action-[actionname]" value="Hinzufuegen">
While changing this I could easily add the paramter stuff to work the same
way as you propose with URL stuff below.
<input type="submit" name="cocoon-action-[actionname]/[parameter]" value="Hinzufuegen">
The /[parameter] could be optional and be translated into an action
parameter named "cocoon-action-parameter". What do you think?
> > ...some kind of that. Of course we *could* use a different syntax in the
> > sitemap but for consistancy reasons I would prefer to go with the java
> > syntax and keep it through all the site. But this still brings up some
> > confusion....
> >
> > Another thing is we have to be careful with the contract definition.
> > What exactly is an action? Actually I think the current contract is not
> > exactly what people would expect. Actions are expected to be executed. A
> > component cannot be executed - a *method* of component can be executed.
> > Unfortunately we cannot change this anymore... but people seem to get used
> > to it:)
> >
> > But what if we would come up with event definitions? (this is borrowed
> > from turbine ;) So a method is more an event on an action?
> >
> > *If* we change something on the current action handling or not. What I
> > really like to see is get some additional information from the
> > cocoon-action request parameter into the the action.
> >
> > Another idea: Maybe we could remove a postfix from the cocoon-action an
> > add it as action parameter:
> >
> > <input type="submit" name="cocoon-action" value="usermanagement/add">
> >
> > Will result in a call of action usermanagement with parameter
> > "cocoon-action-parameter" set to "add"
> >
> > Mulitple actions per class could be implemented easily then...
>
> 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 :(
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] was: [PROPOSAL] mulitple actions per class
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
Hi!
Btw, there were a discussion on a topic related to action selection based
not only 'cocoon-action' attribute value, but in many other ways, e.g. one
can select an action/method to execute based on:
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.
2) Request param value (current implementation):
/customer?cocoon-action=Add - this has disadvantages, see below.
3) Request param presence: /customer?addBtn=Add: in this case checked the
param name, not the value, so you can have multiple submit buttons on the
screen: <input name="addBtn" value="Add" />, <input name="updateBtn"
value="Update" />
4) Any other value, e.g. sitemap param maybe returned from another action or
session/header/cookie, etc.
> > > <snip>
> > >
> > > :) ...no, I meant the syntax only - as you have given your +1 for use
in
> > > the action-sets. (BTW: I'd prefer the "action.method" syntax)
> > >
> > Ah, ok. I think the additional method attribute is more painless. I'm
not
> > sure, but I think I can currently define an action named "hello.you"
which
> > with your syntax would be handled as a multiaction.
>
> Carsten, I slept over this... and I found the attribute to be confusing.
> Here comes why: The original problem is that we want to pass more
> information via the one request parameter "cocoon-action" than the single
> name of the action. But all we have is *one* string. So for the request we
> can only choose from:
>
> <!-- java object syntax -->
> <input type="submit" name="cocoon-action" value="usermanagement.add">
> <!-- html anchor syntax -->
> <input type="submit" name="cocoon-action" value="usermanagement#add">
> <!-- java inner class syntax -->
> <input type="submit" name="cocoon-action" value="usermanagement$add">
> <!-- (x)path syntax -->
> <input type="submit" name="cocoon-action" value="usermanagement/add">
>
So, what will the end user see on his screen in this case? Buttons with ugly
names and what will you do in a multilanguage web application? You'll get
multilanguage method names ;)
> ...some kind of that. Of course we *could* use a different syntax in the
> sitemap but for consistancy reasons I would prefer to go with the java
> syntax and keep it through all the site. But this still brings up some
> confusion....
>
> Another thing is we have to be careful with the contract definition.
> What exactly is an action? Actually I think the current contract is not
> exactly what people would expect. Actions are expected to be executed. A
> component cannot be executed - a *method* of component can be executed.
> Unfortunately we cannot change this anymore... but people seem to get used
> to it:)
>
> But what if we would come up with event definitions? (this is borrowed
> from turbine ;) So a method is more an event on an action?
>
> *If* we change something on the current action handling or not. What I
> really like to see is get some additional information from the
> cocoon-action request parameter into the the action.
>
> Another idea: Maybe we could remove a postfix from the cocoon-action an
> add it as action parameter:
>
> <input type="submit" name="cocoon-action" value="usermanagement/add">
>
> Will result in a call of action usermanagement with parameter
> "cocoon-action-parameter" set to "add"
>
> Mulitple actions per class could be implemented easily then...
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?
Regards,
Konstantin Piroumian
Leading Software Developer
Protek Flagship LLC
Phone: + 7 095 795 0520 (add. 1288)
Fax: + 7 095 795 0525
E-mail: kpiroumian@flagship.ru
http://www.protek.com
>
> What do guys think?
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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
[RT] was: [PROPOSAL] mulitple actions per class
Posted by Torsten Curdt <tc...@dff.st>.
> > <snip>
> >
> > :) ...no, I meant the syntax only - as you have given your +1 for use in
> > the action-sets. (BTW: I'd prefer the "action.method" syntax)
> >
> Ah, ok. I think the additional method attribute is more painless. I'm not
> sure, but I think I can currently define an action named "hello.you" which
> with your syntax would be handled as a multiaction.
Carsten, I slept over this... and I found the attribute to be confusing.
Here comes why: The original problem is that we want to pass more
information via the one request parameter "cocoon-action" than the single
name of the action. But all we have is *one* string. So for the request we
can only choose from:
<!-- java object syntax -->
<input type="submit" name="cocoon-action" value="usermanagement.add">
<!-- html anchor syntax -->
<input type="submit" name="cocoon-action" value="usermanagement#add">
<!-- java inner class syntax -->
<input type="submit" name="cocoon-action" value="usermanagement$add">
<!-- (x)path syntax -->
<input type="submit" name="cocoon-action" value="usermanagement/add">
...some kind of that. Of course we *could* use a different syntax in the
sitemap but for consistancy reasons I would prefer to go with the java
syntax and keep it through all the site. But this still brings up some
confusion....
Another thing is we have to be careful with the contract definition.
What exactly is an action? Actually I think the current contract is not
exactly what people would expect. Actions are expected to be executed. A
component cannot be executed - a *method* of component can be executed.
Unfortunately we cannot change this anymore... but people seem to get used
to it:)
But what if we would come up with event definitions? (this is borrowed
from turbine ;) So a method is more an event on an action?
*If* we change something on the current action handling or not. What I
really like to see is get some additional information from the
cocoon-action request parameter into the the action.
Another idea: Maybe we could remove a postfix from the cocoon-action an
add it as action parameter:
<input type="submit" name="cocoon-action" value="usermanagement/add">
Will result in a call of action usermanagement with parameter
"cocoon-action-parameter" set to "add"
Mulitple actions per class could be implemented easily then...
What do guys think?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] mulitple actions per class
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> Torsten Curdt wrote
>
> <snip>
>
> :) ...no, I meant the syntax only - as you have given your +1 for use in
> the action-sets. (BTW: I'd prefer the "action.method" syntax)
>
Ah, ok. I think the additional method attribute is more painless. I'm not
sure, but I think I can currently define an action named "hello.you" which
with your syntax would be handled as a multiaction.
> > If I have a chance to see by looking into the sitemap which methods the
> > multiaction exposes (or which values are valid for the method attribute)
> > then I will change this to +0.
>
> But this means that you once define what is available inside the java code
> and need to mirror this inside the sitemap. This is more work than
> necessary and one of idoms of the sitemap was: (quoting Stefano from the
> docs) "minimal verbosity is of maximum importance" If someone is writing
> an webapp he should know about the classes he is using! If not - he could
> easily look this up in the javadocs. Actually I see this verbosity more as
> burden than helping.
>
> I guess it really depends on how the team is organized. Who is using
> these multiactions? And what goes in there? Actually I think these actions
> are different from the general purpose action that come with cocoon. They
> can be used to bind a java mehod directly to button on a web page.
> This becomes even more interesting if we also could use JavaScriptActions
> this way.
>
Ok, you're right that it depends on how the team is organized. I'm always
thinking of SoC, so one team writing java components and another team
"writing" the webapp by using the provided components. This second team
has no knowledge of Java and they don't know how to look into JavaDocs etc.
Now, it is of course possible to hand them documentation about the
multiaction
which contains everything, but I personally would like to directly see it in
the sitemap as a requirement. documentation is the part of a project where
never anyone has time for.
> Of course having this inside action-sets is better than nothing...
> ...so if noone objects I'd like to implement at least this new feature.
+1 (for action-sets)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] mulitple actions per class
Posted by Torsten Curdt <tc...@dff.st>.
On Wed, 13 Feb 2002, Carsten Ziegeler wrote:
>
> > Torsten Curdt wrote:
> >
> >
> > On Tue, 12 Feb 2002, Carsten Ziegeler wrote:
> >
> > > > Torsten Curdt wrote:
> > > > <snip>
> > > >
> > > > > The verbose solution from above has the advantage that the
> > > > sitemap editor
> > > > > (the person writing the pipelines) sees which actions are available.
> > > >
> > > > Hm... that's true. But I guess these actions are would be
> > mainly used for
> > > > webapp purposes and will be used with the cocoon-action
> > parameter anyway.
> > > > Not inside the sitemap. ...but maybe we could provide both syntaxes?
> > > >
> > > Ah, you mean as an action-set, right?
> > > So something like this (don't quote me on the syntax):
> > >
> > > <map:action-set name="mysuperactionset">
> > > <map:action type="multiaction" method="a" action="add"/>
> > > <map:action type="multiaction" method="d" action="delete"/>
> > > </map:action-set>
> > >
> > > For this I'm +1.
> > >
> > > But I'm not sure about a
> > > <map:act type="multiaction method="a"/> somewhere in the pipelines
> > > section.
> >
> > Yes, in particular for action-sets. Actually right now I am +0 for
> > supporting it within the pipelines but for consistancy reasons I tend to
> > +1. What would we tell someone on cocoon-users why it is not supported
> > within the pipelines?!
> >
> > Is this also a +1 for the method-attribute syntax? ;)
>
> Hehe, nice try. No, sorry, it's rather a -0.
:) ...no, I meant the syntax only - as you have given your +1 for use in
the action-sets. (BTW: I'd prefer the "action.method" syntax)
> If I have a chance to see by looking into the sitemap which methods the
> multiaction exposes (or which values are valid for the method attribute)
> then I will change this to +0.
But this means that you once define what is available inside the java code
and need to mirror this inside the sitemap. This is more work than
necessary and one of idoms of the sitemap was: (quoting Stefano from the
docs) "minimal verbosity is of maximum importance" If someone is writing
an webapp he should know about the classes he is using! If not - he could
easily look this up in the javadocs. Actually I see this verbosity more as
burden than helping.
I guess it really depends on how the team is organized. Who is using
these multiactions? And what goes in there? Actually I think these actions
are different from the general purpose action that come with cocoon. They
can be used to bind a java mehod directly to button on a web page.
This becomes even more interesting if we also could use JavaScriptActions
this way.
Of course having this inside action-sets is better than nothing...
...so if noone objects I'd like to implement at least this new feature.
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] mulitple actions per class
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> Torsten Curdt wrote:
>
>
> On Tue, 12 Feb 2002, Carsten Ziegeler wrote:
>
> > > Torsten Curdt wrote:
> > > <snip>
> > >
> > > > The verbose solution from above has the advantage that the
> > > sitemap editor
> > > > (the person writing the pipelines) sees which actions are available.
> > >
> > > Hm... that's true. But I guess these actions are would be
> mainly used for
> > > webapp purposes and will be used with the cocoon-action
> parameter anyway.
> > > Not inside the sitemap. ...but maybe we could provide both syntaxes?
> > >
> > Ah, you mean as an action-set, right?
> > So something like this (don't quote me on the syntax):
> >
> > <map:action-set name="mysuperactionset">
> > <map:action type="multiaction" method="a" action="add"/>
> > <map:action type="multiaction" method="d" action="delete"/>
> > </map:action-set>
> >
> > For this I'm +1.
> >
> > But I'm not sure about a
> > <map:act type="multiaction method="a"/> somewhere in the pipelines
> > section.
>
> Yes, in particular for action-sets. Actually right now I am +0 for
> supporting it within the pipelines but for consistancy reasons I tend to
> +1. What would we tell someone on cocoon-users why it is not supported
> within the pipelines?!
>
> Is this also a +1 for the method-attribute syntax? ;)
Hehe, nice try. No, sorry, it's rather a -0.
If I have a chance to see by looking into the sitemap which methods the
multiaction exposes (or which values are valid for the method attribute)
then I will change this to +0.
Cheers
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] mulitple actions per class
Posted by Torsten Curdt <tc...@dff.st>.
On Tue, 12 Feb 2002, Carsten Ziegeler wrote:
> > Torsten Curdt wrote:
> > <snip>
> >
> > > The verbose solution from above has the advantage that the
> > sitemap editor
> > > (the person writing the pipelines) sees which actions are available.
> >
> > Hm... that's true. But I guess these actions are would be mainly used for
> > webapp purposes and will be used with the cocoon-action parameter anyway.
> > Not inside the sitemap. ...but maybe we could provide both syntaxes?
> >
> Ah, you mean as an action-set, right?
> So something like this (don't quote me on the syntax):
>
> <map:action-set name="mysuperactionset">
> <map:action type="multiaction" method="a" action="add"/>
> <map:action type="multiaction" method="d" action="delete"/>
> </map:action-set>
>
> For this I'm +1.
>
> But I'm not sure about a
> <map:act type="multiaction method="a"/> somewhere in the pipelines
> section.
Yes, in particular for action-sets. Actually right now I am +0 for
supporting it within the pipelines but for consistancy reasons I tend to
+1. What would we tell someone on cocoon-users why it is not supported
within the pipelines?!
Is this also a +1 for the method-attribute syntax? ;)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] mulitple actions per class
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> Torsten Curdt wrote:
> <snip>
>
> > The verbose solution from above has the advantage that the
> sitemap editor
> > (the person writing the pipelines) sees which actions are available.
>
> Hm... that's true. But I guess these actions are would be mainly used for
> webapp purposes and will be used with the cocoon-action parameter anyway.
> Not inside the sitemap. ...but maybe we could provide both syntaxes?
>
Ah, you mean as an action-set, right?
So something like this (don't quote me on the syntax):
<map:action-set name="mysuperactionset">
<map:action type="multiaction" method="a" action="add"/>
<map:action type="multiaction" method="d" action="delete"/>
</map:action-set>
For this I'm +1.
But I'm not sure about a
<map:act type="multiaction method="a"/> somewhere in the pipelines
section.
Carsten
> Although this might be confusing for some users... :-/
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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
RE: [PROPOSAL] mulitple actions per class
Posted by Torsten Curdt <tc...@dff.st>.
> > <map:act type="usermanager-add">
> > ...
> >
>
> I really like the idea of your proposal and agree that the above is too
> verbose and complicated.
Cool :)
> > I think this is much to complicated and verbose for the
> > sitemap. I see no benefit over:
> >
> > <map:actions>
> > <map:action name="usermanager" src="org.apache..UserManagerAction"/>
> > </map:actions>
> > ...
> >
> > <map:act type="usermanager.add">
> > ...
> >
> > Isn't this simple and straight forward?
> >
> This is simple, but how do I know which methods are available with this
> action? And how do I know that this is a "multiple action class"?
This is easy... you could simply know because there is a dot in the
name:) But I would do a bit more elegant.
We could define an interface e.g. SelfReflective, ReflectionObject or
someting general providing cached information about the class itself.
(at least up to jdk 1.3 this speeds up reflection a LOT!!)
interface ReflectionObject {
public Object call(String key, Object[] parameter)
throws IllegalAccessException,
IllegalArgumentException,
InvocationTargetException
...
}
Or use a more specific interface
interface ReflectionAction {
public Map act( String method,
Redirector redirector,
SourceResolver resolver,
Map objectModel,
String source,
Parameters params ) throws Exception
}
We should provide a default implementation. On configure the action
uses the reflect API to go through it's public methods and will add
the ones starting with a given prefix (e.g. "do") to a HashMap holding
the Method objects. That's almost about it :)
The sitemap then can only call act on the ReflectionAction which
in turn will call the appropriate method.
> The verbose solution from above has the advantage that the sitemap editor
> (the person writing the pipelines) sees which actions are available.
Hm... that's true. But I guess these actions are would be mainly used for
webapp purposes and will be used with the cocoon-action parameter anyway.
Not inside the sitemap. ...but maybe we could provide both syntaxes?
Although this might be confusing for some users... :-/
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] mulitple actions per class
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> Torsten Curdt:
> <snip>
>
> Hm... but then you always have to define each method of the
> class inside the sitemap plus you have to come up with all
> different names. So let's assume we have a usermanager class
>
> public class UserManagerAction extends SomeAction {
>
> public Map doAdd(...) {
> }
>
> public Map doUpdate(...) {
> }
>
> public Map doDelete(...) {
> }
>
> private void commonStuff() {
> }
> }
>
>
> Sitemap:
>
> <map:actions>
> <map:action name="usermanager-add"
> src="org.apache..UserManagerAction" method="doAdd"/>
> <map:action name="usermanager-update"
> src="org.apache..UserManagerAction" method="doUpdate"/>
> <map:action name="usermanager-delete"
> src="org.apache..UserManagerAction" method="doDelete"/>
> </map:actions>
>
> ...
>
> <map:act type="usermanager-add">
> ...
>
I really like the idea of your proposal and agree that the above is too
verbose and complicated.
>
> I think this is much to complicated and verbose for the
> sitemap. I see no benefit over:
>
> <map:actions>
> <map:action name="usermanager" src="org.apache..UserManagerAction"/>
> </map:actions>
> ...
>
> <map:act type="usermanager.add">
> ...
>
> Isn't this simple and straight forward?
>
This is simple, but how do I know which methods are available with this
action? And how do I know that this is a "multiple action class"?
The verbose solution from above has the advantage that the sitemap editor
(the person writing the pipelines) sees which actions are available.
Carsten
>
> The "do" prefix could make sure only desire methods can be used
> as action from a class.
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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
RE: [PROPOSAL] mulitple actions per class
Posted by Torsten Curdt <tc...@dff.st>.
> > 1. <map:action type="SomeActions.doMyAction">
> > <!-- directly use the method -->
>
> Do you mean <map:act>?
ups... sure! ;)
> > 2. <map:action type="SomeActions.MyAction">
> > <!-- have a fix prefix like "do" -->
> >
> > 3. <map:action type="SomeActions" method="doMyAction">
> >
> > 4. <map:action type="SomeActions" method="MyAction">
>
> 5.
> <map:actions>
> <map:action src="com.foo.SomeActions" method="doMyAction"/>
> </map:actions>
>
> <map:act type="SomeActions"/>
Hm... but then you always have to define each method of the
class inside the sitemap plus you have to come up with all
different names. So let's assume we have a usermanager class
public class UserManagerAction extends SomeAction {
public Map doAdd(...) {
}
public Map doUpdate(...) {
}
public Map doDelete(...) {
}
private void commonStuff() {
}
}
Sitemap:
<map:actions>
<map:action name="usermanager-add" src="org.apache..UserManagerAction" method="doAdd"/>
<map:action name="usermanager-update" src="org.apache..UserManagerAction" method="doUpdate"/>
<map:action name="usermanager-delete" src="org.apache..UserManagerAction" method="doDelete"/>
</map:actions>
...
<map:act type="usermanager-add">
...
I think this is much to complicated and verbose for the
sitemap. I see no benefit over:
<map:actions>
<map:action name="usermanager" src="org.apache..UserManagerAction"/>
</map:actions>
...
<map:act type="usermanager.add">
...
Isn't this simple and straight forward?
The "do" prefix could make sure only desire methods can be used
as action from a class.
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] mulitple actions per class
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Torsten Curdt [mailto:tcurdt@dff.st]
>
> While working with actions something bugs me more and more... For each
> very simple action you need to have a new class. Although it might be
just
> a few lines for each, it becomes really ugly when you share code with
> other actions or need to call an action from an action. Plus having
> thousand of action class for a single webapp. Sure this all possible
and
> one can say: then use helper classes that hold all the shared code.
But
> well - possible does not mean confortable.
>
> IIRC with Turbine e.g. it is way more confortable. They use
> "methods as actions":
>
> class SomeActions {
>
> public void doMyAction(..) {
> ...
>
> (I'm not quite sure about the arguments and stuff though)
> This helps to have all related code at a glance.
> Although I'm not yet sure what syntax should be prefered
>
> 1. <map:action type="SomeActions.doMyAction">
> <!-- directly use the method -->
Do you mean <map:act>?
> 2. <map:action type="SomeActions.MyAction">
> <!-- have a fix prefix like "do" -->
>
> 3. <map:action type="SomeActions" method="doMyAction">
>
> 4. <map:action type="SomeActions" method="MyAction">
5.
<map:actions>
<map:action src="com.foo.SomeActions" method="doMyAction"/>
</map:actions>
<map:act type="SomeActions"/>
Vadim
> Of course this will require the use of the reflection API
> for those actions using the new method syntax. (All others
> will not be effected and treated as usual)
>
> I have made some tests: if we use some intelligent
> caching for the reflection API there will be only little
> to no performance loss compared to the old mechanism.
>
> What do guys think?
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org