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]
