You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2004/10/26 07:14:40 UTC
Struts Shale
> 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, dev@struts.apache.org wrote:
> Date: 2004-10-24T21:56:45
> Editor: CraigMcClanahan <cr...@apache.org>
> 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: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Joe Germuska <Jo...@Germuska.com>.
At 5:32 PM +0100 10/26/04, Niall Pemberton wrote:
>I'm +1 for 1.5 as well, but from memory I believe there were people who
>didn't want to be that bleeding edge.
Or those who use a lovely operating system whose own Tiger release is
still several months away, with no plans for Java 5.0 support before
then...
I love Mac OS X, but really wish Apple could close the Java gap a bit.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place."
- Carlos Santana
Re: Struts Shale
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
I'm +1 for 1.5 as well, but from memory I believe there were people who
didn't want to be that bleeding edge.
Niall
----- Original Message -----
From: "James Mitchell" <jm...@apache.org>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Tuesday, October 26, 2004 4:16 PM
Subject: Re: Struts Shale
> I would be +1 for 1.5 as well
>
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
>
> ----- Original Message -----
> From: "Ted Husted" <hu...@apache.org>
> To: "Struts Developers List" <de...@struts.apache.org>
> Sent: Tuesday, October 26, 2004 1:14 AM
> Subject: Struts Shale
>
>
> > 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, dev@struts.apache.org wrote:
> > Date: 2004-10-24T21:56:45
> > Editor: CraigMcClanahan <cr...@apache.org>
> > 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: dev-unsubscribe@struts.apache.org For
> > additional commands, e-mail: dev-help@struts.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by James Mitchell <jm...@apache.org>.
I would be +1 for 1.5 as well
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Tuesday, October 26, 2004 1:14 AM
Subject: Struts Shale
> 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, dev@struts.apache.org wrote:
> Date: 2004-10-24T21:56:45
> Editor: CraigMcClanahan <cr...@apache.org>
> 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: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Eddie Bush <ea...@swbell.net>.
Struts (the controller) is pretty view agnostic as it sits now (unless
there's been some change of which I am unaware). There are even non-http
methods so that it can be used outside of a web application. I believe some
folks have actually even done this.
Struts does provide a lot to facilitate rendering a JSP view, but that's
just because that's what's main-stream. There are "kits" to have Struts
render to other views.
I am a little nervous about using a JDK 1.5 base. I'd like to use this once
there's a GA release, and I - being realistic and pragmatic - am not certain
the company I work for will be running things on such a platform.
I'm 250% for JDK 1.4 and Servlet spec 2.4 / JSP 2.0. That gives us a myriad
of tools to use we haven't had at our disposal before now and also sets what
I believe is realistically a possible common platform that folks will have
available to use this when we do hit GA.
If someone can convince me otherwise, I'd be happy to get behind the
1.5/5.0/?.?? band-wagon and hop on. Maybe I'll hit-up our farm-management
guys and see what their expectations are for the next year.
2 cents, 4 cents, 6 cents ... a dollar! er ... maybe not :-)
Eddie
----- Original Message -----
From: "Michael Rasmussen" <ra...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Tuesday, October 26, 2004 1: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
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0444-0, 10/26/2004
Tested on: 10/26/2004 6:00:09 PM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Sorry, I had not received Niall's email when this was sent.
Michael McGrady wrote:
> If Niall is right that JSF is a required aspect of the proposals, I
> would agree with him. This is not a negative toward JSF in any sense.
> The jury in my head is out on that one and is finding some nice things
> there. However, I do think that choices are excellent in any
> framework. And, so, I think that the ability to put in one's own
> controller, which I think is there, is important. Is Niall right on
> this? I had thought he was not.
>
> Michael McGrady
>
> Niall Pemberton wrote:
>
>> 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"
>> <ra...@gmail.com>
>> To: "Struts Developers List" <de...@struts.apache.org>
>> 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" <se...@gmail.com>
>>>> To: "Struts Developers List" <de...@struts.apache.org>;
>>>>
>>>
>> <cr...@apache.org>
>>
>>
>>>> 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
>>>>>
>>>>
>> <cr...@gmail.com>
>>
>>
>>>> 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 <hu...@apache.org>
>>>>>>
>>>>>
>>>> wrote:
>>>>
>>>>
>>>>>>>> On Mon, 25 Oct 2004 04:56:45 +0000, dev@struts.apache.org 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, dev@struts.apache.org wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Date: 2004-10-24T21:56:45
>>>>>>>>> Editor: CraigMcClanahan <cr...@apache.org>
>>>>>>>>> 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: dev-unsubscribe@struts.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>> --------------------------------------------------------------------
>>>
>>>
>>>>>>>> - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>>>>>>>> additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>>
>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>>
>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
If Niall is right that JSF is a required aspect of the proposals, I
would agree with him. This is not a negative toward JSF in any sense.
The jury in my head is out on that one and is finding some nice things
there. However, I do think that choices are excellent in any
framework. And, so, I think that the ability to put in one's own
controller, which I think is there, is important. Is Niall right on
this? I had thought he was not.
Michael McGrady
Niall Pemberton wrote:
>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" <ra...@gmail.com>
>To: "Struts Developers List" <de...@struts.apache.org>
>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" <se...@gmail.com>
>>>To: "Struts Developers List" <de...@struts.apache.org>;
>>>
>>>
><cr...@apache.org>
>
>
>>>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
>>>>
>>>>
><cr...@gmail.com>
>
>
>>>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 <hu...@apache.org>
>>>>>
>>>>>
>>>wrote:
>>>
>>>
>>>>>>>On Mon, 25 Oct 2004 04:56:45 +0000, dev@struts.apache.org 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, dev@struts.apache.org wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Date: 2004-10-24T21:56:45
>>>>>>>>Editor: CraigMcClanahan <cr...@apache.org>
>>>>>>>>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: dev-unsubscribe@struts.apache.org
>>>>>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>--------------------------------------------------------------------
>>
>>
>>>>>>>- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>>>>>>>additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>---------------------------------------------------------------------
>>
>>
>>>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>---------------------------------------------------------------------
>>
>>
>>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>
>>>
>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
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" <ra...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>
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" <se...@gmail.com>
> > To: "Struts Developers List" <de...@struts.apache.org>;
<cr...@apache.org>
> > 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
<cr...@gmail.com>
> > 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 <hu...@apache.org>
> > wrote:
> > > > > > On Mon, 25 Oct 2004 04:56:45 +0000, dev@struts.apache.org 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, dev@struts.apache.org wrote:
> > > > > >
> > > > > >> Date: 2004-10-24T21:56:45
> > > > > >> Editor: CraigMcClanahan <cr...@apache.org>
> > > > > >> 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: dev-unsubscribe@struts.apache.org
> > > > > >> For additional commands, e-mail: dev-help@struts.apache.org
> > > > > >
> > > > > >
> > > > >
> --------------------------------------------------------------------
> > > > > > - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> > > > > > additional commands, e-mail: dev-help@struts.apache.org
> > > > >
> > > > >
> > > >
> ---------------------------------------------------------------------
> > > > >
> > > > >
> > > > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > > >
> > > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > >
> > > >
> > > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> >
> >
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Michael Rasmussen <ra...@gmail.com>.
> 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" <se...@gmail.com>
> To: "Struts Developers List" <de...@struts.apache.org>; <cr...@apache.org>
> 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 <cr...@gmail.com>
> 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 <hu...@apache.org>
> wrote:
> > > > > On Mon, 25 Oct 2004 04:56:45 +0000, dev@struts.apache.org 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, dev@struts.apache.org wrote:
> > > > >
> > > > >> Date: 2004-10-24T21:56:45
> > > > >> Editor: CraigMcClanahan <cr...@apache.org>
> > > > >> 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: dev-unsubscribe@struts.apache.org
> > > > >> For additional commands, e-mail: dev-help@struts.apache.org
> > > > >
> > > > >
> > > > > --------------------------------------------------------------------
> > > > > - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> > > > > additional commands, e-mail: dev-help@struts.apache.org
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > >
> > > >
> > > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > >
> > >
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Eddie Bush <ea...@swbell.net>.
JSF is view agnostic isn't it? Plus, it's going to into the 5.0 spec, so
... with Struts having such a strong history of making use of industry
standards and best-practice approaches, doesn't it seem logical any
"revolutionary" new release would utilize JSF?
I've not looked at JSF enough to know what it can('t) do for me, but what
little I do know gives me warm fuzzies. I think it'd be serious overkill
for a simple web app though.
Perhaps what we ought to do is continue to let the 1.x and 2.x code-bases
evolve independent of one another. I know Martin (I believe it was Martin)
voiced some sentiment against this, but I think a Struts 1.x framework could
have a home in developers' toolboxes for some time yet.
Eddie
----- Original Message -----
From: "Joe Germuska" <Jo...@Germuska.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Tuesday, October 26, 2004 1:04 PM
Subject: Re: Struts Shale
> At 7:02 PM +0100 10/26/04, Niall Pemberton wrote:
>>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.
>
> I don't think that's true. In order to disagree with this strategy,
> you need to be interested enough in some non JSF view tier to find it
> worthwhile to give Struts an adapter that works with JSF as well as
> non JSF view technologies.
>
> Although I'm a JSP user and interested in JSF, I'm also interested in
> trying to keep Struts more view-agnostic. I understand Craig's point
> about reinventing APIs that JSF already has (and his personal
> disinterest in doing that work) so I need to have a better handle on
> what all that would take before I agree or disagree with the strategy.
>
> I would definitely endorse designing to take full advantage of ideas
> gained from JSF, and as we move towards that, we should get a better
> idea of what it would take to abstract away from a JSF dependency --
> then we can see who's willing to do it!
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
> back; I'll know I'm in the wrong place."
> - Carlos Santana
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0444-0, 10/26/2004
Tested on: 10/26/2004 6:04:38 PM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Joe Germuska <Jo...@Germuska.com>.
At 7:02 PM +0100 10/26/04, Niall Pemberton wrote:
>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.
I don't think that's true. In order to disagree with this strategy,
you need to be interested enough in some non JSF view tier to find it
worthwhile to give Struts an adapter that works with JSF as well as
non JSF view technologies.
Although I'm a JSP user and interested in JSF, I'm also interested in
trying to keep Struts more view-agnostic. I understand Craig's point
about reinventing APIs that JSF already has (and his personal
disinterest in doing that work) so I need to have a better handle on
what all that would take before I agree or disagree with the strategy.
I would definitely endorse designing to take full advantage of ideas
gained from JSF, and as we move towards that, we should get a better
idea of what it would take to abstract away from a JSF dependency --
then we can see who's willing to do it!
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place."
- Carlos Santana
RE: Struts Shale
Posted by Anders Steinlein <an...@steinlein.no>.
I have to agree with Craig here. Although I haven't used JSF that much
yet, I have investigated it enough to understand its basic infrastructure
and functionality. As Craig said, it would require much work to abstract
the same functionality in to Struts, where it is already available in JSF
(such as view navigation).
One of my personal wishes for Struts 2.x (and I would love to volunteer)
is a smooth and clear integration with JSF. Many people are confused about
how JSF fits in with frameworks such as Struts (and webapps in general),
and this would be a great opportunity to clear that up once and for all.
Besides, it would put us in a good position marketing-wise, as there
aren't currently any frameworks (to mine knowledge anyway) utilizing JSF
in this manner. Shale should then focus on adding neat features "outside"
of what JSF already does.
I do wonder about one thing though - how would portlets fit into all this?
I know next to nothing about portlets, except that I feel it should be
supported out-of-the-box in Struts 2.x. Could JSF be used in that regard?
Regards,
\Anders
> -----Original Message-----
> From: Craig McClanahan [mailto:craigmcc@gmail.com]
> Sent: 28. oktober 2004 19:40
> To: Dakota Jack; Struts Developers List
> Subject: Re: Struts Shale
>
> I think that's Ted's basic point.
>
> My answer is to consider how much extra machinery you have to
> build in to the Struts abstraction of what a ViewController
> is so that an application built on top of Struts can use
> different technologies.
>
> Just as one example out of my list from the previous email
> ... how does a ViewController say "I want to switch to a new
> view"? With JSF that's easy ... support for navigation is
> built in based on the string value that's returned by your
> action mapping, which is processed through the navigation
> rules that you've defined in faces-config.xml to pick the
> next view. Without JSF, someone is going to have to build in
> a way for a ViewController to ask for that -- and that's
> redundant work.
>
> Part of the potential confusion here is based on the fact
> that JSF isn't just a dynamic rendering technology. Indeed,
> JSF itself is agnostic whether you want to use JSP pages or
> Velocity (although you'll need to provide your own
> ViewHandler plugin for the latter case, but it's not tough to
> write one). The key difference is that JSF already has a
> well defined request processing lifecycle built in, following
> the Front Controller design pattern in a manner fairly
> similar to the way that Struts currently works. I want to
> leverage that instead of abstracting it out or reinventing it
> -- JSF's already good enough.
>
> Craig
>
> On Thu, 28 Oct 2004 10:23:37 -0700, Dakota Jack
> <cr...@gmail.com> wrote:
> > Why is it not possible for the framework to use interfaces
> into which
> > JSF can be plugged in, perhaps with adapters, as an option well as
> > other alternatives? This too is not a rhetorical question.
> >
> > Jack
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Craig McClanahan <cr...@gmail.com>.
I think that's Ted's basic point.
My answer is to consider how much extra machinery you have to build in
to the Struts abstraction of what a ViewController is so that an
application built on top of Struts can use different technologies.
Just as one example out of my list from the previous email ... how
does a ViewController say "I want to switch to a new view"? With JSF
that's easy ... support for navigation is built in based on the string
value that's returned by your action mapping, which is processed
through the navigation rules that you've defined in faces-config.xml
to pick the next view. Without JSF, someone is going to have to build
in a way for a ViewController to ask for that -- and that's redundant
work.
Part of the potential confusion here is based on the fact that JSF
isn't just a dynamic rendering technology. Indeed, JSF itself is
agnostic whether you want to use JSP pages or Velocity (although
you'll need to provide your own ViewHandler plugin for the latter
case, but it's not tough to write one). The key difference is that
JSF already has a well defined request processing lifecycle built in,
following the Front Controller design pattern in a manner fairly
similar to the way that Struts currently works. I want to leverage
that instead of abstracting it out or reinventing it -- JSF's already
good enough.
Craig
On Thu, 28 Oct 2004 10:23:37 -0700, Dakota Jack <cr...@gmail.com> wrote:
> Why is it not possible for the framework to use interfaces into which
> JSF can be plugged in, perhaps with adapters, as an option well as
> other alternatives? This too is not a rhetorical question.
>
> Jack
>
>
>
>
> On Thu, 28 Oct 2004 10:16:56 -0700, Craig McClanahan <cr...@gmail.com> wrote:
> >
> >
> > On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted <hu...@apache.org> wrote:
> > > On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote:
> > > > My personal itch is to not have to build everything from scratch --
> > > > its to build on the JSF request processing lifecycle, without
> > > > committing you to any particular view tier templating approach.
> > > > Doing more work than that is ... more work.
> > >
> > > Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale.
> > >
> > > For example, instead of an "impl" folder, could we have a "faces" folder?
> > >
> >
> > I don't see the point in doing this now -- if a reasonable non-JSF
> > approach is shown to be viable and accepted by the community we can
> > always do it later. I haven't seen enough yet to make me think this
> > is viable without compromising the simplicity of the current approach.
> >
> > > And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the "abstract" responsibilities of the interface and what happens when an ViewController implementation is wired to JSF?
> >
> > Abstracting when the init/prepare/destroy methods are called and what
> > they do would not be that hard, although you're going to need a bunch
> > of things to make ViewController actually usable without presuming
> > JSF:
> >
> > * The notion of a "view identifier" that maps to both the
> > view tier presentation (typically a JSP page) and the
> > corresponding ViewController class.
> >
> > * A mechanism for performing validations and handling
> > validation error messages.
> >
> > * Some method that gets invoked when, say, a submit
> > button is pressed that triggers your business logic.
> >
> > * A mechanism for a ViewController to request that its own
> > view get redisplayed, or to navigate to a different view id.
> >
> > All of the above are already provided by JSF, but necessary in a non-JSF world.
> >
> > Basically, I'm really curious how you propose to abstract out the
> > "Standard JSF processing and event handling is performed" part without
> > essentially re-inventing a JSF-like lifecycle. If you try to impose
> > those abstractions onto the basic ViewController API then I would
> > likely be -1 because they are redundant to using the framework *with*
> > JSF. You could create a NonFacesViewController abstraction on top of
> > ViewController if you wanted, but by that point we might as well
> > create two separate frameworks instead of one.
> >
> > >
> > > -Ted.
> > >
> > >
> >
> > Craig
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> --
> "You can't wake a person who is pretending to be asleep."
>
> ~Native Proverb~
>
> "Each man is good in His sight. It is not necessary for eagles to be crows."
>
> ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Dakota Jack <cr...@gmail.com>.
Why is it not possible for the framework to use interfaces into which
JSF can be plugged in, perhaps with adapters, as an option well as
other alternatives? This too is not a rhetorical question.
Jack
On Thu, 28 Oct 2004 10:16:56 -0700, Craig McClanahan <cr...@gmail.com> wrote:
>
>
> On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted <hu...@apache.org> wrote:
> > On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote:
> > > My personal itch is to not have to build everything from scratch --
> > > its to build on the JSF request processing lifecycle, without
> > > committing you to any particular view tier templating approach.
> > > Doing more work than that is ... more work.
> >
> > Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale.
> >
> > For example, instead of an "impl" folder, could we have a "faces" folder?
> >
>
> I don't see the point in doing this now -- if a reasonable non-JSF
> approach is shown to be viable and accepted by the community we can
> always do it later. I haven't seen enough yet to make me think this
> is viable without compromising the simplicity of the current approach.
>
> > And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the "abstract" responsibilities of the interface and what happens when an ViewController implementation is wired to JSF?
>
> Abstracting when the init/prepare/destroy methods are called and what
> they do would not be that hard, although you're going to need a bunch
> of things to make ViewController actually usable without presuming
> JSF:
>
> * The notion of a "view identifier" that maps to both the
> view tier presentation (typically a JSP page) and the
> corresponding ViewController class.
>
> * A mechanism for performing validations and handling
> validation error messages.
>
> * Some method that gets invoked when, say, a submit
> button is pressed that triggers your business logic.
>
> * A mechanism for a ViewController to request that its own
> view get redisplayed, or to navigate to a different view id.
>
> All of the above are already provided by JSF, but necessary in a non-JSF world.
>
> Basically, I'm really curious how you propose to abstract out the
> "Standard JSF processing and event handling is performed" part without
> essentially re-inventing a JSF-like lifecycle. If you try to impose
> those abstractions onto the basic ViewController API then I would
> likely be -1 because they are redundant to using the framework *with*
> JSF. You could create a NonFacesViewController abstraction on top of
> ViewController if you wanted, but by that point we might as well
> create two separate frameworks instead of one.
>
> >
> > -Ted.
> >
> >
>
> Craig
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted <hu...@apache.org> wrote:
> On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote:
> > My personal itch is to not have to build everything from scratch --
> > its to build on the JSF request processing lifecycle, without
> > committing you to any particular view tier templating approach.
> > Doing more work than that is ... more work.
>
> Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale.
>
> For example, instead of an "impl" folder, could we have a "faces" folder?
>
I don't see the point in doing this now -- if a reasonable non-JSF
approach is shown to be viable and accepted by the community we can
always do it later. I haven't seen enough yet to make me think this
is viable without compromising the simplicity of the current approach.
> And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the "abstract" responsibilities of the interface and what happens when an ViewController implementation is wired to JSF?
Abstracting when the init/prepare/destroy methods are called and what
they do would not be that hard, although you're going to need a bunch
of things to make ViewController actually usable without presuming
JSF:
* The notion of a "view identifier" that maps to both the
view tier presentation (typically a JSP page) and the
corresponding ViewController class.
* A mechanism for performing validations and handling
validation error messages.
* Some method that gets invoked when, say, a submit
button is pressed that triggers your business logic.
* A mechanism for a ViewController to request that its own
view get redisplayed, or to navigate to a different view id.
All of the above are already provided by JSF, but necessary in a non-JSF world.
Basically, I'm really curious how you propose to abstract out the
"Standard JSF processing and event handling is performed" part without
essentially re-inventing a JSF-like lifecycle. If you try to impose
those abstractions onto the basic ViewController API then I would
likely be -1 because they are redundant to using the framework *with*
JSF. You could create a NonFacesViewController abstraction on top of
ViewController if you wanted, but by that point we might as well
create two separate frameworks instead of one.
>
> -Ted.
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fwd: Struts Shale
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 28 Oct 2004 14:30:33 -0400, Ted Husted <hu...@apache.org> wrote:
> On Thu, 28 Oct 2004 13:57:15 -0400, Ted Husted wrote:
> > ... that we rename the package called "impl" as "faces".
>
> As to the impl package:
>
> I think what really bothers me here is that the classes implemented here are not part of the Shale API. As soon as I saw ImplViewHandler, I starting looking around for a Shale ViewHandler interface. :) Of course, it is not a Shale interface, but a Faces interface. So far, all of the members here extend Faces interfaces or classes.
>
> To me, "impl" says we're implementing the interfaces for the Shale layer (rather than the Faces layer).
>
> Naming this package "faces" clarifies that it contains classes that are dependant on the lower-level Faces API, as opposed to the higher-level Shale API.
>
> What I would suggest is that we call the package "faces", and the member classes:
>
> * "ShaleApplicationFilter"
> * "ShaleConstants"
> * "ShalePhaseListener"
> * "ShaleViewHandler"
>
> I'm thinking that in an import statement
>
> * org.apache.shale.ViewController
> * org.apache.shale.faces.ShaleApplicationFilter
>
> would clearly say who's riding whom.
>
Yah, I can buy that argument. Feel free to refactor.
By the way, I'm about 50% done with making mailreader work just on top
of ViewController (i'll refactor my imports as needed when you make
those changes). That will give us a starting point for seeing what
applications built on this thing could look like - even without all
the dialog and application level stuff.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fwd: Struts Shale
Posted by Craig McClanahan <cr...@gmail.com>.
I haven't personally tried to think of Shale as a general purpose
adapter for between remote clients and server side business objects.
I'm not sure there's really a need for one, either. Here's a really
primitive ASCII Art picture of how I look at it:
Browser Client --> WebApp Server ---\
\
Web Services Client --> WebServices Server --> ServiceLocator -->
BusinessLogic
/
JMX Remote Client --> JMX Server ---/
Where JSF+Shale would be used in the "WebApp Server" role, and you'd
use something JAX-RPC based for the "WebServices Server" and JMX
Remoting for the "JMX Server".
You can certainly share a ServiceLocator implementation (perhaps based
on an IoC framework, perhaps based on EJBs, or whatever you want)
between the various servers ... but I don't think that the APIs for
such a thing need to be baked into the APIs for the front end server
that is primarily acting as an adapter.
The technology choice for the ServiceLocator and BusinessLogic should
be up to the application architect, not the architect of the front
controller framework.
That being said, the fact that these three technologies all use HTTP
means you could really coexist in a single web application if you
wanted to. My gut says that this woud be more fragile than an
environment where the app for each incoming technology is deployed
independently (and upgraded on their own schedules as needed, and
deployed on different hardware depending on volume, etc.), so I don't
think it is something we would want to encourage. But sharing the
back end processing is certainly a good idea.
Craig
On Thu, 28 Oct 2004 13:02:56 -0600, BaTien Duong
<ba...@dbgroups.com> wrote:
> Ted Husted wrote:
>
> >On Thu, 28 Oct 2004 13:57:15 -0400, Ted Husted wrote:
> >
> >
> >> ... that we rename the package called "impl" as "faces".
> >>
> >>
> >
> >As to the impl package:
> >
> >I think what really bothers me here is that the classes implemented here are not part of the Shale API. As soon as I saw ImplViewHandler, I starting looking around for a Shale ViewHandler interface. :) Of course, it is not a Shale interface, but a Faces interface. So far, all of the members here extend Faces interfaces or classes.
> >
> >To me, "impl" says we're implementing the interfaces for the Shale layer (rather than the Faces layer).
> >
> >
> >
> Greetings:
>
> I have not had a chance to look at the Shale API yet, but i already play
> around with the idea of controller and adapters. To me, the view handler
> (either you use JSF which is available now or future framework) is only
> 1 part of the adapters to manage services that use HTTP/HTTPS ports.
> Other services that use the ports are WebService, WebDAV, JMXRemote.
>
> It makes sense for Shale API to handle all standard services using
> HTTP/HTTPS by providing a centralized service requester and service
> router that routes the incoming services to appropriate adapter (view
> adapter for browser and mobile devices, webService adapter, webDAV
> adapter and JMXRemote adapter). Is there any one thinking along this line?
>
> BaTien
> DBGROUPS
>
>
>
> >Naming this package "faces" clarifies that it contains classes that are dependant on the lower-level Faces API, as opposed to the higher-level Shale API.
> >
> >What I would suggest is that we call the package "faces", and the member classes:
> >
> >* "ShaleApplicationFilter"
> >* "ShaleConstants"
> >* "ShalePhaseListener"
> >* "ShaleViewHandler"
> >
> >I'm thinking that in an import statement
> >
> >* org.apache.shale.ViewController
> >* org.apache.shale.faces.ShaleApplicationFilter
> >
> >would clearly say who's riding whom.
> >
> >-Ted.
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >.
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fwd: Struts Shale
Posted by BaTien Duong <ba...@dbgroups.com>.
Ted Husted wrote:
>On Thu, 28 Oct 2004 13:57:15 -0400, Ted Husted wrote:
>
>
>> ... that we rename the package called "impl" as "faces".
>>
>>
>
>As to the impl package:
>
>I think what really bothers me here is that the classes implemented here are not part of the Shale API. As soon as I saw ImplViewHandler, I starting looking around for a Shale ViewHandler interface. :) Of course, it is not a Shale interface, but a Faces interface. So far, all of the members here extend Faces interfaces or classes.
>
>To me, "impl" says we're implementing the interfaces for the Shale layer (rather than the Faces layer).
>
>
>
Greetings:
I have not had a chance to look at the Shale API yet, but i already play
around with the idea of controller and adapters. To me, the view handler
(either you use JSF which is available now or future framework) is only
1 part of the adapters to manage services that use HTTP/HTTPS ports.
Other services that use the ports are WebService, WebDAV, JMXRemote.
It makes sense for Shale API to handle all standard services using
HTTP/HTTPS by providing a centralized service requester and service
router that routes the incoming services to appropriate adapter (view
adapter for browser and mobile devices, webService adapter, webDAV
adapter and JMXRemote adapter). Is there any one thinking along this line?
BaTien
DBGROUPS
>Naming this package "faces" clarifies that it contains classes that are dependant on the lower-level Faces API, as opposed to the higher-level Shale API.
>
>What I would suggest is that we call the package "faces", and the member classes:
>
>* "ShaleApplicationFilter"
>* "ShaleConstants"
>* "ShalePhaseListener"
>* "ShaleViewHandler"
>
>I'm thinking that in an import statement
>
>* org.apache.shale.ViewController
>* org.apache.shale.faces.ShaleApplicationFilter
>
>would clearly say who's riding whom.
>
>-Ted.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fwd: Struts Shale
Posted by Ted Husted <hu...@apache.org>.
On Thu, 28 Oct 2004 13:57:15 -0400, Ted Husted wrote:
>�... that we rename the package called "impl" as "faces".
As to the impl package:
I think what really bothers me here is that the classes implemented here are not part of the Shale API. As soon as I saw ImplViewHandler, I starting looking around for a Shale ViewHandler interface. :) Of course, it is not a Shale interface, but a Faces interface. So far, all of the members here extend Faces interfaces or classes.
To me, "impl" says we're implementing the interfaces for the Shale layer (rather than the Faces layer).
Naming this package "faces" clarifies that it contains classes that are dependant on the lower-level Faces API, as opposed to the higher-level Shale API.
What I would suggest is that we call the package "faces", and the member classes:
* "ShaleApplicationFilter"
* "ShaleConstants"
* "ShalePhaseListener"
* "ShaleViewHandler"
I'm thinking that in an import statement
* org.apache.shale.ViewController
* org.apache.shale.faces.ShaleApplicationFilter
would clearly say who's riding whom.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fwd: Struts Shale
Posted by Ted Husted <hu...@apache.org>.
On Thu, 28 Oct 2004 10:20:45 -0700, Craig McClanahan wrote:
>�Ted can correct my understanding of his position if I'm wrong, but
>�basically he wants Struts to be view tier agnostic. �I'll agree
>�with that on the actual technology used to implement the dynamic
>�rendering (JSF lets you do that already), but not on abstracting
>�the entire request processing lifecycle. �JSF already provides a
>�solid foundation on which to build application level controller
>�facilities, and I see no point in re-inventing that part.
It's just my feeling that we should either leave the door open to non-JSF implementations of Shale, should someone want to do one.
I'm not saying that anyone will do an alternate implementation. But I do believe it would be helpful to distinguish where the top-level of the Shale API ends, and the JSF-based implementation begins. Or, in order words, to clearly define the value Shale adds to the JSF lifecycle.
At this point, I'm only suggesting that we (meaning I) try to document the view controller a little differently, and that we rename the package called "impl" as "faces".
I am absolutely and totally in favor of a lightweight framework that rides on top of JavaServer Faces. It's an excellent idea, and I do want to do whatever I can to help. Right now, I'm just trying to keep it clear in my own tiny mind where the rider ends and the horse begins.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Fwd: Struts Shale
Posted by Craig McClanahan <cr...@gmail.com>.
Oops ... meant to reply to both Jack and the list.
Craig
---------- Forwarded message ----------
From: Craig McClanahan <cr...@gmail.com>
Date: Thu, 28 Oct 2004 10:19:48 -0700
Subject: Re: Struts Shale
To: Dakota Jack <cr...@gmail.com>
On Thu, 28 Oct 2004 06:51:32 -0700, Dakota Jack <cr...@gmail.com> wrote:
> How could there be a reason not to do this? (This is not a rhetorical
> question.)
Ted can correct my understanding of his position if I'm wrong, but
basically he wants Struts to be view tier agnostic. I'll agree with
that on the actual technology used to implement the dynamic rendering
(JSF lets you do that already), but not on abstracting the entire
request processing lifecycle. JSF already provides a solid foundation
on which to build application level controller facilities, and I see
no point in re-inventing that part.
>
> Jack
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Dakota Jack <cr...@gmail.com>.
How could there be a reason not to do this? (This is not a rhetorical
question.)
Jack
On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted <hu...@apache.org> wrote:
> On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote:
> > My personal itch is to not have to build everything from scratch --
> > its to build on the JSF request processing lifecycle, without
> > committing you to any particular view tier templating approach.
> > Doing more work than that is ... more work.
>
> Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale.
>
> For example, instead of an "impl" folder, could we have a "faces" folder?
>
> And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the "abstract" responsibilities of the interface and what happens when an ViewController implementation is wired to JSF?
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Ted Husted <hu...@apache.org>.
On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote:
>�My personal itch is to not have to build everything from scratch --
>�its to build on the JSF request processing lifecycle, without
>�committing you to any particular view tier templating approach. �
>�Doing more work than that is ... more work.
Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale.
For example, instead of an "impl" folder, could we have a "faces" folder?
And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the "abstract" responsibilities of the interface and what happens when an ViewController implementation is wired to JSF?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Sean Schofield <se...@gmail.com>.
On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan <cr...@gmail.com> wrote:
> * The proposed Struts Core doesn't contain or use any
> JSF components -- it presumes the use of the infrastructure
> stuff (managed beans, expressions, navigation mapping,
> as well as the basic request processing lifecycle)
> that is darned useful, and would have to be reinvented
> by any non-JSF-based implementation anyway.
This makes complete sense to me. JSF seems to handle these things
really well so why reinvent the wheel on this?
JSF does seem to be picking up momentum as a standard. It will take a
while for sure, but if Craig is correct about it being part of J2EE
5.0, this will only hasten its adoption.
At some point it will not make sense to continue evolving Struts in
its current form. Bug fixes and minor tweaks are one thing, but we
don't want to be working at cross purposes. If JSF can handle x,y,
and z better then lets focus on what it doesn't handle very well.
> * Even if the core controller part of Struts was JSF-agnostic
> (except for an implementation of the APIs based on it),
> you still can't write an application on top of this without committing
> to a choice in view tier technology. The more stuff like how
> validation errors are propogated that we have to abstract in
> order to be JSF-agnostic, the more complicated we make
> the architecture; and the more code we have to wrte and fix
> and document and test.
I agree with this statement as well.
> * Finally, there's a "marketing" viewpoint :-). The world has changed
> since Struts was first developed, and there's so many frameworks
> out there that people get laughed at on TheServerSide etc. for
> creating YAWAF (yet another web application framework). Without
> some distinguishing characteristic, what (besides the "Struts"
> name) would we bring to the table that all the other non-JSF-specific
> frameworks already do?
I think this is a very important issue. If JSF does indeed catch on,
then the very first thing a perspective user will want to know about
Struts Shale is, "How does this work with JSF?" (Same as when JSF
came along and we all asked ourselves, "How does this fit in with
Struts?")
Let me summarize what I think Craig is suggesting. He and others can
correct me if I'm wrong:
1.) Forget about backwards compatability with Struts 1.x
2.) Focus exclusively on value added to JSF (even if the user
ultimately doesn't want to use JSF). This includes things like
"dialogs" and would focus primarily on the controller
3.) Design with an eye towards using it with JSF but with little (or
no) dependencies on it.
We could continue to develop Struts 1.x versions for the forseeable
future, but the real innovations would take place in Struts Shale.
Thus users who migrate from Struts to JSF, and users who never used
Struts and are starting with JSF, can use the new Struts Shale for the
extra goodies. Users who want no part in JSF and like the old Struts
framework can keep on with Struts 1.x (with the option to integrate
with JSF using struts-faces.)
> Craig
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Craig McClanahan <cr...@gmail.com>.
On Tue, 26 Oct 2004 11:48:33 -0700, Michael McGrady
<mi...@michaelmcgrady.com> wrote:
> Niall Pemberton wrote:
>
> >OK Craig didn't say it was "JSF only" - but that was my interpretation of
> >the likely direction.
> >
> >He said "The interface as currently defined is not dependent on JSF" but
> >then went on to say that JSF already solves a whole load of the view tier
> >issues and re-inventing them outside JSF is "...not an effort I'm interested
> >in actually doing, and IMHO it would needlessly complicate the overall
> >architecture -- but it's technically feasible."
> >
> >Niall
> >
>
> My understanding is that the interfaces will be optimized to a JSF
> "emphasis" but amenable to and sensitive to any other options nuts like
> myself might want to code. Is that right, Craig?
>
Let's look at this from a variety of perspectives:
* The proposed Struts Core doesn't contain or use any
JSF components -- it presumes the use of the infrastructure
stuff (managed beans, expressions, navigation mapping,
as well as the basic request processing lifecycle)
that is darned useful, and would have to be reinvented
by any non-JSF-based implementation anyway.
* JSF itself is bound to JSP substantially less than Struts is,
even though a JSF implementation is required to support JSP.
For example, if you like Tapestry's approach of a separate
HTML file containing markup with id attributes that correspond
to a component tree, that's a very straightforward thing to
implement -- indeed, Hans Bergsten's book gets you about
80% of the way there. Or, if you want to output WML or SVG
instead of HTML ... that's nothing the controller need concern
itself with -- just pick the correct JSF renderers.
* The same thing could be done for any other templating
technology that has some way to establish the data bindings
(Velocity macros, for example) and is accessible via
RequestDispatcher.forward() or a programmatic interface
to actually do the rendering.
I'd be OK with having a subproject lying around
that implemented one or more of these adapters
for view tier technologies; I can provide design
assistance but not much in the way of development
help due to time constraints.
* That being said, JSF goes far beyond just using templates,
because it provides a sophisticated component model (so
you can build things like tree controls and scrollable tables)
and an event model optimized for component oriented development.
Choosing a templating technology which forces you to give that
up seems to me a sub-optimal choice. But it could be done,
if we're willing to simulate the controller-level parts of JSF.
* Even if the core controller part of Struts was JSF-agnostic
(except for an implementation of the APIs based on it),
you still can't write an application on top of this without committing
to a choice in view tier technology. The more stuff like how
validation errors are propogated that we have to abstract in
order to be JSF-agnostic, the more complicated we make
the architecture; and the more code we have to wrte and fix
and document and test.
* JSF is going to be part of J2EE 5.0 anyway, so rumors of its
imminent demise are not credible :-).
* Indeed, Apache is currently incubating an open source
implementation (http://incubator.apache.org/projects/myfaces.html)
that will, naturally enough, be Apache licensed and suitable
for distribution (once it passes the compatibility tests).
* Finally, there's a "marketing" viewpoint :-). The world has changed
since Struts was first developed, and there's so many frameworks
out there that people get laughed at on TheServerSide etc. for
creating YAWAF (yet another web application framework). Without
some distinguishing characteristic, what (besides the "Struts"
name) would we bring to the table that all the other non-JSF-specific
frameworks already do?
My personal itch is to not have to build everything from scratch --
its to build on the JSF request processing lifecycle, without
committing you to any particular view tier templating approach. Doing
more work than that is ... more work.
> Michael McGrady
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Niall Pemberton wrote:
>OK Craig didn't say it was "JSF only" - but that was my interpretation of
>the likely direction.
>
>He said "The interface as currently defined is not dependent on JSF" but
>then went on to say that JSF already solves a whole load of the view tier
>issues and re-inventing them outside JSF is "...not an effort I'm interested
>in actually doing, and IMHO it would needlessly complicate the overall
>architecture -- but it's technically feasible."
>
>Niall
>
My understanding is that the interfaces will be optimized to a JSF
"emphasis" but amenable to and sensitive to any other options nuts like
myself might want to code. Is that right, Craig?
Michael McGrady
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Ted Husted <hu...@apache.org>.
On Tue, 26 Oct 2004 19:40:59 +0100, Niall Pemberton wrote:
> OK Craig didn't say it was "JSF only" - but that was my
> interpretation of the likely direction.
Something to consider is that we are not constrained to a single line of development.
We could proceed with Struts Shale as a subproject [org.apache.struts.shale], and see how it goes. If there's a way to bridge the gap between Struts 1.x and Shale, I'm sure someone will rush in to make it so. Meanwhile, people who are happy with Struts 1.x can continue evolving the tried-and-true codebase.
Shale does seems like a fine idea for a JSF framework, but it really doesn't have a "Struts 2.x" feel. In fact, calling it Struts 2.x might cause a lot of confusion, unless there is a very clear migration path. But, that doesn't mean we can't host Struts Shale alongside Struts 1.x.
We might also ask if our friends at Apache MyFaces would be interested in helping with Apache Shale, or even hosting the development. If this is going to be a JSF gizmo, and we are short of JSF developers here, perhaps Shale should live where more JSF developers hang out.
Of course, if MyFaces doesn't want to get into the framework business, we can host it here, and perhaps some MyFaces developers will join us here.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
OK Craig didn't say it was "JSF only" - but that was my interpretation of
the likely direction.
He said "The interface as currently defined is not dependent on JSF" but
then went on to say that JSF already solves a whole load of the view tier
issues and re-inventing them outside JSF is "...not an effort I'm interested
in actually doing, and IMHO it would needlessly complicate the overall
architecture -- but it's technically feasible."
Niall
----- Original Message -----
From: "Michael McGrady" <mi...@michaelmcgrady.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Tuesday, October 26, 2004 7:21 PM
Subject: Re: Struts Shale
> Niall Pemberton wrote:
>
> >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.
> >
>
> Is this correct? I did get that there was an optional controller with
> this sort of emphasis, but I read the proposal as allowing custom
> controllers to do pretty much whatever one wanted. Am I off the beam?
>
> Michael McGrady
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
Niall Pemberton wrote:
>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.
>
Is this correct? I did get that there was an optional controller with
this sort of emphasis, but I read the proposal as allowing custom
controllers to do pretty much whatever one wanted. Am I off the beam?
Michael McGrady
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
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" <se...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>; <cr...@apache.org>
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 <cr...@gmail.com>
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 <hu...@apache.org>
wrote:
> > > > On Mon, 25 Oct 2004 04:56:45 +0000, dev@struts.apache.org 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, dev@struts.apache.org wrote:
> > > >
> > > >> Date: 2004-10-24T21:56:45
> > > >> Editor: CraigMcClanahan <cr...@apache.org>
> > > >> 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: dev-unsubscribe@struts.apache.org
> > > >> For additional commands, e-mail: dev-help@struts.apache.org
> > > >
> > > >
> > > > --------------------------------------------------------------------
> > > > - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> > > > additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > >
> > >
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> >
> >
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Sean Schofield <se...@gmail.com>.
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 <cr...@gmail.com> 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 <hu...@apache.org> wrote:
> > > On Mon, 25 Oct 2004 04:56:45 +0000, dev@struts.apache.org 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, dev@struts.apache.org wrote:
> > >
> > >> Date: 2004-10-24T21:56:45
> > >> Editor: CraigMcClanahan <cr...@apache.org>
> > >> 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: dev-unsubscribe@struts.apache.org
> > >> For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> > > additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> > ---------------------------------------------------------------------
> >
> >
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Craig McClanahan <cr...@gmail.com>.
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 <hu...@apache.org> wrote:
> > On Mon, 25 Oct 2004 04:56:45 +0000, dev@struts.apache.org 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, dev@struts.apache.org wrote:
> >
> >> Date: 2004-10-24T21:56:45
> >> Editor: CraigMcClanahan <cr...@apache.org>
> >> 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: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> > additional commands, e-mail: dev-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Struts Shale
Posted by Anders Steinlein <an...@steinlein.no>.
> -----Original Message-----
> From: Craig McClanahan [mailto:craigmcc@gmail.com]
> On Fri, 29 Oct 2004 01:22:09 +0200, Anders Steinlein
> <an...@steinlein.no> wrote:
> >
> > Although I have no real saying in this, I am +1 on J2SE 5.0
> > as well. As I would anticipate 1-2 years in development on
> > Struts 2.x, J2SE 5.0 should be widely deployed by then. If
> > not, then our "endorsement" of it could encourage people to
> > make the switch. ;) Plus, it could stand as a marketing bonus
> > - in support of our "revolutionary" path.
>
> I sure hope it doesn't take us 1-2 years, but with our track
> record I'd be pretty foolish to make any promises at this point :-).
I sure doesn't hope so either. Besides, I suspect more people would like
to volunteer on a 2.x release to scratch some revolutionary itches and/or
understanding the framework from the beginning (myself included), which
could help speed things up. :)
> > Quick questions regarding Commons Logging proposal:
> >
> > Letting people choose their logging implementation is not a
> > bad idea, but I've been hearing negative things about Commons
> > Logging in its ability to detect the correct implementation
> > to use. Something about classpath problems, if I remember
> > correctly? Are these issues solved?
>
> 99.9% of the issue is configuration -- getting the right JARs
> and configuration files in the right place. In that sense
> its not really different than any other JAR that might be
> included in the webapp or installed in the container. You
> just need to get all the moving parts where they belong. And
> use C-L 1.0.4 or later, of course, because there were some
> critical bugfixes.
Ah, that explains it. Thanks for clearing this up for me.
> Struts 1.x has used C-L from the very beginning of its
> existence, and we've been satisfied with it.
>
> > Again, this is
> > just little me's two cents, but I am in favor of minimizing third
> > party dependencies as much as possible, and I don't see very much
> > reason not to use the JDK 1.4 implementation. Anyone?
>
> There are a lot of potential customers that have existing
> environments based on things like Log4J, and those folks
> would be really (and justifiably) irritated to be required
> to configure two logging systems.
Indeed good and valid points - I'm sold.
> Craig
\Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Craig McClanahan <cr...@gmail.com>.
On Fri, 29 Oct 2004 01:22:09 +0200, Anders Steinlein
<an...@steinlein.no> wrote:
> >
> > > 3.1 Java2 Standard Edition APIs
> >
> > I'd be +1 for J2SE 5.0
>
> Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I
> would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should
> be widely deployed by then. If not, then our "endorsement" of it could
> encourage people to make the switch. ;) Plus, it could stand as a
> marketing bonus - in support of our "revolutionary" path.
I sure hope it doesn't take us 1-2 years, but with our track record
I'd be pretty foolish to make any promises at this point :-).
>
> Quick questions regarding Commons Logging proposal:
>
> Letting people choose their logging implementation is not a bad idea, but
> I've been hearing negative things about Commons Logging in its ability to
> detect the correct implementation to use. Something about classpath
> problems, if I remember correctly? Are these issues solved?
99.9% of the issue is configuration -- getting the right JARs and
configuration files in the right place. In that sense its not really
different than any other JAR that might be included in the webapp or
installed in the container. You just need to get all the moving parts
where they belong. And use C-L 1.0.4 or later, of course, because
there were some critical bugfixes.
Struts 1.x has used C-L from the very beginning of its existence, and
we've been satisfied with it.
> Again, this is
> just little me's two cents, but I am in favor of minimizing third party
> dependencies as much as possible, and I don't see very much reason not to
> use the JDK 1.4 implementation. Anyone?
There are a lot of potential customers that have existing environments
based on things like Log4J, and those folks would be really (and
justifiably) irritated to be required to configure two logging
systems.
>
> Regards,
> \Anders
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts Shale
Posted by Ted Husted <hu...@apache.org>.
> On Mon, 25 Oct 2004 04:56:45 +0000, dev@struts.apache.org 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.
> 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).
> 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?
Perhaps as an abstract link in the request processing chain?
Would there be an interface for the Application Controller?
> [New topic] 2.6 Unit Tests
Would it be all right if I contributed some unit tests to the codebase accompanying the proposal?
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.
> 3.8 Logging APIs
Proposal: Commons Logging
+1
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, dev@struts.apache.org wrote:
>
>> Date: 2004-10-24T21:56:45
>> Editor: CraigMcClanahan <cr...@apache.org>
>> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>
>
> --------------------------------------------------------------------
> - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Struts Shale
Posted by Anders Steinlein <an...@steinlein.no>.
>
> > 3.1 Java2 Standard Edition APIs
>
> I'd be +1 for J2SE 5.0
Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I
would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should
be widely deployed by then. If not, then our "endorsement" of it could
encourage people to make the switch. ;) Plus, it could stand as a
marketing bonus - in support of our "revolutionary" path.
Quick questions regarding Commons Logging proposal:
Letting people choose their logging implementation is not a bad idea, but
I've been hearing negative things about Commons Logging in its ability to
detect the correct implementation to use. Something about classpath
problems, if I remember correctly? Are these issues solved? Again, this is
just little me's two cents, but I am in favor of minimizing third party
dependencies as much as possible, and I don't see very much reason not to
use the JDK 1.4 implementation. Anyone?
Regards,
\Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org