[PROPOSAL] Abstraction layer betwenn the httpServlet package and the action classes

[Emmanuel Feller <Em...@free.fr>]

Hello everybody,

I am still quiet newby in struts technologies, but i am
working on a mvc framework for 2years and when i started
2months ago using struts i was supprised : everytime i want
to push some information from my action classe to my jsp i
must take the request or the session.

So writing a struts application is not simple because it
need knowledge of servlet and jsp technologies.

I am hacking the code to add an abstraction layer, but i
prefer do a proposal before submit a patch. This is a better
way to standardize the API and to have a stable release more
quickly ... or to retake a good way if i am
miss-understanding.

I propose a sessionManager, which is a technical wrapper to
the session. It is able to take care of the mappings,
request and session.
I add three context :
a ViewContext, a HashMap, into which you push your data. So
you don't have to take back the request or session anymore.
The viewContext should be use to manage business data as
well as technicals ones ...
a ModuleContext, this is an intermediate level betwenn the
request scope and the session scope. information in
available only in the module where you are.
a SessionContext, this is a wrapper for session. Information
are available at any time in any module.

One advantage of the module is the segmentation of
information, so you can't have anymore conflict into 2
modules when you push data into the session object.

I also change the signature for the execute method :
ActionForm XXXXX (SessionManager, ViewContext,
ModuleContext, ActionForm)

I do not include the mapping because i am searching an issue
to make the navigation available to the developper : it
should be automatic and only in exception case do
redirection. (i don't have found the better way yet).

I have not inserted the name of the method because i propose
an enhancement into struts-config for action tag. We should
add a command tag, if it is present, the method called will
be the named, else it will be the standard execute method.
So when you have lots of action on a screen, it will not
need lots of action class, only bigger one ...

We are able to do the transformation with backward
compatibility, ie into 1.2 family, or into 2.0 family, as
you prefer. But it will need lots of modifications into
taglibs.

We can do the modification in 2 times, the first (into 1.2)
could be only the add of the new interfaces, and preserve
backward compatibility, the second one into 2.0 family could
be total refactor of the core request processing and also
add new transport protocol (ie ftp, soap, ... ) to make
struts open for new technologies as IRC services ;)) ...

I am waiting for your comments,

Regards,
Emmanuel Feller
Senior Developper
Cap Gemini Ernst & Young
+33 2 51 17 35 00 phone 3716
+33 6 23 34 63 39



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: [PROPOSAL] Abstraction layer betwenn the httpServlet package and the action classes

[Emmanuel Feller <Em...@free.fr>]

Hi Vic,

I take a look to your class and it fill major part of my
proposal, but the struts engine is still http oriented.

So the action classes don't depend on httpservlet package
any more but you still can't process ftp or irc request.
That's why i proposed an enhancement of core engine.

Emmanuel
----- Message d'origine -----
De : "Vic Cekvenich" <vc...@basebeans.com>
� : <st...@jakarta.apache.org>
Envoy� : dimanche 16 mars 2003 16:12
Objet : Re: [PROPOSAL] Abstraction layer betwenn the
httpServlet package and the action classes


> I do something similar:
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/b
P/WEB-INF/src/war/org/apache/scaffoldingLib/base/BaseAct.jav
a
> See the execute has execute(ActionEvent ae) {} and a
dispatcher.
> This way people can add what ever they want to
Event/Context object and
> it's thread safe.
>
> As pointed out, it makes it easier to do non HTML, like
SOAP (included
> in Resin 3.1).
>
> YAAS (Yet Anoother Action Signature).
> .V
>




---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: [PROPOSAL] Abstraction layer betwenn the httpServlet package and the action classes

[Vic Cekvenich <vc...@basebeans.com>]

I do something similar:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bP/WEB-INF/src/war/org/apache/scaffoldingLib/base/BaseAct.java
See the execute has execute(ActionEvent ae) {} and a dispatcher.
This way people can add what ever they want to Event/Context object and 
it's thread safe.

As pointed out, it makes it easier to do non HTML, like SOAP (included 
in Resin 3.1).

YAAS (Yet Anoother Action Signature).
.V



Emmanuel Feller wrote:
> Hello everybody,
> 
> I am still quiet newby in struts technologies, but i am
> working on a mvc framework for 2years and when i started
> 2months ago using struts i was supprised : everytime i want
> to push some information from my action classe to my jsp i
> must take the request or the session.
> 
> So writing a struts application is not simple because it
> need knowledge of servlet and jsp technologies.
> 
> I am hacking the code to add an abstraction layer, but i
> prefer do a proposal before submit a patch. This is a better
> way to standardize the API and to have a stable release more
> quickly ... or to retake a good way if i am
> miss-understanding.
> 
> I propose a sessionManager, which is a technical wrapper to
> the session. It is able to take care of the mappings,
> request and session.
> I add three context :
> a ViewContext, a HashMap, into which you push your data. So
> you don't have to take back the request or session anymore.
> The viewContext should be use to manage business data as
> well as technicals ones ...
> a ModuleContext, this is an intermediate level betwenn the
> request scope and the session scope. information in
> available only in the module where you are.
> a SessionContext, this is a wrapper for session. Information
> are available at any time in any module.
> 
> One advantage of the module is the segmentation of
> information, so you can't have anymore conflict into 2
> modules when you push data into the session object.
> 
> I also change the signature for the execute method :
> ActionForm XXXXX (SessionManager, ViewContext,
> ModuleContext, ActionForm)
> 
> I do not include the mapping because i am searching an issue
> to make the navigation available to the developper : it
> should be automatic and only in exception case do
> redirection. (i don't have found the better way yet).
> 
> I have not inserted the name of the method because i propose
> an enhancement into struts-config for action tag. We should
> add a command tag, if it is present, the method called will
> be the named, else it will be the standard execute method.
> So when you have lots of action on a screen, it will not
> need lots of action class, only bigger one ...
> 
> We are able to do the transformation with backward
> compatibility, ie into 1.2 family, or into 2.0 family, as
> you prefer. But it will need lots of modifications into
> taglibs.
> 
> We can do the modification in 2 times, the first (into 1.2)
> could be only the add of the new interfaces, and preserve
> backward compatibility, the second one into 2.0 family could
> be total refactor of the core request processing and also
> add new transport protocol (ie ftp, soap, ... ) to make
> struts open for new technologies as IRC services ;)) ...
> 
> I am waiting for your comments,
> 
> Regards,
> Emmanuel Feller
> Senior Developper
> Cap Gemini Ernst & Young
> +33 2 51 17 35 00 phone 3716
> +33 6 23 34 63 39



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org