I haven't read Michaels latest write up, so I don't know if its substantially different, but last time I looked the only reason for integrating the "dispatch" style into Action was (IMO) to encourage its use. If thats still true then my opinion is unchanged:
http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 I also think that the concrete Action class tied to the servlet API is legacy and that if you want to inovate then the effort is better spent focusing on the support for CoR/CoC in Struts 1.3 and the Command interface (Commons Chain 1.1 even has a DispatchCommand :-) http://jakarta.apache.org/commons/chain/changes-report.html http://jakarta.apache.org/commons/chain/apidocs/index.html The great benefit of Chain means that having an alternative set of "request processing" steps becomes much easier and you could develop something more elegant to support your event style which would probably mean that the user doesn't need to use either the DispatchAction or ActionDispatcher at all. Niall On 6/28/06, Hubert Rabago <[EMAIL PROTECTED]> wrote:
I like the functionality that this provides. If I ever get to work on another Struts 1 project, I would certainly like to use this. That said, I'm -0 to integrating it, but I won't stand in the way if other committers accept it. I think though that it works well enough without being integrated into the core. With the Extras subproject, what we've done lately is extract things out instead of bundle them in the core. The same can apply to this feature. I think it'll make an excellent subproject that can be distributed along with the main download, like taglibs and tiles integration, and it'll still get the attention it deserves without negatively affecting its potential. Hubert On 6/26/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > I want to stress out that what I suggest is not a framework ;) I did > try to make the standalone library independent of Struts for various > reasons. Still, its concept is quite foriegn to a Struts user, in > comparison to the principle of having code in Action and view in JSP. > > Integrating this idea fully into Struts changes very little in current > Struts development cycle: there is Action that handles events, there > is JSP that displays a view. That is it. No new concepts to users if > they already know what a dispatch action is. Two or three tags that I > implemented are totally optional. Therefore accepting the component > model integrated into Struts core, and developing with it is much > easier than using a standalone library. > > Comparing my enhancement to Tiles, I believe that Tiles is quite rich > in functionality and has its own learning curve. On contrary, my > enhancement fits current Struts coding and configuration conventions > very neatly. Current and future users will not be affected, but for > those who would like to have components out of the box, this > functionality will be available. Why not? > > So, the reasons for including this enhancement into the core: > > * Struts can be called a component framework (or a hybrid > action/component framework). > * User's actions that manage components will be clean and tidy, no > need to instantiate dispatchers or to manually handle > component-related stuff, no plumbing code. > > On the other hand, I do not want to hamper 1.3.5 release plan, I don't > want to fork off /struts/action/trunk/core as well. So having this > enhancement as an extension project in /struts/action/trunk will work > for me. This way I will be able to make isolated updates to the code > without affecting 1.3.5 functionality (will I?). Maybe later we will > return to this duscussion considering including the extension into 1.4 > core :) > > Michael. > > On 6/26/06, Don Brown <[EMAIL PROTECTED]> wrote: > > Ok, I see your points of leveraging known code and frameworks, but according to > > your last article, what you developed isn't tied to Struts at all and can be > > used with pure JSP. If that is the case, perhaps it would be better for this > > component framework to have its own project and be treated similar to what we > > are planning for Tiles. I'm fine with the event dispatching part of your > > proposal, but I'm not convinced a new component framework should be added to > > Struts Action 1 core. > > > > Don > > > > Michael Jouravlev wrote: > > > Don, thanks for replying. See inline. > > > > > > On 6/25/06, Don Brown <[EMAIL PROTECTED]> wrote: > > >> Interesting...I can see you have put a lot of time and thought into > > >> this. My first pass seems to find this a cross between the portlet api > > >> and JSF. What I saw missing from the articles and wiki pages is a > > >> higher level justification: > > >> - Why not just use portlets? > > > > > > Firstly, what I suggest IS portlets :) because the term "portlets" is > > > not copyrighted. Ok, ok, I know you mean JSR-168 portlets. Still, I > > > think it is not fair to consider only JSR-168 portlets to be real > > > portlets. > > > > > > JSR-168 requires to set up portal engine and it imposes porltet API. > > > Nothing like this is imposed on Struts components. Java code is > > > basically the same, JSP code contains couple of enhanced tags. > > > <comp:component> tag is optional. Other tags that I created are > > > optional too. > > > > > > On Java side, the same Struts action can control both page component > > > as well as a normal web resource (dispatch-style). So, with very > > > little change for a user he gets a whole new functionality and revival > > > for old codebase. > > > > > >> - Why not just use JSF? > > > > > > Because I use Struts, meaning Struts Action Framework 1. Why should I > > > switch my framework just to get something that I can have without > > > switching? I don't think that JSF/ICEFaces can do more than improved > > > Struts. If I will be switching I'd choose GWT. Or maybe even Laszlo. > > > Something really different. > > > > > >> - Why should Struts the project include another non-standard component > > >> framework? > > > > > > What do you mean by component framework? The tags? They are optional. > > > The code? It is the same. The Javascript? Yes, it does not use more > > > well-known libraries like Dojo or DWR or Prototype. One of the users > > > of my pure JSP library suggested to implement a unified API for either > > > Behaviour or Prototype. If Struts 1.x had Ajax engine already I would > > > use it, but it does not. > > > > > > Again, it is not inclusion of a foreign library into Struts, it is > > > enhancing Struts with features that proved to work. I cannot see how > > > improving a framework can be a bad thing. > > > > > >> It seems to me that the web framework space is moving 1) towards > > >> standardization > > > > > > I partly answered on this regarding to Javascript engine. Also, Struts > > > is standard by itself. So, maybe this feature *will* become a standard > > > :) at least among those who will still be using SAF1. > > > > > >> and 2) away from JSP-specific solutions and really JSP > > >> altogether. > > > > > > I know you do not use JSP, but many users do. Taglib for a long time > > > was considered a standard Struts library, JSP was considered a > > > standard view technology. I don't see that it can hurt someone if I > > > provide new features for Struts/JSP users. > > > > > >> I'm curious as to what specific value(s) you feel this > > >> component framework brings to Struts that goes against those directions. > > > > > > Consider SAF1 as Win3x/9x/Me, SAF2 as Win NT/2K/XP. I think that SAF1 > > > is somewwhere in Win95 stage, it still can be improved and its users > > > can benefit on this. I don't see the point to switch to a whole new > > > framework if a current one can be enhanced with very little changes > > > (to a user at least) and can still be used to build viable > > > applications. > > > > > >> Michael Jouravlev wrote: > > >> > As most of you probably know, I have been quite obsessed with page > > >> > components developed with JSP or with JSP/Struts [1],[2]. My first > > >> > attempt used Struts/JSP, the second one is pure JSP-based [3]. It > > >> > proved to be quite robust, simple and it works. So now in my newly > > >> > acquired powers of Struts committer I want to build this technology > > >> > into Struts 1.x. > > >> > > > >> > The code is not GA quality yet, but major stuff works. Nice thing is > > >> > that the same code/markup works in both non-Javascript and > > >> > Javascript-enabled browsers. With Javascript, simple Ajax is used to > > >> > replace component markup in a composite page (make it AHAH since it > > >> > returns XHTML, not XML). Without Javascript good old > > >> > redirect-after-post is used, the reload target is calculated > > >> > automatically. > > >> > > > >> > I believe that this is a really nice feature. And it is extensible. > > >> > Compare it to, say, ICEFaces. I was experimenting and I implmented > > >> > many of these features like Ajax tab component or partial submit. This > > >> > technology will put the end to "Struts has no components" claim. I do > > >> > not suggest this for SAF2 since it already has Ajax and component > > >> > features. > > >> > > > >> > You can read more in Wiki pages, that I envision as peice of future > > >> > documentation [4] > > >> > > > >> > I will be able to finish coding myself so I do not need much help on > > >> > this part. What I do need is approval for: > > >> > > > >> > * enhancing Struts 1.x with this technology > > >> > * enhanching Action class with dispatching functionality > > >> > > > >> > So while I will be polishing the code, I want these ideas to get > > >> > marinated for a while. I already raised the question about sticking > > >> > dispatching stuff into Action [5], [6]. The replies were: > > >> > > > >> > Don -- OK > > >> > Frank -- OK, if all current functionality is retained > > >> > Dave N -- OK, if execute() will be made default dispatch method > > >> > Niall - Nah... (but not Noooo! so I hope to convince him) > > >> > > > >> > I would like to explain my position once again, largely for Niall and > > >> > maybe for others too. > > >> > > > >> > * After series of experiments with oh so many flavors of dispatch > > >> > actions we now have the best of the breed: EventDispathAction. It > > >> > covers all the bases, it is highly unlikely that another dispatch > > >> > action will be created for Struts 1.x. I want to implement > > >> > EventDispathAction in base Action. > > >> > * No one will be hurt: it will be possible to use Action just as an > > >> > ordinary old-school Action. Older dispatch actions will work as well. > > >> > * Having dispatching functionality at the core allows to promote the > > >> > concept of a web resource or a web business object. Programming with > > >> > Struts is still more like procedural, comparing to OO. I argue that > > >> > for an interactive app OO paradigm is easier to use, like Customer > > >> > object and methods on it. But again, nothing prevents from standard > > >> > usage of Action. > > >> > * The code will be simpler and cleaner, no need to instantiate > > >> dispatchers. > > >> > * Big thing: it will be possible to make event definition in action > > >> > mapping first-class elements. > > >> > * I can think of more if needed ;-) > > >> > > > >> > Why this is needed? Because my concept of a web component stems from a > > >> > concept of a stateful web resource that is controlled by a dispatch > > >> > action [7]. > > >> > > > >> > The proposed markup in struts-config.xml will look something like this: > > >> > > > >> > <action component = "Login" > > >> > view = "/login/loginComponent.jsp" > > >> > path = "/login" > > >> > type = "samples.login.LoginAction" > > >> > form = "loginform" > > >> > scope = "session" > > >> > validate = "false"> > > >> > <event name="loginEvent" handler="login"/> > > >> > <event name="logoutEvent" handler="logout"/> > > >> > </action> > > >> > > > >> > Here event definitions are first-class elements of action mapping. > > >> > Those of you who object this approach, consider how ASP.NET works. > > >> > Yes, it is page-based, but the code-behind class has event handlers > > >> > for all UI controls on a page. Very, very similar. Struts can do the > > >> > same, but even better, because we can render different views from one > > >> > event dispatcher. > > >> > > > >> > * "component" attribute contains the name of a component. It > > >> > identifies an action as a component manager. Such actions are handled > > >> > differently than a regular action or a simple dispatch action. > > >> > * "view" attribute identifies a default view. May consist of several > > >> > subviews. > > >> > * "form" is just another name for "name" property, I wanted to make > > >> > this change for a long time ;) > > >> > * "event" property allows to define incoming events and corresponding > > >> > method handlers. An event is just a request parameter. > > >> > > > >> > If action mapping does not define "component" and "event" elements, it > > >> > is processed as a regular Action. If "event" elements are defined, > > >> > action is process in the same manner as EventDispatchAction does. If > > >> > "component" is defined, the action does some additional > > >> > component-related processing. I think this is quite simple, and no > > >> > current functionality will be affected. > > >> > > > >> > > > >> > References: > > >> > > > >> > [1] http://today.java.net/pub/a/today/2005/08/04/jspcomponents.html > > >> > [2] http://today.java.net/pub/a/today/2006/05/04/almost-portlets.html > > >> > [3] http://www.jspcontrols.net/ > > >> > [4] http://wiki.apache.org/struts/StrutsManualActionWebComponent > > >> > [5] http://marc.theaimsgroup.com/?l=struts-user&m=114676523831110&w=2 > > >> > [6] http://marc.theaimsgroup.com/?l=struts-dev&m=114723101619599&w=2 > > >> > [7] http://wiki.apache.org/struts/StrutsManualActionClasses > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
