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