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]
