struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Jouravlev <jmi...@gmail.com>
Subject Re: Integrating AJAX into Struts
Date Fri, 11 Nov 2005 20:03:23 GMT
On 11/11/05, Hubert Rabago <hrabago@gmail.com> wrote:
> On 11/11/05, Michael Jouravlev <jmikus@gmail.com> wrote:
> >
> > Oops, am I blind or what? Hubert, this is awesome! Thanks a
> > bunch, I would like to, er..., purloin this stuff for my use :-)
>
> Sure, have fun!  Be aware though that there's a lot of, uhm,
> "opportunities for improvement" here.  I've already thought of a few
> the past week.  (There's some that are shouting very loudly in my mind
> right now.)

I will try. I even got a book on Javascript :) (never used it before).

> > Stuff like this should be included in the Core ;-)
>
> Uhm, well no.  Read the disclaimers.  :)
>
> <rant>
> I keep hoping that I can find a way for people to get more comfortable
> about using extras that don't come with the Struts download.  Sure
> there are some lost causes out there, such as those whose bosses don't
> even want them to use the EL tags because they're not part of "The
> Distribution".  However, one of the big plusses of Struts is the
> amount of third party libraries that support it.
>
> I mean, c'mon, people say great things about Eclipse, saying its
> plugins make it very powerful.  And JSF gets praise for being highly
> extensible.  So how come we don't take advantage of the Struts plugins
> and extensions?
> </rant>

I don't agree with you. Eclipse is an empty hangar, which can be
filled up with tools, benches and other machinery. You use each
machine as it is supposed to be used, and you use the hangar just to
transport parts from one machine to another, or to provide some basic
stuff like electricity, ventilation, etc.

Struts is not a container, it is a framework. It not only provides
features, it imposes a certain way of using them. For example, Struts
Dialogs is an add-on library, but it uses Struts in a way kinda
opposite to "official" rules. It is hard for people to use a library
if it is not endorsed by Struts dev team, and even behaves in a
different manner? Even harder for them to make a mind shift. Speaking
about me, I want not just to provide an add-on library for Struts, but
to change the way Struts applications are written. Yep, I am that
arrogant :-) I cannot do this simply providing an add-on. The problem
here, that I need to convince core devs themselves that my approach is
better ;-)

Same with other core technologies like flow. HTML2 is on a fence,
maybe better suited for an add-on. FormDef somewhat changes the usage
of forms too, so it has to be officially endorsed for users to ebrace
it. At least as an optional way, if not the "one and only" proper way.

> Whoo.  Sorry.  I think that got built up for some time now.

Don't tell me :-)

> Of course, now my time is going to this other thing we talked about a
> few weeks before:
> http://marc.theaimsgroup.com/?l=struts-dev&m=112930650012896&w=2

I started to look into garbage collector for forms. POJO or not, we
should have something, that works as a container for all data used by
action, be it ActionForm or a regular Java class, implementing a
certain interface. We need to be able to easily and reliably locate
these input/output containers to manage them. Please keep this in mind
if you will work on action/form combo :)

I added a "scenario" attribute to <action> element, and on each
request I am going to check session and to clean all form beans that
do not correspond to action's scenario ("scenario" attribute can
enlist several scenarios that action participates in). It would be
simpler to define scenario for <form-bean> themselves, but I think it
is easier for developer to think in terms of grouped actions, not
grouped forms.

Michael.

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


Mime
View raw message