cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [PROPOSAL] mulitple actions per class
Date Tue, 12 Feb 2002 14:13:45 GMT
> 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


Mime
View raw message