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]
