I take your points but I probably didn't express this very well - I was thinking more that in the same way that jsp is a standard java technolody and has its supporters/detractors - the same will probably be true of JSF. The jsp detractors don't like the jsp orientation even when Struts isn't actually tied to it - if its a "you have to use JSF" to use Struts what reaction is that going to get?
I guess that if the overwhelming majority of people want to use JSF, then its not really an issue - but at this point in time it isn't a given IMO. As I said I need try JSF out and this was only intended as an initial *musing*. Niall ----- Original Message ----- From: "Michael Rasmussen" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, October 26, 2004 7:03 PM Subject: Re: Struts Shale > > Some people already moan that struts is too jsp orientated with > > the tags that are included > > I'm not trying to tip the discussion in any direction here, but I > thought I would point out that JSF is "supposed" to be view agnostic. > Render kits are being built for WML, Swing, etc. I think that it is > safe to assume that JSF would move Struts AWAY from its jsp > orientation. > > > 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 Vie w > > 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] > > > > > > --------------------------------------------------------------------- > 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]
