Re: [STRUTS 2X]: Ideas
If someone have not noticed my another message, I have got the article published. It discusses the idea of two-phase components, JSP controls and Struts implementation: http://today.java.net/pub/a/today/2005/08/04/jspcomponents.html I hope that the article explains better what I has been offering for last couple of months. The article discusses the issue from another perspective, but I hope it is even better to see the same thing from a different angle. Michael --- Struts Dialogs http://struts.sourceforge.net/strutsdialogs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
Likewise; I haven't made a detailed comparison of the different frameworks out there since around the time Tapestry was migrating to Apache! Should be interesting reading. L. David G. Friedman wrote: I'm definitely interested that so don't forget to post about it. :) Regards, David, Craig PS: For a slightly more in depth comparison between the frameworks mentioned above, watch for me to post the slides for my O'Reilly Open Source Conference session tomorrow that compares them. You can't get *too* detailed in 45 minutes, but I try to provide at least an overview comparison about how the most popular frameworks deal with a common set of issues. -- Laurie, Open Source advocate, Java geek and novice blogger: http://www.holoweb.net/laurie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
Interesting, how different Struts crowd is ;) Some want to keep what they have, but make it cleaner. Other want the revolution. What about gradual improvement with compatibility with current code base? I will try to explain again my ideas. As we all know, there are two approaches for webapps: Front Controller and Page Controller. Page Controller approach is simple to explain: it is page content combined with backing bean / code-behind / whatever you call it. An application unit is a page with some plumbing and business code. With Front Controller a unit is a Dispatcher, which renders a view: http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html . It seems to me that Front Controller pattern is underused by many Struts users, who actually might be pretty happy with Page Controller. This is probably one of the reasons of their migration to JSF. But the strong selling point of Front Controller is that each Controller/Dispatcher *can generate different views*, that is, different pages. Many Struts users think in terms of "flow" of pages interleaved with actions (setup action->page->process action). I suggest to think in terms of actions owning a set of pages. So, there would be no setup actions or process actions. When an action is navigated to it displays a view corresponding to current action state, as simple as that. The "action having tree of pages" is more object-oriented. With it, an action has state and has events. This just begs for bringing Action and ActionForm into one class. Keeping state is easier on server, so this stateful action would have session scope. And, to provide better user experience, it use two phase request processing, redirecting from input phase to view phase. So, this is what I am suggesting, to move away from sequential approach of setup/process actions and from one JSP per action. And to accept (as an option! The codebase is still the same) to accept the idea of action as a stateful resource with multiple views. This is what Struts Dialogs provides. So, my vision of future Struts development is: * action as a stateful resource with multiple views * DispatchAction or its flavor is a base action to implement stateful resource and event handlers * two-phase request processing aka Redirect-after-Post (mainly for form submits) * Free navigation between actions (no flow is required to move from one action to another, but flow can be employed if needed.) * Short wizards are implemented by one action, not as sequence of actions * Two-phase request processing allows to create embeddable components using JSP without Portlet API and portlet engine * Standard components for login, for CRUD, for lists, etc. All this requires very little additions to current codebase, basically, just one action class. This may be a revolution in minds, but a very mild evolution for codebase :) Michael. --- Struts Dialogs: build components, controls and wizards http://struts.sourceforge.net/strutsdialogs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [STRUTS 2X]: Ideas
I'm definitely interested that so don't forget to post about it. :) Regards, David, > Craig > PS: For a slightly more in depth comparison between > the frameworks mentioned above, watch for me to post > the slides for my O'Reilly Open Source Conference > session tomorrow that compares them. You can't get > *too* detailed in 45 minutes, but I try to provide at > least an overview comparison about how the most popular > frameworks deal with a common set of issues. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
On 8/2/05, Dakota Jack <[EMAIL PROTECTED]> wrote: > > I agree for a third time, and in fact I think that something that is > built for Struts rather than on its own merits and is dependent on the > present community for support is not worth working on at all. I am > personally not willing to associate in an active way with anything > that is not IoC pure in both dependency and locator injection. I > think I am going to follow Ted's advice and begin coding completely > independent of but appreciative of the basic Struts controller ideas > and to see who wants to join in. If anyone is interested in pursuing > this from the bottom up and also understands what is going on, let me > know and we can work together on getting a base started. The first > thing I am going to do is to see if the web framework with Spring is > good enough to join. > If IoC is your favorite architectural paradigm, you will definitely like Spring MVC -- it is consistently based on building up the front controller part of the application using Spring's IoC faciities, consistent with the way that everything else in a well-designed Spring app is configured. And, of course, you get seamless access to all the other stuff that Spring itself provides (which is a pretty substantial array of technology). On the other hand, if you really crave the "ActionForm is a POJO with typed properties and embedded action methods", take a look at WebWork or Tapestry or JSF -- all of which implement this basic concept today. Indeed, if I had thought of it at the time, Struts 1.x would have looked a lot more like WebWork in how it deals with the "action form" and "action" concepts. The interesting aspect of working on web frameworks today is that there is a plethora of options, many *very* well designed -- to the point where trying to start from scratch and build a new one, and then hope it gains enough popularity to impact the market, seems like an exercise in futility. That's one of the primary reasons I'm not going to be personally involved in coding whatever Struts 1.x turns into (unless Shale gets adopted as "Struts X.Y" at some point, of course :-). The only reasonable strategy that appeals to me is starting from a unique position compared to those other frameworks (build around JSF and avoid redundantly implementing all the stuff JSF already provides), which is what I'm doing with Shale. Craig PS: For a slightly more in depth comparison between the frameworks mentioned above, watch for me to post the slides for my O'Reilly Open Source Conference session tomorrow that compares them. You can't get *too* detailed in 45 minutes, but I try to provide at least an overview comparison about how the most popular frameworks deal with a common set of issues. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
On 8/1/05, Ted Husted <[EMAIL PROTECTED]> wrote: > On 7/31/05, Nick Heudecker <[EMAIL PROTECTED]> wrote: > > > I think there are a lot of people out there who feel as you do, but > > > backwards-compatibility has always been a major theme for those > > > > While backwards compatibility is nice, I would rather see a better > > framework for the 2.x release. My personal opinion is that version > > compatibility should be required between point releases, but all bets > > are off for major revisions. > > I would tend to agree. Me too. > > Personally, I think a great place to start would be a Struts codebase > for Java 5. It's not something I can work on myself right now, but if > I start coding in Java again, I'd definately want to get up to speed > with everything that Java 5 has to offer. Me too, also. > What we want to most in a proposal is an indication that the project > will go on whether Struts accepts it or not. We want codebases that > can stand on their own feet, but would prefer to stand with us, if > they can. If the only way a codebase will get written is if we accept > it, then the codebase will never be written :) > > Every major codebases we've ever accepted, Validator, Tiles, Nesting, > EL, Scripting, Flow, and Shale, were all written and attracting > communities before we considered them for subprojects. And, had we > passed, each one of these would have gone on to live indepedant lives > with their own communities.. I agree for a third time, and in fact I think that something that is built for Struts rather than on its own merits and is dependent on the present community for support is not worth working on at all. I am personally not willing to associate in an active way with anything that is not IoC pure in both dependency and locator injection. I think I am going to follow Ted's advice and begin coding completely independent of but appreciative of the basic Struts controller ideas and to see who wants to join in. If anyone is interested in pursuing this from the bottom up and also understands what is going on, let me know and we can work together on getting a base started. The first thing I am going to do is to see if the web framework with Spring is good enough to join. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [STRUTS 2X]: Ideas
> -Original Message-
> From: Adam Hardy [mailto:[EMAIL PROTECTED]
====
>
>
> Pilgrim, Peter on 01/08/05 09:30, wrote:
> > Struts 2 should force an Action or ActionForm to be interface or
> > subclass of an abstract type, hence dependency injection.
> >
Oops! My wording was wrong.
Struts 2 should [definitely] __NOT__ force an Action or ActionForm
implement an a particular interface or interfaces, or be a
concrete subclass of any abstract type.
Hence dependency injection presupposes the existance of a container
and also a lifecycle manager.
> > If the former is the case, then it follows that calling the action
> > method should be flexible
> >
> > public void bluegrass(ActionContext ac) { /* ... */}
> >
> > or
> >
> > public void bluegrass() {
> > ActionContext ac = typeOfThreadLocal.getFromSomeWhere();
> > /* ... */ }
> >
> > then you need to handle absurdities like so (the general case )
> >
> > public void bluegrass( A a, B b, ... ActionContext ac, ...
> Y y, Z z )
> > { /* ... */}
> >
>
> Dependency injection lets me swap implementations really
> easily, so for
> instance in testing for business tier, I can have either real DAOs or
> Mock DAOs depending on the XML configuration I choose.
>
> So in the servlet tier, what would be the advantages? In
> testing again I
> guess, choosing to inject either the real Factories or Mock Factories
> (or Delegates or Session Facade, choose your pattern).
>
> You could put this IoC in the struts-config. It could also inject the
> form bean, if the plan allows for its seperation from the action. The
> action would have to be instantiated for each request in that case,
> rather than having one per container.
>
And in particular putting this dependency injection and
assembly information also inside the struts-config would remove
one more XML file to configure.
--
Peter Pilgrim :: J2EE Software Development
Operations/IT - Credit Suisse First Boston,
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
==
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.csfb.com/legal_terms/disclaimer_external_email.shtml
==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [STRUTS 2X]: Ideas
> -Original Message- > From: Ted Husted [mailto:[EMAIL PROTECTED] ==== > > On 7/31/05, Nick Heudecker <[EMAIL PROTECTED]> wrote: > > > I think there are a lot of people out there who feel as > you do, but > > > backwards-compatibility has always been a major theme for those > > > > While backwards compatibility is nice, I would rather see a better > > framework for the 2.x release. My personal opinion is that version > > compatibility should be required between point releases, > but all bets > > are off for major revisions. > > I would tend to agree. > > Personally, I think a great place to start would be a Struts codebase > for Java 5. It's not something I can work on myself right now, but if > I start coding in Java again, I'd definately want to get up to speed > with everything that Java 5 has to offer. > > A lot of frameworks that are very different from Struts are able to > read the Struts configuration and allow use of Struts actions and > such, while also allowing use of the native framework members. > > But any proposals for a new Struts subproject or revolution have to be > based on an existing codebase. Discussions and debates will never be > enough. Someone has to show us the code, and more importantly, the > community behind the code. > Yes I tend to agree that just discussions is not equal to code, but one must have "the vision", and for a vision you must eventually come up with a design. > When a coder is a committer, like Craig or I, we can start whiteboards > in the Apache repository, mainly to avoid putting the code through the > Incubator later. But, we still have to go through the same guantlet > with the Struts PMC that a codebase that originated at SourceForge > goes through. > > What we want to most in a proposal is an indication that the project > will go on whether Struts accepts it or not. We want codebases that > can stand on their own feet, but would prefer to stand with us, if > they can. If the only way a codebase will get written is if we accept > it, then the codebase will never be written :) > > Every major codebases we've ever accepted, Validator, Tiles, Nesting, > EL, Scripting, Flow, and Shale, were all written and attracting > communities before we considered them for subprojects. And, had we > passed, each one of these would have gone on to live indepedant lives > with their own communities.. So what you saying one can take the existing codebase and build a next generation derivative. Publish it around, wait for the community to build up, and then you will get a chance to be considered among equals. > > HTH. Ted. > ==== -- Peter Pilgrim :: J2EE Software Development Operations/IT - Credit Suisse First Boston, Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.csfb.com/legal_terms/disclaimer_external_email.shtml == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
Pilgrim, Peter on 01/08/05 09:30, wrote:
Struts 2 should force an Action or ActionForm to be interface or
subclass of an abstract type, hence dependency injection.
If the former is the case, then it follows that calling the action
method should be flexible
public void bluegrass(ActionContext ac) { /* ... */}
or
public void bluegrass() {
> ActionContext ac = typeOfThreadLocal.getFromSomeWhere();
> /* ... */ }
then you need to handle absurdities like so (the general case )
public void bluegrass( A a, B b, ... ActionContext ac, ... Y y, Z z )
{ /* ... */}
Dependency injection lets me swap implementations really easily, so for
instance in testing for business tier, I can have either real DAOs or
Mock DAOs depending on the XML configuration I choose.
So in the servlet tier, what would be the advantages? In testing again I
guess, choosing to inject either the real Factories or Mock Factories
(or Delegates or Session Facade, choose your pattern).
You could put this IoC in the struts-config. It could also inject the
form bean, if the plan allows for its seperation from the action. The
action would have to be instantiated for each request in that case,
rather than having one per container.
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
Paul Benedict on 01/08/05 12:54, wrote: Peter writes: (2) Stubbing of abstract attributes for framework implementation like Tapestry. Are you talking abouting the ``jwcid'' attribute? No. When you create a Tapestry page, you don't have to implement the getters - or even write the setter methods for attributes (unless you want to use them). See the class example I wrote; the three properties are stubbed out for implementation and then the framework automatically subclasses the class, and provides an implementation for them. So Tapestry auto-generates the subclasses like xdoclet or middlegen? It makes me wonder what its deployment lifecycle is like. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
On 7/31/05, Nick Heudecker <[EMAIL PROTECTED]> wrote: > > I think there are a lot of people out there who feel as you do, but > > backwards-compatibility has always been a major theme for those > > While backwards compatibility is nice, I would rather see a better > framework for the 2.x release. My personal opinion is that version > compatibility should be required between point releases, but all bets > are off for major revisions. I believe that my dialog stuff is a pretty big step for traditional Struts request/response processing, while being FULLY compatible with current codebase. But seems that those who want innovation, choose different frameworks, while those who stay with Struts, do not want to change the way they are used to do things. > Since we're offering suggestions, I would like to see a simplified > configuration, or none at all, like Wicket. Wicket is good. I would already switched to Wicket, if not for the code that I already have written for Struts. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
On 7/31/05, Nick Heudecker <[EMAIL PROTECTED]> wrote: > > I think there are a lot of people out there who feel as you do, but > > backwards-compatibility has always been a major theme for those > > While backwards compatibility is nice, I would rather see a better > framework for the 2.x release. My personal opinion is that version > compatibility should be required between point releases, but all bets > are off for major revisions. I would tend to agree. Personally, I think a great place to start would be a Struts codebase for Java 5. It's not something I can work on myself right now, but if I start coding in Java again, I'd definately want to get up to speed with everything that Java 5 has to offer. A lot of frameworks that are very different from Struts are able to read the Struts configuration and allow use of Struts actions and such, while also allowing use of the native framework members. But any proposals for a new Struts subproject or revolution have to be based on an existing codebase. Discussions and debates will never be enough. Someone has to show us the code, and more importantly, the community behind the code. When a coder is a committer, like Craig or I, we can start whiteboards in the Apache repository, mainly to avoid putting the code through the Incubator later. But, we still have to go through the same guantlet with the Struts PMC that a codebase that originated at SourceForge goes through. What we want to most in a proposal is an indication that the project will go on whether Struts accepts it or not. We want codebases that can stand on their own feet, but would prefer to stand with us, if they can. If the only way a codebase will get written is if we accept it, then the codebase will never be written :) Every major codebases we've ever accepted, Validator, Tiles, Nesting, EL, Scripting, Flow, and Shale, were all written and attracting communities before we considered them for subprojects. And, had we passed, each one of these would have gone on to live indepedant lives with their own communities.. HTH. Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [STRUTS 2X]: Ideas
Peter writes: >> (2) Stubbing of abstract attributes for framework >> implementation like Tapestry. >> Are you talking abouting the ``jwcid'' attribute? No. When you create a Tapestry page, you don't have to implement the getters - or even write the setter methods for attributes (unless you want to use them). See the class example I wrote; the three properties are stubbed out for implementation and then the framework automatically subclasses the class, and provides an implementation for them. I think this kind of behavior brings the best of both worlds of ActionForms and DynaActionForms: compile time type-safety + less coding. __ Yahoo! Mail for Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [STRUTS 2X]: Ideas
> -Original Message-
> From: Paul Benedict [mailto:[EMAIL PROTECTED]
====
>
> Frank,
>
> I am fond of these two ideas (see following). Heck, I
> would be willing to even write them if I think there
> would be a chance of someone actually commiting them
> into the Trunk!!
>
> There are four things that I am very fond of and they
> are all tightly integrated:
> (1) POJO for forms
See below
> (2) Stubbing of abstract attributes for framework
> implementation like Tapestry.
Are you talking abouting the ``jwcid'' attribute?
> (3) The use of native data types in forms without
> worrying of validation.
A new validation methodology is required.
With JSF there is processing render life cycle,
now the new version could borrow that model, or
better analyse it and come with something better.
> (4) Action methods being part of the POJO.
Agreed here. I would like the flexible to make the action form
and the action seperate or be part of the same class.
Struts uses the BeanUtil library so in order to change the
use of native types in form without validations may require
changes to that library.
I believe Struts 2 should inject dependencies into the actions
or action forms. It is a little contraversial as there
are many IoC frameworks out to there to do this already.
Struts 2 should force an Action or ActionForm to be interface
or subclass of an abstract type, hence dependency injection.
If the former is the case, then it follows that calling the
action method should be flexible
public void bluegrass(ActionContext ac) { /* ... */}
or
public void bluegrass() {
ActionContext ac = typeOfThreadLocal.getFromSomeWhere();
/* ... */
}
then you need to handle absurdities like so (the general case )
public void bluegrass( A a, B b, ... ActionContext ac, ... Y y, Z z ) { /*
... */}
Also remember we have the chain of responsible stuff and the
Struts action extension to factor, which most developer
haven't even use yet in real anger, into a new version of
Struts 2. Proviso backwards compatibility
>
> 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 intgetAge();
>
> 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
> }
> }
>
> 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.
>
> (2) The attributes are stubbed out for implementation
> like done in Tapestry. This allows the type-checking
> at runtime found in ActionForms (important to me) with
> the flexibility of defining forms like DynaActionForms
> (used heavily by me).
>
> (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???
>
> Thanks guys.
====
--
Peter Pilgrim :: J2EE Software Development
Operations/IT - Credit Suisse First Boston,
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
==
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.csfb.com/legal_terms/disclaimer_external_email.shtml
==
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
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 intgetAge();
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
Frank,
I am fond of these two ideas (see following). Heck, I
would be willing to even write them if I think there
would be a chance of someone actually commiting them
into the Trunk!!
There are four things that I am very fond of and they
are all tightly integrated:
(1) POJO for forms
(2) Stubbing of abstract attributes for framework
implementation like Tapestry.
(3) The use of native data types in forms without
worrying of validation.
(4) Action methods being part of the POJO.
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 intgetAge();
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
}
}
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.
(2) The attributes are stubbed out for implementation
like done in Tapestry. This allows the type-checking
at runtime found in ActionForms (important to me) with
the flexibility of defining forms like DynaActionForms
(used heavily by me).
(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???
Thanks guys.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
> I think there are a lot of people out there who feel as you do, but > backwards-compatibility has always been a major theme for those While backwards compatibility is nice, I would rather see a better framework for the 2.x release. My personal opinion is that version compatibility should be required between point releases, but all bets are off for major revisions. Since we're offering suggestions, I would like to see a simplified configuration, or none at all, like Wicket. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STRUTS 2X]: Ideas
Paul, Do you have any specific ideas? I think there are a lot of people out there who feel as you do, but backwards-compatibility has always been a major theme for those stewarding Struts, and rightly so I think, and many of the "revolutionary" ideas that have been discussed or could be discussed would necasserily run contrary to that goal. The alternative is a lot of code bloat to support the new features and do it without breaking compatibility, and I doubt too many would be thrilled with that approach. Since I asked if you have any specific ideas, I'll throw one out there myself... One thing that I think JSF and some of the newer frameworks do well that Struts doesn't is deal with the presentation. Struts has a fairly robust set of tags that can help you if you are developing what I like to call a "classic" web app, that is, an app that doesn't rely on the client-side of things very much. Note that Struts doesn't do anything that STOPS you from developing a non-classic webapp yourself, just that it doesn't help you much. In this regard I think Shale is actually on the right track... I think a "modern" framework, which I define simply as one newer than Struts, should have more to say about the presentation, and more power and flexibility in that regard. I haven't been overly thrilled with JSF myself, but I do believe this is one area it does get it right, or at least more right than we have with Struts classic now. This is also an area where you probably could be a bit revolutionary without tearing up what exists now. In many ways this boils down to a more robust set of taglibs. Sure, there would likely be some things to be done in the core itself to support this, but I don't imagine it would be drastic, and maintaining backwards-compatibility probably wouldn't be quite as onerous. Frank Paul Benedict wrote: Hi guys, I have some ideas for some enhancements for Struts. I am glad we are moving along with 1.2.x and 1.3, but are we allowed to have discussion about the revolution of it too? I like to think that Ted Husted's Struts Jericho could get going soon. We have "Shale" (although I think JSF is not a fun product), but I think there are some really great aspects of JSF, Tapestry, and Spring that we could mimic in Struts and continue growing the code base into the future. These are just some initial ramblings. I'd like to see some best-of-breed architectures that we learned from frameworks over the past 3 years and include them in Struts. Some people say Struts is dying (or will die), but I think that will only happen if we don't make some intentionally revolutionary design decisions sometimes in the near future. OK. Hopefully I'll have something interesting responses to read ;-) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[STRUTS 2X]: Ideas
Hi guys, I have some ideas for some enhancements for Struts. I am glad we are moving along with 1.2.x and 1.3, but are we allowed to have discussion about the revolution of it too? I like to think that Ted Husted's Struts Jericho could get going soon. We have "Shale" (although I think JSF is not a fun product), but I think there are some really great aspects of JSF, Tapestry, and Spring that we could mimic in Struts and continue growing the code base into the future. These are just some initial ramblings. I'd like to see some best-of-breed architectures that we learned from frameworks over the past 3 years and include them in Struts. Some people say Struts is dying (or will die), but I think that will only happen if we don't make some intentionally revolutionary design decisions sometimes in the near future. OK. Hopefully I'll have something interesting responses to read ;-) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
