Re: [STRUTS 2X]: Ideas

["Frank W. Zammetti" <fz...@omnytex.com>]

See, now it gets interesting because debate starts :)

(I'm already thinking this should probably be moved to the dev list by 
the way)...

Paul Benedict wrote:
> (1) POJO for forms

Agreed, this would be very nice, and I know it has been discussed before.

> (2) Stubbing of abstract attributes for framework
> implementation like Tapestry.

This is a new concept to me, I'll have to investigate this further. 
Consequently, no comment at this time :)

> (3) The use of native data types in forms without
> worrying of validation.

This one I actually *disagree* with... My thinking now is that an 
ActionForm, whether POJO or not, should only contain Strings.  I believe 
it is a misuse of an ActionForm otherwise and promotes the idea that an 
ActionForm can (or even worse, should) be passed to business delegates. 
  I mean, if my ActionForm has native types and all the conversions are 
handled for me automaticlly, doesn't seem a little redundant to have a 
DTO that is passed from an Action to a business delegate?  I think many 
would think so and get into bad habits (habits I myself had to break 
myself of by the way!).

> (4) Action methods being part of the POJO.

I'm not sure how I feel about this yet... this has also been talked 
about, recently as I recall... I do agree there is some bemefit to this, 
but I'm not sure I like the mixing of essential DTOs (which is what an 
ActionForm is in the end) and Actions.  You might be able to convince me 
on this one, but I don't think I'm with you on it yet :)

> Just imagine how cool it would be to have something
> like:
> 
> public class MyActionForm {
>   // stub out properties
>   public abstract String getFirstName();
>   public abstract String getLastName();
>   public abstract int    getAge();
> 
>   public void save(ActionContext ac) {
>     // save form here
>   }
> 
>   public void edit(ActionContext ac) {
>     // edit form here
>   }
> 
>   public void bluegrass(ActionContext ac) {
>     // do something else here
>   }
> }

The ActionContext is something that has definitely been discussed, and I 
am completely for that.  I absolutely think an Action should no longer 
be accepting HTTP-specific objects.  This was the model my own framework 
took some years ago, and it is one of the very few things that I 
actually missed when I moved to Struts.

I notice you take an approach much like a DispatchAction.  I seem to be 
in the minority on this, but I dislike DispatchActions.  I believe they 
largely run contrary to general object-oriented design (I realize 
however there is a rational argument that says it very much *IS* inline 
with OO thinking).  I would favor an approach that allowed you to do 
like the code you posted does, but doesn't force you into it in any way, 
much like there is nothing forcing you to use a DispatchAction today.

> In this example, all four things happen:
> (1) The object is a POJO and (3) uses native data
> types. If any conversion failure happens, it is
> considered an automatic validation error.

I'm not sure how I feel about *any* conversion error being a validation 
error... I think there may be scenarios where the conversion error 
should be handled differently than a validation error.  In either case, 
this might be something to think about more.

> (3) Action methods are now part of the action form
> itself. Here I used the Struts 1.3 method of having
> the Chain-of-command object be the only thing passed
> in, which should contain references to any other web
> object you need to complete this request. I believe
> JSF does something similar, and why not imitate this
> good idea? Besides, I think the Struts Roadmap has a
> similar idea planned for 1.5???

Agreed.  However, an interesting question is what thet ActionContext 
should be... is it just a Map or is it a real bean?  Do I have to do 
ae.get("request") or do I do ae.getRequest()?  The former is more 
flexible and won't require changes when new objects are added, but the 
later is more obvious and in a sense self-documenting (much like the 
debate about whether it is better to pass generic Maps and such to 
business delegates or true beans?  I used to think Maps were better, now 
I believe beans are).

> Thanks guys.

Excellent food for thought!

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com


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

Re: [STRUTS 2X]: Ideas

[netsql <ne...@roomity.com>]

Frank W. Zammetti wrote:
  what does it really mean for them to be
> rendered client-side and where does DHTML/Ajax fit in?
>

DHTML renders client side(w Ajax RCP). Flex/Lazlo. Swing. XUL. X-Forms?


.V


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

Re: [STRUTS 2X]: Ideas

["Frank W. Zammetti" <fz...@omnytex.com>]

netsql wrote:
> I would say that key for any "new" framework is that it has to default 
> to client side rendering of ui. DHTML/Ajax ... or others ;-)
> And then as option be able to do server side generated UI.

What does that really MEAN though?  For instance, take the common form 
controls we all know and love... what does it really mean for them to be 
rendered client-side and where does DHTML/Ajax fit in?

I think in discussing things like this we need to be careful not to 
simply succumb to buzzword-itis.  Many people view JSF as the future, 
and to the best of my knowledge the default widget set (or whatever the 
correct term is) looks very much like today's UI widgets and does't 
require DHTML/Ajax.  I recall hearing of JSF components that take things 
further and DO use those things, but it isn't a requirement of JSF as I 
recall.

That being said, I definitely DO think there is a place for those 
things, and I think once people come to the conclusion that scripting is 
good and offloading some of the work to the client is good, we'll enter 
a new age of much more robust webapps.  Some of us are doing those 
things today and are quite happy about it (as are our clients who love 
the things we produce).  But if these things are *required* by a 
general-purpose framework, I think it will turn a lot of people off, at 
least for a time.

Frank


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

Re: [STRUTS 2X]: Ideas

[netsql <ne...@roomity.com>]

Frank W. Zammetti wrote:
> See, now it gets interesting because debate starts :)

I would say that key for any "new" framework is that it has to default 
to client side rendering of ui. DHTML/Ajax ... or others ;-)
And then as option be able to do server side generated UI.

.V
roomity.com


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