You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Sean Schofield <se...@gmail.com> on 2004/12/15 19:18:26 UTC
Re: commons-chain: joining with struts
Pedro,
A StrutsWebContext class might be an interesting idea. If adopted, it
should go in the struts-chain project as opposed to commons-chain. (I
am sending a copy of this response to the struts-dev mailing list
which is probably the best place to propose this kind of enhancement).
I'm not sure how useful it would be to have the ActionForm in your
commands but I don't work a lot on struts-chain so maybe others have
an opinion on that.
If you decide to go ahead with submitting an official patch (or just
using it in your own projects) the code should probably be modified to
take advantage of recent changes to commons-chain.
Specifically, you can now use CatalogFactory to get a copy of the
catalog you're interested in. Just make sure to setup the
o.a.c.c.w.ChainListener with the appropriate parameters, and it will
configure the catalog when the webapp starts and it will automatically
be available to any java class using the same class loader (including
your proposed CommandAction).
Hope that helps,
sean
On Tue, 14 Dec 2004 15:56:54 +0100, Pedro Salgado <sa...@04web.com> wrote:
> Hello,
>
> I have read the commons-chain cookbook and I think there is a better way
> to join with struts.
>
> In a command, one can only retrieve the ActionForm by codding
> request/session.getAttribute("formName"); through the ServletWebContext.
>
> Wouldn't it be better if there was a StrutsWebContext class with a
> getActionForm() method that automatically gave the form? This way the
> command should not have to know what is the name of the form (Bor-ring
> ;D)... only the needed form properties.
>
> I think this would simplify a little bit. All comments are welcome.
>
> Regards,
>
> Pedro Salgado
>
> /* My Struts Web Context */
> package test;
>
> import org.apache.commons.chain.web.servlet.ServletWebContext;
> import org.apache.struts.action.ActionForm;
>
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> import javax.servlet.ServletContext;
>
> /**
> * //TODO [JAVADOC] class description
> *
> * @version {version} [{date}]
> */
> public class StrutsWebContext extends ServletWebContext {
>
> private ActionForm form;
>
> public StrutsWebContext(ServletContext context,
> HttpServletRequest request,
> HttpServletResponse response,
> ActionForm form) {
>
> super(context, request, response);
> this.form = form;
> }
>
> public ActionForm getActionForm() {
> return form;
> }
> }
>
> /* Struts chain base action. */
>
> package test;
>
> import org.apache.commons.chain.Catalog;
> import org.apache.commons.chain.Command;
> import org.apache.commons.chain.Context;
> import org.apache.commons.chain.web.servlet.ServletWebContext;
> import org.apache.struts.action.Action;
> import org.apache.struts.action.ActionForm;
> import org.apache.struts.action.ActionForward;
> import org.apache.struts.action.ActionMapping;
>
> import javax.servlet.ServletContext;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
>
> public class CommandAction extends Action {
>
> private static final String SUCCESS = "success";
>
> protected final Command getCommand(final ActionMapping mapping,
> final HttpServletRequest request)
> throws Exception {
>
> Catalog catalog = (Catalog) request.getSession()
> .getServletContext().getAttribute("catalog");
> String name = mapping.getName();
> Command command = catalog.getCommand(name);
>
> return command;
> }
>
> protected final Context getContext(final ActionMapping mapping,
> final HttpServletRequest request,
> final HttpServletResponse response,
> final ActionForm form)
> throws Exception {
>
> ServletContext application = request.getSession()
> .getServletContext();
>
> return new StrutsWebContext(application, request, response, form);
> }
>
> protected final ActionForward findLocation(final ActionMapping mapping,
> final boolean stop) {
>
> if (stop) return mapping.getInputForward(); // Something failed
>
> return mapping.findForward(SUCCESS);
> }
>
> public final ActionForward execute(final ActionMapping mapping,
> final ActionForm form,
> final HttpServletRequest request,
> final HttpServletResponse response)
> throws Exception {
>
> Command command = getCommand(mapping, request);
> Context context = getContext(mapping, request, response);
>
> boolean stop = command.execute(context);
> ActionForward location = findLocation(mapping, stop);
>
> return location;
> }
> }
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: commons-chain: joining with struts
Posted by Don Brown <mr...@twdata.org>.
ActionContext could certainly, and probably will be, a subclass of
o.a.c.c.Context but my point is it will not be a subclass of the
ServletWebContext, which struts-chain creates and passes through its
commands.
Don
Vic wrote:
> Ah... can someone educate me as to why not just subclass chain
> context, would it not let you just do the same thing you said bellow?
> (and w/o servlet api).
>
> .V
>
>
> Don Brown wrote:
>
>> The summary of our discussion, as I understand it, would be to create
>> a ActionContext, which would not be a subclass of any commons-chain
>> contexts, but would contain the commons-chain, probably WebContext
>> instance available via a getter. This would allow us to have one
>> ActionContext instance, and not have to subclass the different faces,
>> portlet, and servlet instances. The Action class would be replaced
>> by an Actionable (name not decided) interface which would have one
>> method, execute(ActionContext ctx). This ActionContext would also
>> have basically all the methods from Action like saveToken(), etc.
>>
>> Don
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: commons-chain: joining with struts
Posted by Vic <vi...@friendvu.com>.
Ah... can someone educate me as to why not just subclass chain context,
would it not let you just do the same thing you said bellow?
(and w/o servlet api).
.V
Don Brown wrote:
> The summary of our discussion, as I understand it, would be to create
> a ActionContext, which would not be a subclass of any commons-chain
> contexts, but would contain the commons-chain, probably WebContext
> instance available via a getter. This would allow us to have one
> ActionContext instance, and not have to subclass the different faces,
> portlet, and servlet instances. The Action class would be replaced by
> an Actionable (name not decided) interface which would have one
> method, execute(ActionContext ctx). This ActionContext would also
> have basically all the methods from Action like saveToken(), etc.
>
> Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: commons-chain: joining with struts
Posted by Don Brown <mr...@twdata.org>.
The summary of our discussion, as I understand it, would be to create a
ActionContext, which would not be a subclass of any commons-chain
contexts, but would contain the commons-chain, probably WebContext
instance available via a getter. This would allow us to have one
ActionContext instance, and not have to subclass the different faces,
portlet, and servlet instances. The Action class would be replaced by
an Actionable (name not decided) interface which would have one method,
execute(ActionContext ctx). This ActionContext would also have
basically all the methods from Action like saveToken(), etc.
Don
Joe Germuska wrote:
> As one of the Struts developers who is very keen on moving
> chain-integration forward, I'll say a few brief words. I'm not on the
> commons-user list, but I will say that Sean's right that this
> discussion is best suited to struts-dev. (I'll leave commons-user on
> this message, but I'd encourage anyone else who responds to only reply
> to dev@struts.apache.org)
>
> Anyway, we've talked about a StrutsWebContext, and in fact, we've
> talked about a few different subclasses of o.a.c.chain.Context for use
> in different phases of the request process. You may want to look
> through the mailing list archives, as this has been a pretty active
> topic of discussion in the last 2-3 months.
>
> Now that Chain has hit a full release, we are definitely planning on
> moving ahead with changing the default request processor in Struts to
> be based on commons-chain. The struts-chain project which is
> currently available from the subversion repository is a very healthy
> working implementation. The migration to the Struts core will mostly
> involve building in a mechanism for initializing any number of
> catalogs (obsoleting a Plugin class which does it in struts-chain).
>
> But I absolutely agree that it makes sense to make type-safe
> subclasses of Context which clarify the names and types of important
> participants in the Struts request processing chain. I would only
> argue that we'd probably like to keep "Web" from being too visible, as
> we feel in Struts that it would be good to decrease explicit
> dependencies on the Servlet API.
>
> Best,
> Joe
>
> At 1:18 PM -0500 12/15/04, Sean Schofield wrote:
>
>> Pedro,
>>
>> A StrutsWebContext class might be an interesting idea. If adopted, it
>> should go in the struts-chain project as opposed to commons-chain. (I
>> am sending a copy of this response to the struts-dev mailing list
>> which is probably the best place to propose this kind of enhancement).
>>
>> I'm not sure how useful it would be to have the ActionForm in your
>> commands but I don't work a lot on struts-chain so maybe others have
>> an opinion on that.
>>
>> If you decide to go ahead with submitting an official patch (or just
>> using it in your own projects) the code should probably be modified to
>> take advantage of recent changes to commons-chain.
>>
>> Specifically, you can now use CatalogFactory to get a copy of the
>> catalog you're interested in. Just make sure to setup the
>> o.a.c.c.w.ChainListener with the appropriate parameters, and it will
>> configure the catalog when the webapp starts and it will automatically
>> be available to any java class using the same class loader (including
>> your proposed CommandAction).
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: commons-chain: joining with struts
Posted by Joe Germuska <Jo...@Germuska.com>.
As one of the Struts developers who is very keen on moving
chain-integration forward, I'll say a few brief words. I'm not on
the commons-user list, but I will say that Sean's right that this
discussion is best suited to struts-dev. (I'll leave commons-user
on this message, but I'd encourage anyone else who responds to only
reply to dev@struts.apache.org)
Anyway, we've talked about a StrutsWebContext, and in fact, we've
talked about a few different subclasses of o.a.c.chain.Context for
use in different phases of the request process. You may want to look
through the mailing list archives, as this has been a pretty active
topic of discussion in the last 2-3 months.
Now that Chain has hit a full release, we are definitely planning on
moving ahead with changing the default request processor in Struts to
be based on commons-chain. The struts-chain project which is
currently available from the subversion repository is a very healthy
working implementation. The migration to the Struts core will mostly
involve building in a mechanism for initializing any number of
catalogs (obsoleting a Plugin class which does it in struts-chain).
But I absolutely agree that it makes sense to make type-safe
subclasses of Context which clarify the names and types of important
participants in the Struts request processing chain. I would only
argue that we'd probably like to keep "Web" from being too visible,
as we feel in Struts that it would be good to decrease explicit
dependencies on the Servlet API.
Best,
Joe
At 1:18 PM -0500 12/15/04, Sean Schofield wrote:
>Pedro,
>
>A StrutsWebContext class might be an interesting idea. If adopted, it
>should go in the struts-chain project as opposed to commons-chain. (I
>am sending a copy of this response to the struts-dev mailing list
>which is probably the best place to propose this kind of enhancement).
>
>I'm not sure how useful it would be to have the ActionForm in your
>commands but I don't work a lot on struts-chain so maybe others have
>an opinion on that.
>
>If you decide to go ahead with submitting an official patch (or just
>using it in your own projects) the code should probably be modified to
>take advantage of recent changes to commons-chain.
>
>Specifically, you can now use CatalogFactory to get a copy of the
>catalog you're interested in. Just make sure to setup the
>o.a.c.c.w.ChainListener with the appropriate parameters, and it will
>configure the catalog when the webapp starts and it will automatically
>be available to any java class using the same class loader (including
>your proposed CommandAction).
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: commons-chain: joining with struts
Posted by Joe Germuska <Jo...@Germuska.com>.
As one of the Struts developers who is very keen on moving
chain-integration forward, I'll say a few brief words. I'm not on
the commons-user list, but I will say that Sean's right that this
discussion is best suited to struts-dev. (I'll leave commons-user
on this message, but I'd encourage anyone else who responds to only
reply to dev@struts.apache.org)
Anyway, we've talked about a StrutsWebContext, and in fact, we've
talked about a few different subclasses of o.a.c.chain.Context for
use in different phases of the request process. You may want to look
through the mailing list archives, as this has been a pretty active
topic of discussion in the last 2-3 months.
Now that Chain has hit a full release, we are definitely planning on
moving ahead with changing the default request processor in Struts to
be based on commons-chain. The struts-chain project which is
currently available from the subversion repository is a very healthy
working implementation. The migration to the Struts core will mostly
involve building in a mechanism for initializing any number of
catalogs (obsoleting a Plugin class which does it in struts-chain).
But I absolutely agree that it makes sense to make type-safe
subclasses of Context which clarify the names and types of important
participants in the Struts request processing chain. I would only
argue that we'd probably like to keep "Web" from being too visible,
as we feel in Struts that it would be good to decrease explicit
dependencies on the Servlet API.
Best,
Joe
At 1:18 PM -0500 12/15/04, Sean Schofield wrote:
>Pedro,
>
>A StrutsWebContext class might be an interesting idea. If adopted, it
>should go in the struts-chain project as opposed to commons-chain. (I
>am sending a copy of this response to the struts-dev mailing list
>which is probably the best place to propose this kind of enhancement).
>
>I'm not sure how useful it would be to have the ActionForm in your
>commands but I don't work a lot on struts-chain so maybe others have
>an opinion on that.
>
>If you decide to go ahead with submitting an official patch (or just
>using it in your own projects) the code should probably be modified to
>take advantage of recent changes to commons-chain.
>
>Specifically, you can now use CatalogFactory to get a copy of the
>catalog you're interested in. Just make sure to setup the
>o.a.c.c.w.ChainListener with the appropriate parameters, and it will
>configure the catalog when the webapp starts and it will automatically
>be available to any java class using the same class loader (including
>your proposed CommandAction).
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org