I'm all for taking JSF faces strongly into account, but the proposal seems to be *JSF only* for the view tier - to the exclusion of all others. Since I haven't tried out JSF yet and therefore don't know enough about it that makes me uneasy.
Seems to me at this point that its early days to commit to a JSF only strategy. Some people already moan that struts is too jsp orientated with the tags that are included and I'm wondering what proportion of the exisiting Struts user base were going to loose/screw going that route? I guess in order to agree/disagree with this stratgey I need to go and actullay try JSF out. Niall ----- Original Message ----- From: "Sean Schofield" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, October 26, 2004 6:35 PM Subject: Re: Struts Shale > I'm +1 on JDK 1.4 (+0 on JDK 1.5). > > I also agree with Craig's sentiments on keeping things as simple as > possible and not reinventing what JSF (and other frameworks) can do > for you. > > The more I look at JSF, the more impressed I am with it. In many ways > it seems to be a signifcant improvement upon Struts but without the > restrictions on being backwards compatible. Not suprising since Craig > was key in both of these efforts ... > > I definitely feel that JSF should fit seemlessly into the new Shale > effort. Right now its a bit awkward integrating Struts and JSF. > That's to be expected because Struts was not designed with JSF in > mind. Going forward, however, I think we diminish the value of both > Struts and JSF if we don't take JSF strongly into account. > > From reading Craig's proposal and comment here, it sounds like that is > his goal. I just wanted to second that notion. > > sean > > > On Tue, 26 Oct 2004 09:34:07 -0700, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > Just time for a couple of notes this morning. > > > > I'm +0 on JDK 5.0 (nee 1.5) depending on how long we really think this > > is going to take. The "struts core" part of this isn't really huge or > > complicated, but asking a Struts developer for a timeline is probably > > a silly thing to do :-). > > > > Other comments inline. > > > > > > On Tue, 26 Oct 2004 09:42:27 -0400, Ted Husted <[EMAIL PROTECTED]> wrote: > > > > On Mon, 25 Oct 2004 04:56:45 +0000, [EMAIL PROTECTED] wrote: > > > >> URL: http://wiki.apache.org/struts/StrutsShale > > > > > > A few more more notes. > > > > > > > 2.4 View Controller > > > > 3.3 View (Presentation) Tier APIs > > > > Proposal:: JavaServer Faces 1.1 > > > > > > Does the View Controller need to be tied to JSF? > > > > > > Could the interface be agnostic and a FacesViewController be provided that is specific to JSF? > > > > > > Or, could there be a [org.apache.shale.faces] package, allowing room for, say, a [org.apache.shale.xlst] package or a [org.apache.shale.jstl] package or a [org.apache.shale.velocity] ? > > > > > > I'm not saying that we would have to provide all of these packages for Shale to be complete. I'd just like to position Struts 2.x so it could be everyone's controller :) -- if there are volunteers ready, willing, and able to make it so. > > > > The interface as currently defined is not dependent on JSF, nor need > > it be for its own purposes. Applications that implement a > > ViewController can stay *mostly* agnostic of the view tier technology, > > but you still have to decide at some point: > > > > * How do I bind my model data to my user interface "components"? > > (With JSF, you use value bindings on the components to > > properties in your view controller, and/or "binding" attributes > > to bind the actual component instances.) > > > > * How do I send error messages back to the user interface? > > (With JSF, you call FacesContext.addMessage().) > > > > * How do I initiate page navigation? (With JSF, the string outcome > > returned by an "action" method is fed through the page navigation > > rules you've configured to choose the next page, or "null" > > return means stay on the same page). > > > > All of those sorts of decisions have predefined answers in JSF, and > > abstracting them would require building infrastructure (into Struts > > Core) to bridge that gap into any other view tier technology you want, > > and/or reinventing a lot of what JSF (the managed beans, page > > navigation, and so on) already has. That's not an effort I'm > > interested in actually doing, and IMHO it would needlessly complicate > > the overall architecture -- but it's technically feasible. > > > > > > > > > 2.5 Functionality Not Included In Struts 2.0 Core > > > > > > Would any view packages be bundled with the 2.x core, or would the core be the Application controller and interfaces for the Dialog and View controllers (and any implementation-independent utilities). > > > > > > > My current view is that no view *components* would be included in the > > core -- although, if we accept the proposal to base the core on JSF > > for its infrastructure capabilities, we'd need to have a JSF > > implementation available (even if an alternative view technology was > > used for the actual presentation). The core would also include > > preregistration of JSF plugins like a custom ViewHandler that would > > actually implement the ViewHandler calling-in contracts (but that's > > invisible to people using it; JSF recognizes META-INF/faces-config.xml > > files inside a JAR at startup time to add stuff like this). > > > > It's clearly reasonable to distribute separate view tier packages, > > including things like useful components (the way MyFaces does) and/or > > extra goodies for things like validation. > > > > > > 2.5 Functionality Not Included In Struts 2.0 Core > > > > > > Since "client-side" validation is mentioned, are we leaving the door open for "server-side" validation? > > > > > > > My current view is that UI validation (as opposed to business rules > > that might require database lookups, like authenticating a user in a > > login screen) should be defined in the view tier. Whether it's > > implemented client side or server side (or both) is an implementation > > detail. Here's some options (again presuming a choice of JSF): > > > > * Standard JSF per-component validators (server side only for > > the standard components, but smarter components could do > > client side as well) > > > > * Special form tag component that hooks into an externally defined > > set of rules that enforce the rules both client and server side > > (this is what struts-faces does to hook into Commons Validator) > > > > * Special JSF ActionListener plugin (the part of JSF that receives > > submit buttons and decides what view controller to load, and what > > action method to call) that would hook in to the validator framework > > (this would work with the standard form component too) > > > > In none of the cases would the view controller's action method be > > called if there were validation errors (exactly analogous to how we > > don't call an Action if errors existed). > > > > > Perhaps as an abstract link in the request processing chain? > > > > The third option above is probably the most elegant, and would > > certainly lend itself to inserting an arbitrary request processing > > chain of your own, which could include validation or anything else you > > wanted to do solely on form submits (versus user interface events like > > expanding a node in a tree control, where the component changes state > > and just rerenders the page). > > > > > > > > Would there be an interface for the Application Controller? > > > > > > > Not sure. It could be as simple as a set of servlet filters that you > > configure together, or it could be some single filter (to make web.xml > > manipulation easier) that has a configuration file for the services > > that are defined at this level (perhaps driven by chains). > > > > > > [New topic] 2.6 Unit Tests > > > > > > Would it be all right if I contributed some unit tests to the codebase accompanying the proposal? > > > > > > > Absolutely. There's an empty spot in SVN ("src/test") just waiting > > for this kind of thing to be added. > > > > In fact, I'd like to go one further in the big picture -- I'd like us > > to include unit tests in any example application that we ship, so that > > we can demonstrate best practices for unit testing a Struts-based > > appication. > > > > This will also show off one particular architectural change that > > Struts 1.x gets knocked for -- it's much easier to unit test a view > > controller ... all your test framework has to do is call into the bean > > in the right order -- no mocks unless you need to deal with error > > messages (and we might want to set up an abstraction to make that > > easier too). > > > > > I realize that everything is subject to change, and the tests would have be resynched with any changes, but I'm up for that :) > > > > > > Obviously, the tests would not be much at this point, but I want to be sure we start out on the right foot. > > > > > > > +1 on being aggressive about unit testing the framework itself (and > > apps, as described above). > > > > > > 3.8 Logging APIs > > > > > > Proposal: Commons Logging > > > > > > +1 > > > > > > > Craig > > > > > > > > > > > > > > On Tue, 26 Oct 2004 01:14:40 -0400, Ted Husted wrote: > > > >> 3.1 Java2 Standard Edition APIs > > > >> > > > > I'd be +1 for J2SE 5.0 > > > > > > > > * http://java.sun.com/j2se/1.5.0/index.jsp > > > > > > > > Since Struts 1.x is in evolutionary mode, we might as well start > > > > the revolution based on the latest and greatest. We'd then be able > > > > to "take advantage of annotations, generics, and all that". From > > > > the traffic on the list, I have the feeling many of us have JDK 5.0 > > > > itches. I'm getting one myself :) > > > > > > > > As Apache Beehive reasoned, by the time we are done, it will be > > > > widely deployed. If we both base our work on JDK 5.0, we might help > > > > that become a self-fulfilling prophesy :) > > > > > > > > > > > >> 3.5 Service Provisioning APIs > > > >> From my research so far, I like Spring's capabilities in this > > > >> area the best, but am open to other suggestions. > > > >> > > > > +1 > > > > > > > > > > > > On Mon, 25 Oct 2004 04:56:45 +0000, [EMAIL PROTECTED] wrote: > > > > > > > >> Date: 2004-10-24T21:56:45 > > > >> Editor: CraigMcClanahan <[EMAIL PROTECTED]> > > > >> Wiki: Apache Struts Wiki > > > >> Page: StrutsShale > > > >> URL: http://wiki.apache.org/struts/StrutsShale > > > >> > > > >> Pointers to information about the "Shale" proposal > > > >> > > > >> New Page: > > > >> > > > >> This is a proposal for an overall architecture for Struts 2.0, > > > >> based on dividing the controller tier into > > > >> modular layers, and dramatically increasing the usability of the > > > >> controller functionality. > > > >> > > > >> * [http://svn.apache.org/viewcvs.cgi/*checkout* > > > >> /struts/trunk/contrib/struts-shale/README.html Proposal Details] > > > >> (latest SVN version) > > > >> * [http://www.apache.org/~craigmcc/struts-shale/ API Javadocs] > > > >> (periodically updated) > > > >> > > > >> > > > >> ------------------------------------------------------------------ > > > >> -- - To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -------------------------------------------------------------------- > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > > > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
