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]
