You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2003/12/17 22:08:17 UTC
Struts 2.0 Discussion Forum
Is there one? I have several ideas I'd like to toss into the discussion.
Don
On 17 Dec 2003 husted@apache.org wrote:
> husted 2003/12/17 12:49:28
>
> Added: contrib/struts-jericho README.txt project.properties
> project.xml
> Log:
> Create whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x.
>
> Revision Changes Path
> 1.1 jakarta-struts/contrib/struts-jericho/README.txt
>
> Index: README.txt
> ===================================================================
> Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x.
>
> Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a codename to a proposal until the Community comes to a consensus.
>
> This proposal is called "Jericho" since it tries to tear-down the walls within the Struts architecture. Jericho proposes to open-up Struts by
>
> * Declaring interfaces for all core components.
>
> * Providing working base implementations for all core components.
>
> * Encapsulating alll path references within "Location" objects (fka ActionForwards)and referring only to Locations from all other objects.
>
> * Providing additional extension points from core components so that the "Inversion of Control" pattern is fully realized.
>
> * Providing "POJO" signatures that encapsulate HTTP classes so that applications can be freed of HTTP semantics, if so desired.
>
> * Retain optional access to HTTP objects so that applications can be free to do whatever they need to do.
>
> -Backward Compatibility-
>
> Jericho is a revolution and backward compatability with prior versions of Struts is not the prime consideration. However, care is being taken to create a clear migration path, where practible, so that Jericho is available to the widest community possible.
>
> _DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
>
> A second alternative to explore is to provide an alternate configuration loader that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
>
> _Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to provided. These classes will provide the Struts 1.2.x behavior but also implement the Struts Jericho interfaces, so that the framework can use them interchangeably.
>
> These same techniques may be applied to provide adaptors for other frameworks, so as to make Struts Jericho available to the widest community possible.
>
> ###
>
>
> 1.1 jakarta-struts/contrib/struts-jericho/project.properties
>
> Index: project.properties
> ===================================================================
> # -------------------------------------------------------------------
> # P R O J E C T P R O P E R T I E S
> # -------------------------------------------------------------------
>
> compile.debug = on
> compile.optimize = off
> compile.deprecation = off
>
> maven.linkcheck.enable=true
>
> # documentation properties
> maven.xdoc.date=left
> maven.xdoc.version=${pom.currentVersion}
> maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
>
>
>
> 1.1 jakarta-struts/contrib/struts-jericho/project.xml
>
> Index: project.xml
> ===================================================================
> <?xml version="1.0" encoding="UTF-8"?>
>
> <project>
> <extend>../project.xml</extend>
> <name>Jericho</name>
> <id>struts-jericho</id>
> <currentVersion>0.1-dev</currentVersion>
> <inceptionYear>2003</inceptionYear>
> <shortDescription>Struts Jericho 2.x Whiteboard</shortDescription>
> <description>
> Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x.
> Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a codename to a proposal
> until the Community comes to a consensus.
> This proposal is called "Jericho" since it tries to tear-down the walls within the Struts architecture.
> </description>
> <developers>
> <developer>
> <name>Ted Husted</name>
> <id>husted</id>
> <email>husted@apache.org</email>
> <organization></organization>
> </developer>
> </developers>
>
> <build>
> <unitTest>
> <includes>
> <include>**/*Test.java</include>
> </includes>
> </unitTest>
> </build>
>
> </project>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Discussion Forum
Posted by BaTien Duong <ba...@dbgroups.com>.
Are we on something revolutionary here? I am looking forward to this.
BaTien
DBGROUPS
Don Brown wrote:
>Is there one? I have several ideas I'd like to toss into the discussion.
>
>Don
>
>On 17 Dec 2003 husted@apache.org wrote:
>
>
>
>>husted 2003/12/17 12:49:28
>>
>> Added: contrib/struts-jericho README.txt project.properties
>> project.xml
>> Log:
>> Create whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x.
>>
>> Revision Changes Path
>> 1.1 jakarta-struts/contrib/struts-jericho/README.txt
>>
>> Index: README.txt
>> ===================================================================
>> Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x.
>>
>> Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a codename to a proposal until the Community comes to a consensus.
>>
>> This proposal is called "Jericho" since it tries to tear-down the walls within the Struts architecture. Jericho proposes to open-up Struts by
>>
>> * Declaring interfaces for all core components.
>>
>> * Providing working base implementations for all core components.
>>
>> * Encapsulating alll path references within "Location" objects (fka ActionForwards)and referring only to Locations from all other objects.
>>
>> * Providing additional extension points from core components so that the "Inversion of Control" pattern is fully realized.
>>
>> * Providing "POJO" signatures that encapsulate HTTP classes so that applications can be freed of HTTP semantics, if so desired.
>>
>> * Retain optional access to HTTP objects so that applications can be free to do whatever they need to do.
>>
>> -Backward Compatibility-
>>
>> Jericho is a revolution and backward compatability with prior versions of Struts is not the prime consideration. However, care is being taken to create a clear migration path, where practible, so that Jericho is available to the widest community possible.
>>
>> _DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
>>
>> A second alternative to explore is to provide an alternate configuration loader that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
>>
>> _Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to provided. These classes will provide the Struts 1.2.x behavior but also implement the Struts Jericho interfaces, so that the framework can use them interchangeably.
>>
>> These same techniques may be applied to provide adaptors for other frameworks, so as to make Struts Jericho available to the widest community possible.
>>
>> ###
>>
>>
>> 1.1 jakarta-struts/contrib/struts-jericho/project.properties
>>
>> Index: project.properties
>> ===================================================================
>> # -------------------------------------------------------------------
>> # P R O J E C T P R O P E R T I E S
>> # -------------------------------------------------------------------
>>
>> compile.debug = on
>> compile.optimize = off
>> compile.deprecation = off
>>
>> maven.linkcheck.enable=true
>>
>> # documentation properties
>> maven.xdoc.date=left
>> maven.xdoc.version=${pom.currentVersion}
>> maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
>>
>>
>>
>> 1.1 jakarta-struts/contrib/struts-jericho/project.xml
>>
>> Index: project.xml
>> ===================================================================
>> <?xml version="1.0" encoding="UTF-8"?>
>>
>> <project>
>> <extend>../project.xml</extend>
>> <name>Jericho</name>
>> <id>struts-jericho</id>
>> <currentVersion>0.1-dev</currentVersion>
>> <inceptionYear>2003</inceptionYear>
>> <shortDescription>Struts Jericho 2.x Whiteboard</shortDescription>
>> <description>
>> Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x.
>> Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a codename to a proposal
>> until the Community comes to a consensus.
>> This proposal is called "Jericho" since it tries to tear-down the walls within the Struts architecture.
>> </description>
>> <developers>
>> <developer>
>> <name>Ted Husted</name>
>> <id>husted</id>
>> <email>husted@apache.org</email>
>> <organization></organization>
>> </developer>
>> </developers>
>>
>> <build>
>> <unitTest>
>> <includes>
>> <include>**/*Test.java</include>
>> </includes>
>> </unitTest>
>> </build>
>>
>> </project>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>.
>
>
>
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Vic Cekvenich <ce...@basebeans.com>.
David Graham wrote:
> --- Vic Cekvenich <ce...@basebeans.com> wrote:
>
>>And.... even a simple DAO interface, to be used optionaly be people, so
>>they can go back and forth from iBatis to Hibreante or what ever.
>
>
> I started the Mapper project in the commons for this exact reason. It
> doesn't belong in Struts.
>
> http://jakarta.apache.org/commons/sandbox/mapper/
>
> David
>
>
I like the goal.
Thanks for the link, I looked at it.... but my idea was more of a utra
simple CRUD DAO interface, taking Collections or XML as arguments. ..
following the Sun DAO patern (what most people do) but simpler.
ex:
public interface OptionalDAO {
Document retrieveAsXML(Map arg); // so people can implement a DAO that
executes a retrieve any way they please.
List retrieveAsList(Map arg);
boolean saveXML(Document arg); // so people can implement a DAO that
saves any way they please.
boolean saveList(List arg);
void beginTran() ;
void endTran();
along those lines.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Ted Husted <hu...@apache.org>.
David Graham wrote:
> --- Vic Cekvenich <ce...@basebeans.com> wrote:
>
>>And.... even a simple DAO interface, to be used optionaly be people, so
>>they can go back and forth from iBatis to Hibreante or what ever.
>
>
> I started the Mapper project in the commons for this exact reason. It
> doesn't belong in Struts.
+1
Struts should remain a BYOM (Bring Your Own Model) framework. As soon as
we include *anything* along these lines, people perceive it as the
preferred way of doing things. (Look at what happened with
GenericDataSource).
Certainly, we can include more HOWTOs in the documentation about hooking
Struts up with various business and persistence layers. But the classes
for doing this should not live under the Struts brand..
> http://jakarta.apache.org/commons/sandbox/mapper/
>
> David
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by David Graham <gr...@yahoo.com>.
--- Vic Cekvenich <ce...@basebeans.com> wrote:
>
> And.... even a simple DAO interface, to be used optionaly be people, so
> they can go back and forth from iBatis to Hibreante or what ever.
I started the Mapper project in the commons for this exact reason. It
doesn't belong in Struts.
http://jakarta.apache.org/commons/sandbox/mapper/
David
>
> And build Struts on top of HiveMind or similar. (IoC and Services... and
>
> XML).
>
> If just the MVC interfaces are defined, then several implemenations can
> ship. One implemtation would be backwards compatible.
> Once could be SOAPActionImpl.
>
> Action's execute should take a Map as signature argument. This way we do
>
> not have Req/Resp tie in, but anything comes in.
> Ex: execute(Map arg) { .. }
> A good 1st step is to have a TilesAction and Action have same signature
> for execute.
>
>
> .V
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Vic Cekvenich <ce...@basebeans.com>.
Martin Cooper wrote:
>
> * Make the Struts core independent of the Servlets spec .... <SNIP>
Above is my favorite wish!
I would like to be able to call an Action via XML-RPC for it to give me
a FormBean.... and for me to give it a FormBean back. (or any other
SOA). There was a few threads of SOAP Struts some time back.
And... maybe a FormBean is an XML DTD.
(Like .NET stuff, and iBatis 2.0 _sqlMap.getXMLResult())
This way a view can render it (such as core tags X: ) any way it wants.
Ex: from javascript you call XML-RPC to get a XML (multirow bean)
And.... even a simple DAO interface, to be used optionaly be people, so
they can go back and forth from iBatis to Hibreante or what ever.
And build Struts on top of HiveMind or similar. (IoC and Services... and
XML).
If just the MVC interfaces are defined, then several implemenations can
ship. One implemtation would be backwards compatible.
Once could be SOAPActionImpl.
Action's execute should take a Map as signature argument. This way we do
not have Req/Resp tie in, but anything comes in.
Ex: execute(Map arg) { .. }
A good 1st step is to have a TilesAction and Action have same signature
for execute.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> * Split out file upload handling into a separate pluggable component, with
> its own configuration. I noticed that this is still in the initial Jericho
> DTD, but I think it should not be. The file upload implementation is
> pluggable, and so should be able to have its own config definition.
Feel free to amend that if you like. I've so far managed to avoid file
uploading in Struts applications, and so remain blissfully ignorant of
the grittier details.
> A sort of meta-question: When is Struts no longer Struts? I mean, how much
> change can we introduce in Struts 2.0 before it becomes so different that
> it's really a different framework? Do we need to decide on what Struts is,
> and is not, before we go too far down the path of Struts 2.0? Or do we let
> whatever falls out just fall out and deal with it later?
Legally, I'd say that Strut is whatever the Struts Community says it is.
It's a brand that belongs to the ASF, which we manage on the
Foundation's behalf.
Technically, I'd say that Struts (or any framework) is an aggregation of
its components. In Struts 1.0, we had mainly Form, Forward, Mapping,
Action, and Messaging components. In Struts 1.1, we added Exception,
Validation, Composite (or Tile), and PlugIn components.
So long as Struts 2.x retains the same hallmark components in a
recognizable form, I'd say it's still Struts. :)
Overall, it's my feeling that Struts does all the right things, it's
just that we don't do them in all the right places. :) Being able to
extend elements is one example. Encapsulating paths is another.
My own goal for Struts 2.x is to consistently apply all our best
practices and eliminate inconsistent and legacy practices. We've got a
good thing here; we just need to make it even better. :)
In terms of new functionality, the three biggest fish I'd like to fry
are Workflow, SSL, and Unit Testing. Towards that end, I'd like to
consider integrating LivingLogic's Workflow, ssl-ext, and Struts
TestCase into the Struts 2.x development stream. We may also want to
consider adding these as standard options to Struts 1.x, so as to blaze
a trail.
Although it's not evident from the Jericho DTD, the intention is to use
a Context object in the signatures, perhaps the Commons Chain Context,
so as to encapsulate Servlet/Portlet dependencies.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Vic Cekvenich <Ce...@baseBeans.com>.
Martin Cooper wrote:
>
>
> I think I need to elaborate on my thoughts some more, since I wasn't
> really clear the first time around...
>
> A great deal has happened in web application framework land since Struts
> came along 3-1/2 years ago.
new technologies:
bytecode manipulation
IoC
SOA
filters
xml (XML Beans?)
AOP (just to list all)
Oscar
Unit Testing
scripting (including client javascript)
XML-RPC (not really new, just I like )
JDK 1.4 (interesting quirk: should jericko use the poor JDK logger?
Maybe, but it's poor.)
Some can be leveraged... others do not apply.
> So, what makes Struts Struts? What characteristics do we need to preserve
> in order to keep it Struts, and retain the greatness that has made it so
> amazingly popular?
My answer is:
-light weight. If "jericho" is bloated, then IMO it fails.
-formbeans. The concept that bean properties correspond to a (html data
entry) form. (thinking outside the box: maybe a XML Document that maps
to form properties can also be a form bean in Jericho).
-it had several clear extension points
And what it did not have:
- A DAO. Many popular frameworks of the day went down with their DAO.
It was a minimalist framework, that did 80% of what you need and it did
not get in the way when you wanted it to do things it was not designed for.
Therefore, one person needs to write most of Jericho over a single
weekend and not try to please a committee, just their own business
application and do initial check in! :-)
Lets not forget validation, btw. it should not be an after taught. Keep
same? yes.
.V
"perfection is achived when you have nothing left to remove"
by Saint something or other
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> A great deal has happened in web application framework land since Struts
> came along 3-1/2 years ago. There is a boatload of frameworks out there
> now, and some of them have some great ideas. What I don't really want to
> end up with is a Struts 2.0 that is simply a reinvention of what other
> people have done, with a compatibility layer to make it accessible to
> Struts 1.x developers.
>
> So, what makes Struts Struts? What characteristics do we need to preserve
> in order to keep it Struts, and retain the greatness that has made it so
> amazingly popular? How far can we go before the decision to choose Struts
> 2.0, or not, is no different to a potential developer than the decision to
> chose any one of the other frameworks out there today? Obviously,
> compatibility is going to be very important, but I hope that's not all!
I think that's going to come down to "I know it when I see it".
I'd say that Struts (or any framework) is an aggregation of its
components. In Struts 1.0, we had mainly Form, Forward, Mapping, Action,
and Messaging components. In Struts 1.1, we added Exception, Validation,
Composite (or Tile), and PlugIn components.
So long as Struts 2.x retains the same hallmark components in a
recognizable form, I'd say it's still Struts.
And, so far, I haven't heard anyone suggest anything that couldn't also
be implemented in Struts 1.x over time. It's just that deprecation and
migration can be a painful process, and sometimes it's better to bite
the bullet and tell people that they might have to change this or that
if they want to migrate now.
We've all admitted several times that we would-a could-a done things
differently if we knew then what we know now. All anyone is saying is
that now is the time to fix the would-a and could-a's.
I don't know about anyone else, but I'm sorta planning on spending yet
another twenty years writing business applications, and this seems like
a very good time to try and write the best Struts framework we can, and
make my declining years easier to bear :)
Of course, the important thing will be for whoever is working on a
Struts 2.x implementation to "eat our own dog food", like we had to do
for Struts 1.x. If it doesn't work for us, it's surely not going to work
for anyone else.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Martin Cooper <ma...@apache.org>.
On Thu, 18 Dec 2003, Craig R. McClanahan wrote:
> Quoting Martin Cooper <ma...@apache.org>:
>
> > Just to add a few more off the top of my head:
> >
> > * Make the Struts core independent of the Servlets spec and the Portlets
> > spec, so that it can be used for both, and more.
> >
> > * Separate view-technology-specific code into separate components, so that
> > the core is view-technology agnostic. So, for example, all JSP specific
> > code, including all of the taglibs, would move to a JSP component.
> >
> > * Rework Tiles into two facets, so that the core is independent of the
> > Servlets spec and JSP, and the JSP component is part of the view specific
> > component described above.
> >
> > * Split out file upload handling into a separate pluggable component, with
> > its own configuration. I noticed that this is still in the initial Jericho
> > DTD, but I think it should not be. The file upload implementation is
> > pluggable, and so should be able to have its own config definition.
> >
> > I know I have more in notes at home, but just wanted to throw these out.
> >
> > A sort of meta-question: When is Struts no longer Struts? I mean, how much
> > change can we introduce in Struts 2.0 before it becomes so different that
> > it's really a different framework? Do we need to decide on what Struts is,
> > and is not, before we go too far down the path of Struts 2.0? Or do we let
> > whatever falls out just fall out and deal with it later?
> >
>
> Product names are marketing, not technology. Struts 2.0 will be Struts if *we*
> call it Struts :-).
>
> More seriously, the amount of change between major product versions can be
> pretty enormous in some cases (ask classic ASP developers if they think ASP.NET
> is really the same environment or not). Innovation and revolution are
> perfectly fine things to do (applying all the lessons we've learned along the
> way), but we should also remember that there are thousands of apps based on a
> Struts 1.x architecture that need continuing support. We need to have the
> discipline to continue to work evolving a 1.2.x world while we're creating a
> new 2.x one.
I think I need to elaborate on my thoughts some more, since I wasn't
really clear the first time around...
A great deal has happened in web application framework land since Struts
came along 3-1/2 years ago. There is a boatload of frameworks out there
now, and some of them have some great ideas. What I don't really want to
end up with is a Struts 2.0 that is simply a reinvention of what other
people have done, with a compatibility layer to make it accessible to
Struts 1.x developers.
So, what makes Struts Struts? What characteristics do we need to preserve
in order to keep it Struts, and retain the greatness that has made it so
amazingly popular? How far can we go before the decision to choose Struts
2.0, or not, is no different to a potential developer than the decision to
chose any one of the other frameworks out there today? Obviously,
compatibility is going to be very important, but I hope that's not all!
>
> Regarding 2.x, an important consideration will be base technology platforms --
> I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e.
> Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
> presentation technology, etc.).
+1 to a J2EE baseline.
--
Martin Cooper
>
> > --
> > Martin Cooper
> >
>
> Craig
>
>
> >
> > On Wed, 17 Dec 2003, Don Brown wrote:
> >
> > > Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
> > > release work. :) I'll throw out some ideas here, then develop them later
> > > in the wiki:
> > >
> > > - Make Inversion of Control central. By using an IoC framework to wire
> > > Struts together, it makes it really easy to extend or improve Struts not
> > > only for future development but for users as well. I'd recommend Spring's
> > > IoC impl as it is small (>100k), really easy to use, and easily
> > > extendable. If we wanted to remain more "agnostic", there are "meta" IoC
> > > frameworks that let you plug in Pico/Spring/Avalon, etc.
> > >
> > > - Use XML Schema over DTD's. Give struts config its own default namespace
> > > to make it easier for users to mix in elements of other namespaces. An
> > > example would be adding custom documentation attributes and elements. Of
> > > course the usual arguments for XML Schema over DTD's apply as well.
> > >
> > > - Replace paths with URL's, allowing for a default protocol. An action
> > > path would look like "action://foo" or a tiles forward would be
> > > "tiles://tilesdef" This would make it easy to plug in handlers to support
> > > different presentation engines. If no protocol is specified, the path is
> > > handled as usual.
> > >
> > > - As Ted said, contine with the wildcard theme. Struts should do
> > > everything possible to cut down configuration.
> > >
> > > - Also, again totally agreeing with Ted, make everything interface based,
> > > have default implementations, and free apps of HTTP. Ideally, I'd like to
> > > see extra effort going into making it easy if not effortless to take a
> > > Struts 2.0 app and use the code in a portlet or web service environment.
> > > At least in my area, clients are wanting human and machine interfaces,
> > > with the human interface generally being behind a portal.
> > >
> > > Anyways, those are my "brainstorming" thoughts. If any look interesting,
> > > I'll write something up in the wiki.
> > >
> > > Don
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Joe Germuska <Jo...@Germuska.com>:
> I don't think I'm going to articulate this question very clearly, but
> hopefully my drift will be gotten, so to speak.
>
> If we're talking about making Struts independent of Servlets, then
> what part of Struts would depend on either Servlet 2.3 or Servlet 2.4?
>
Even if the core framework is independent of the presentation tier APIs, you
still need an adapter layer (often called a binding) between the particular
presentation API in use and the fundamental controller capabilities. As I
pointed out in a previous message, I can see three very obvious bindings (to
servlets, to portlets, and to SOAP) that we'd undoubtedly want to include in
the basic package -- but we know we've succeeded when you can use the same
actions in each of those three environments (to perform the same transaction).
> Rather, how will we partition Struts so that we know our boundaries?
> Presumably in a chain-like world, you could have Servlet 2.3
> pre-processing chains and Servlet 2.4 pre-processing chains, and of
> course we're going to have view post-processors for XSLT, Velocity...
> so why shouldn't there be JSP 1.2 and JSP 2.0 post-processors?
>
For servlet 2.3 versus 2.4, one approach to building frameworks would be to
architect the controller as a filter (or set of cooperating filters) rather
than as a servlet. That is not a practical reality in servlet 2.3 because you
can't interpose filters on a RequestDispatcher call.
It's probably feasible to have a decomposed request processor that can be
implemented as either a set of filters (which, after all, is sort of the CoR
pattern again, just with different APIs) or as a servlet. In practical terms,
though, it's easier to abstract the layers if we stick with a servlet as the
basic adapatation gadget.
The main reason I'm interested in J2EE 1.4 as the base platform is for JSP 2.0.
But the choice between JSP 1.2 and JSP 2.0 should have zero impact on the
organization of the request processor -- it should be as totally an independent
decision as possible. However, if you choose JSP 2.0 for the minimum platform
for JSP-based presentation stuff, you get servlet 2.4 for free to use in the
controller tier if you want.
> I suppose we ought to draft a glossary to make sure we all agree on
> these various concepts...
>
> Joe
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Joe Germuska <Jo...@Germuska.com>.
I don't think I'm going to articulate this question very clearly, but
hopefully my drift will be gotten, so to speak.
If we're talking about making Struts independent of Servlets, then
what part of Struts would depend on either Servlet 2.3 or Servlet 2.4?
Rather, how will we partition Struts so that we know our boundaries?
Presumably in a chain-like world, you could have Servlet 2.3
pre-processing chains and Servlet 2.4 pre-processing chains, and of
course we're going to have view post-processors for XSLT, Velocity...
so why shouldn't there be JSP 1.2 and JSP 2.0 post-processors?
I suppose we ought to draft a glossary to make sure we all agree on
these various concepts...
Joe
At 10:51 AM -0800 12/18/03, Craig R. McClanahan wrote:
>For the portions of the framework that depend on Servlet 2.4, you get two
>modest
>but useful features:
>
>* Ability to execute filters on RequestDispatcher.include and
> RequestDispatcher.forward calls, which is not possible in 2.3.
> This gives you additional degrees of freedom in how you organize
> the processing logic of a framework like Struts -- for example,
> it would now be technically feasible to implement the controller
> as a filter instead of a servlet.
>
>* Ability to define request lifecycle listeners (like the older
> ones for session and application lifecycle) so you get a
> complete and consistent event handling model.
>
>If your presentation tier is based on JSP 2.0 (instead of 1.1/1.2), you get a
>very large number of benefits. The most visible ones are:
>
>* New ***much*** simpler API for building tag classes
> (tag instance pooling is gone, single invocation method
> instead of doStart/doEnd, ability to define a tag that
> takes an arbitrary list of attributes, ...).
>
>* Tag files -- essentially, the ability to write a tag handler
> using JSP code instead of Java, complete with parameter passing.
>
>* EL expressions evaluated everywhere (even template text),
> so you don't need to limit yourself to just tags that implement
> support for it (meaning we don't need struts-el variants).
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Vic Cekvenich <ce...@basebeans.com>.
Craig R. McClanahan wrote:
>
>
> There's a couple of variations on the theme that are possible, but I can think
> of at least three layers of something that might be called a "form bean" in the
> conceptual sense:
>
> (1) A set of typesafe field names and corersponding values
> where the application doesn't have to worry about maintaining
> values across requests.
> - Variation: dynamically add and remove fields as needed
> - Variation: allow non-typesafe fields
> - Variation: allow fields that can have multiple values (arrays)
> - Variation: represent data hierarchically instead of just
> a name-value map (bean properties, nested expressions,
> XML DOM, what have you)
>
> (2) The above plus a mechanism to define validation rules (correctness
> checks) on the field values that are independent of physical
> presentation
> - Variation: hard coded logic for validations (i.e. the original
> validate() method in Struts ActionForms.
> - Variation: pointer to a configured set of validation rules
> that is abstracted from presentation considerations.
>
> (3) All of the above plus event handlers for UI events that change
> the state of the field values -- perhaps in the same bean,
> perhaps somewhere else.
>
> A type (1) or type (2) form bean is really better thought of as an abstract way
> to pass the input data for some sort of business transaction between tiers, or
> within tiers. A type (3) form bean would definitely live in the presentation
> tier, and not be used between them. For all three of the cases, though, we
> probably want to invent a different term than "form bean" because that seems so
> conceptually tied to presentation only. Transaction Bean? Input Bean? Data
> Transfer Object :-)?
Can't it be just one good old View layer "thing" that maps the
properties and it's still called formBean? KISS
Don did not link XMLForms good, here are better links for a real fun read:
http://webservices.xml.com/lpt/a/ws/2003/01/29/cocoon-xforms.html
http://www.cocoonhive.org/xmlform/index.html
I like that Pico is lightest IoC and do not see a need for a Bean
Factory, etc.. So there should be some talk of Spring vs Pico.
So far, if it's built on top of
-IoC
-with "XMLFormBean" (as option, since XML can be slow right now, so it
needs to support backward compatible FormBean)
-an execute(context) Action iterface,
-chain request procesor filter interfaces
-HTML tag to support XML Submit (including multi row)
-JDK 1.4
-Clear testing interface to major user components.
That could be the broad stroke major center pieces. It is same design as
Struts 0.6 with each component refactored, same diagram.
There are several smaller pieces, but if Struts can stay light without
too many moving parts, better, people can put arms arround it.
XML config wishes:
- all xml files be able to extend like tiles, like in Validator
- move form beam declaration section to validator, no need to do it 2 times.
- move all tiles xml to struts config, and get rid of tiles.xml
- have a forward to a tile declaration allow you to name the "base"
definition and tile to replace, even maybe have tile part of "* forward"
or what ever Don's thing is called.
I still kind of think maybe DAO interface should be there, we learned a
lot about DAO since.
(I still think one or 2 people should do it in 48 hours from start
else... it's design by comittee)
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Ted Husted <hu...@apache.org>.
Craig R. McClanahan wrote:
> Quoting Ted Husted <hu...@apache.org>:
>>InputHandler?
>
> That would certainly be an appropriate name for my type (3) form bean (that
> included event handling), and perhaps even for a type (2) form bean that
> includes some sort of hooks into validation. It doesn't fit the type (1) style
> that contains only data, though.
Yes, that one sounds more like an InputContext (that InputHandlers might
extend).
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Ted Husted <hu...@apache.org>:
> Craig R. McClanahan wrote:
> > For all three of the cases, though, we
> > probably want to invent a different term than "form bean" because that
> seems so
> > conceptually tied to presentation only. Transaction Bean? Input Bean?
> Data
> > Transfer Object :-)?
>
> InputHandler?
>
That would certainly be an appropriate name for my type (3) form bean (that
included event handling), and perhaps even for a type (2) form bean that
includes some sort of hooks into validation. It doesn't fit the type (1) style
that contains only data, though.
> -T.
>
>
Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Ted Husted <hu...@apache.org>.
Craig R. McClanahan wrote:
> For all three of the cases, though, we
> probably want to invent a different term than "form bean" because that seems so
> conceptually tied to presentation only. Transaction Bean? Input Bean? Data
> Transfer Object :-)?
InputHandler?
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Vic Cekvenich <ce...@basebeans.com>:
>
>
> Craig R. McClanahan wrote:
>
> >
> > One of the things people have said they liked about using a chain to
> decompose
> > RequestProcessor is that you could easily compose your own chains, adding
> your
> > own custom processing stages and so on. You can do exactly the same thing
> with
> > Filters by making each processXxx method its own filter, and using (say)
> the
> > request attributes to play the role of the Context object in
> commons-chain.
> >
> > Filters have an additional capability if you're building a
> servlet-specific
> > framework -- they can wrap the actual request and response objects that
> are
> > passed on to the next filter in the chain, so you can implement some
> > interesting things not directly possible with a chain based implementation
> --
> > such as caching or on-the-fly compression of the response.
> >
> >
> >
> > Craig
>
> I do not get chains, but Hookom posted this link:
>
http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html
>
> which I sort of get (sort of) and it's my favoirte chain impl.
>
InterceptingFilter (as presented in the Core J2EE Patterns book) is very similar
to the way standard filters work in Servlet 2.3 (and 2.4). The primary
difference from the way commons-chain works from the presented "Custom Filter
Strategy" is that a Filter cannot say "I have completed the response -- no need
to do anything more", which is exactly what you'd want for things like a "check
that the user has logged in" mechanism.
Doing chains the way that servlet filters do it (each filter explicitly calls
the next in the chain) would eliminate that problem, but has two potential
disadvantages:
* Somebody has to deal with the complexity of falling off the
end of the filter chain (i.e. a FilterManager or something)
* You end up with a stack frame per Filter (if you've ever wondered
why Tomcat's stack traces are so long, it's because the Valve
architecture inside Catalina follows this same design pattern).
> So if we can use filters or other chain, somone clever could write an
> "chainRequestProcessor" *interface*, that could be impledented for
> JSP2.0 filter... and then somone else could later write a JSP 1.2
> version, even non filter versions.
>
> ?
>
> So I like chain as interface, and action as interface.
>
In commons-chain, the Context, Command, and Chain APIs are all interfaces. You
can use one of the provided implementations and roll your own.
> I am thinking of fliping sides on FormBean as interface, I am now
> leaning against formbeans being an interface. FormBean is a concept
> (properties that map to form elements), plus this idea of XML as a
> FormBean. It could be a List or String or anything. As long as it itself
> does not do DAO, and it maps to a form, good. (but do have way to unit
> test it w/o a container)
> For starters so the JSTL x: tag can be used instead of c:out, plus some
> Stxx things.
> (Then maybe a way to make HTML tag submit XML Doc, multi row and all).
>
> .V
>
There's a couple of variations on the theme that are possible, but I can think
of at least three layers of something that might be called a "form bean" in the
conceptual sense:
(1) A set of typesafe field names and corersponding values
where the application doesn't have to worry about maintaining
values across requests.
- Variation: dynamically add and remove fields as needed
- Variation: allow non-typesafe fields
- Variation: allow fields that can have multiple values (arrays)
- Variation: represent data hierarchically instead of just
a name-value map (bean properties, nested expressions,
XML DOM, what have you)
(2) The above plus a mechanism to define validation rules (correctness
checks) on the field values that are independent of physical
presentation
- Variation: hard coded logic for validations (i.e. the original
validate() method in Struts ActionForms.
- Variation: pointer to a configured set of validation rules
that is abstracted from presentation considerations.
(3) All of the above plus event handlers for UI events that change
the state of the field values -- perhaps in the same bean,
perhaps somewhere else.
A type (1) or type (2) form bean is really better thought of as an abstract way
to pass the input data for some sort of business transaction between tiers, or
within tiers. A type (3) form bean would definitely live in the presentation
tier, and not be used between them. For all three of the cases, though, we
probably want to invent a different term than "form bean" because that seems so
conceptually tied to presentation only. Transaction Bean? Input Bean? Data
Transfer Object :-)?
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Vic Cekvenich <ce...@basebeans.com>.
Craig R. McClanahan wrote:
>
> One of the things people have said they liked about using a chain to decompose
> RequestProcessor is that you could easily compose your own chains, adding your
> own custom processing stages and so on. You can do exactly the same thing with
> Filters by making each processXxx method its own filter, and using (say) the
> request attributes to play the role of the Context object in commons-chain.
>
> Filters have an additional capability if you're building a servlet-specific
> framework -- they can wrap the actual request and response objects that are
> passed on to the next filter in the chain, so you can implement some
> interesting things not directly possible with a chain based implementation --
> such as caching or on-the-fly compression of the response.
>
>
>
> Craig
I do not get chains, but Hookom posted this link:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html
which I sort of get (sort of) and it's my favoirte chain impl.
So if we can use filters or other chain, somone clever could write an
"chainRequestProcessor" *interface*, that could be impledented for
JSP2.0 filter... and then somone else could later write a JSP 1.2
version, even non filter versions.
?
So I like chain as interface, and action as interface.
I am thinking of fliping sides on FormBean as interface, I am now
leaning against formbeans being an interface. FormBean is a concept
(properties that map to form elements), plus this idea of XML as a
FormBean. It could be a List or String or anything. As long as it itself
does not do DAO, and it maps to a form, good. (but do have way to unit
test it w/o a container)
For starters so the JSTL x: tag can be used instead of c:out, plus some
Stxx things.
(Then maybe a way to make HTML tag submit XML Doc, multi row and all).
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Martin Cooper <ma...@apache.org>:
> On Thu, 18 Dec 2003, Craig R. McClanahan wrote:
>
> > Quoting Vic Cekvenich <Ce...@baseBeans.com>:
> >
> > > Craig R. McClanahan wrote:
> > > >
> > > > Regarding 2.x, an important consideration will be base technology
> platforms
> > > --
> > > > I'm in favor of using J2SE 1.4 and the relevant standards from J2EE
> 1.4
> > > (i.e.
> > > > Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
> > > > presentation technology, etc.).
> > > >
> > >
> > >
> > > JDK 1.4, yes.
> > >
> > > One popular? goal mentioned was:
> > > "Get away from reliance on Servlet API"
> > >
> > > I like being on Tomcat 4.
> > > What does it gain to be Tomcat 5 technically?
> >
> > For the portions of the framework that depend on Servlet 2.4, you get two
> > modest
> > but useful features:
> >
> > * Ability to execute filters on RequestDispatcher.include and
> > RequestDispatcher.forward calls, which is not possible in 2.3.
> > This gives you additional degrees of freedom in how you organize
> > the processing logic of a framework like Struts -- for example,
> > it would now be technically feasible to implement the controller
> > as a filter instead of a servlet.
>
> It would certainly be technically feasible to do that, but are there
> practical advantages to doing so? The only thing I can think of is that
> it's easy to punt on a request and let something else (i.e. another filter
> or a servlet) handle it, but I'm not sure why I would want to do that. Any
> good examples?
>
One of the things people have said they liked about using a chain to decompose
RequestProcessor is that you could easily compose your own chains, adding your
own custom processing stages and so on. You can do exactly the same thing with
Filters by making each processXxx method its own filter, and using (say) the
request attributes to play the role of the Context object in commons-chain.
Filters have an additional capability if you're building a servlet-specific
framework -- they can wrap the actual request and response objects that are
passed on to the next filter in the chain, so you can implement some
interesting things not directly possible with a chain based implementation --
such as caching or on-the-fly compression of the response.
> --
> Martin Cooper
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Martin Cooper <ma...@apache.org>.
On Thu, 18 Dec 2003, Craig R. McClanahan wrote:
> Quoting Vic Cekvenich <Ce...@baseBeans.com>:
>
> > Craig R. McClanahan wrote:
> > >
> > > Regarding 2.x, an important consideration will be base technology platforms
> > --
> > > I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4
> > (i.e.
> > > Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
> > > presentation technology, etc.).
> > >
> >
> >
> > JDK 1.4, yes.
> >
> > One popular? goal mentioned was:
> > "Get away from reliance on Servlet API"
> >
> > I like being on Tomcat 4.
> > What does it gain to be Tomcat 5 technically?
>
> For the portions of the framework that depend on Servlet 2.4, you get two
> modest
> but useful features:
>
> * Ability to execute filters on RequestDispatcher.include and
> RequestDispatcher.forward calls, which is not possible in 2.3.
> This gives you additional degrees of freedom in how you organize
> the processing logic of a framework like Struts -- for example,
> it would now be technically feasible to implement the controller
> as a filter instead of a servlet.
It would certainly be technically feasible to do that, but are there
practical advantages to doing so? The only thing I can think of is that
it's easy to punt on a request and let something else (i.e. another filter
or a servlet) handle it, but I'm not sure why I would want to do that. Any
good examples?
--
Martin Cooper
>
> * Ability to define request lifecycle listeners (like the older
> ones for session and application lifecycle) so you get a
> complete and consistent event handling model.
>
> If your presentation tier is based on JSP 2.0 (instead of 1.1/1.2), you get a
> very large number of benefits. The most visible ones are:
>
> * New ***much*** simpler API for building tag classes
> (tag instance pooling is gone, single invocation method
> instead of doStart/doEnd, ability to define a tag that
> takes an arbitrary list of attributes, ...).
>
> * Tag files -- essentially, the ability to write a tag handler
> using JSP code instead of Java, complete with parameter passing.
>
> * EL expressions evaluated everywhere (even template text),
> so you don't need to limit yourself to just tags that implement
> support for it (meaning we don't need struts-el variants).
>
>
> What containers support
> > 2.4? How long for users to convert to the new 2.4 containers?
> > It'd be limiting.
> >
>
> The timing only matters when we're *done* with Struts 2.0, not now. Based on
> our past history, I'd bet we're talking 12-18 months before a production
> quality release of 2.0 would be designed, developed, tested, and evolved to the
> point where we were happy enough to call it (and the APIs inside it) "stable."
>
> Because of how long it took for the J2EE 1.4 standards to go final (we were done
> with servlet and JSP last summer, but had to wait for the web services
> standards to go final), the various app server vendors are already well on the
> way towards 1.4 compliance. (Sun's certified server is already available, and
> is free for development AND production). In the open source world, Tomcat 5
> already has production quality support, of course, and Jetty at least is not
> far behind (Greg is using Jasper2 for the JSP 2.0 stuff, so all he's got to do
> is catch up on the servlet 2.4 changes, which are pretty modest).
>
> > If it ends up being interface, so it could be even used from Soap or
> > applications (the discussed interface execute(Context ctx) ; ) it won't
> > matter much.
> >
>
> I agree that execute(Context ctx) is the right sort of method
> signature for the low level elements. Come to think of it, that's already the
> signature used in commons-chain :-).
>
> > .V
> >
> > ps: I would like light IoC to be considered just a bit more as platform,
> > Pico, Oscar. Not Spring or Avalon.
> >
>
> All of these are interesting, but I think there's two levels of IoC that need to
> be thought about:
>
> * How the various pieces of Struts itself glue themselves together.
>
> * How application level services are composed and made available.
>
> It seems to me that different choices are possible at these two levels, and that
> (if different) the former should be lighter weight than the latter. But we
> can't really pick particular technologies without having identified the needs
> and use cases first.
>
>
> Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Vic Cekvenich <Ce...@baseBeans.com>:
> Craig R. McClanahan wrote:
> >
> > Regarding 2.x, an important consideration will be base technology platforms
> --
> > I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4
> (i.e.
> > Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
> > presentation technology, etc.).
> >
>
>
> JDK 1.4, yes.
>
> One popular? goal mentioned was:
> "Get away from reliance on Servlet API"
>
> I like being on Tomcat 4.
> What does it gain to be Tomcat 5 technically?
For the portions of the framework that depend on Servlet 2.4, you get two
modest
but useful features:
* Ability to execute filters on RequestDispatcher.include and
RequestDispatcher.forward calls, which is not possible in 2.3.
This gives you additional degrees of freedom in how you organize
the processing logic of a framework like Struts -- for example,
it would now be technically feasible to implement the controller
as a filter instead of a servlet.
* Ability to define request lifecycle listeners (like the older
ones for session and application lifecycle) so you get a
complete and consistent event handling model.
If your presentation tier is based on JSP 2.0 (instead of 1.1/1.2), you get a
very large number of benefits. The most visible ones are:
* New ***much*** simpler API for building tag classes
(tag instance pooling is gone, single invocation method
instead of doStart/doEnd, ability to define a tag that
takes an arbitrary list of attributes, ...).
* Tag files -- essentially, the ability to write a tag handler
using JSP code instead of Java, complete with parameter passing.
* EL expressions evaluated everywhere (even template text),
so you don't need to limit yourself to just tags that implement
support for it (meaning we don't need struts-el variants).
What containers support
> 2.4? How long for users to convert to the new 2.4 containers?
> It'd be limiting.
>
The timing only matters when we're *done* with Struts 2.0, not now. Based on
our past history, I'd bet we're talking 12-18 months before a production
quality release of 2.0 would be designed, developed, tested, and evolved to the
point where we were happy enough to call it (and the APIs inside it) "stable."
Because of how long it took for the J2EE 1.4 standards to go final (we were done
with servlet and JSP last summer, but had to wait for the web services
standards to go final), the various app server vendors are already well on the
way towards 1.4 compliance. (Sun's certified server is already available, and
is free for development AND production). In the open source world, Tomcat 5
already has production quality support, of course, and Jetty at least is not
far behind (Greg is using Jasper2 for the JSP 2.0 stuff, so all he's got to do
is catch up on the servlet 2.4 changes, which are pretty modest).
> If it ends up being interface, so it could be even used from Soap or
> applications (the discussed interface execute(Context ctx) ; ) it won't
> matter much.
>
I agree that execute(Context ctx) is the right sort of method
signature for the low level elements. Come to think of it, that's already the
signature used in commons-chain :-).
> .V
>
> ps: I would like light IoC to be considered just a bit more as platform,
> Pico, Oscar. Not Spring or Avalon.
>
All of these are interesting, but I think there's two levels of IoC that need to
be thought about:
* How the various pieces of Struts itself glue themselves together.
* How application level services are composed and made available.
It seems to me that different choices are possible at these two levels, and that
(if different) the former should be lighter weight than the latter. But we
can't really pick particular technologies without having identified the needs
and use cases first.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Vic Cekvenich <Ce...@baseBeans.com>.
Craig R. McClanahan wrote:
>
> Regarding 2.x, an important consideration will be base technology platforms --
> I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e.
> Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
> presentation technology, etc.).
>
JDK 1.4, yes.
One popular? goal mentioned was:
"Get away from reliance on Servlet API"
I like being on Tomcat 4.
What does it gain to be Tomcat 5 technically? What containers support
2.4? How long for users to convert to the new 2.4 containers?
It'd be limiting.
If it ends up being interface, so it could be even used from Soap or
applications (the discussed interface execute(Context ctx) ; ) it won't
matter much.
.V
ps: I would like light IoC to be considered just a bit more as platform,
Pico, Oscar. Not Spring or Avalon.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Martin Cooper <ma...@apache.org>:
> Just to add a few more off the top of my head:
>
> * Make the Struts core independent of the Servlets spec and the Portlets
> spec, so that it can be used for both, and more.
>
> * Separate view-technology-specific code into separate components, so that
> the core is view-technology agnostic. So, for example, all JSP specific
> code, including all of the taglibs, would move to a JSP component.
>
> * Rework Tiles into two facets, so that the core is independent of the
> Servlets spec and JSP, and the JSP component is part of the view specific
> component described above.
>
> * Split out file upload handling into a separate pluggable component, with
> its own configuration. I noticed that this is still in the initial Jericho
> DTD, but I think it should not be. The file upload implementation is
> pluggable, and so should be able to have its own config definition.
>
> I know I have more in notes at home, but just wanted to throw these out.
>
> A sort of meta-question: When is Struts no longer Struts? I mean, how much
> change can we introduce in Struts 2.0 before it becomes so different that
> it's really a different framework? Do we need to decide on what Struts is,
> and is not, before we go too far down the path of Struts 2.0? Or do we let
> whatever falls out just fall out and deal with it later?
>
Product names are marketing, not technology. Struts 2.0 will be Struts if *we*
call it Struts :-).
More seriously, the amount of change between major product versions can be
pretty enormous in some cases (ask classic ASP developers if they think ASP.NET
is really the same environment or not). Innovation and revolution are
perfectly fine things to do (applying all the lessons we've learned along the
way), but we should also remember that there are thousands of apps based on a
Struts 1.x architecture that need continuing support. We need to have the
discipline to continue to work evolving a 1.2.x world while we're creating a
new 2.x one.
Regarding 2.x, an important consideration will be base technology platforms --
I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e.
Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
presentation technology, etc.).
> --
> Martin Cooper
>
Craig
>
> On Wed, 17 Dec 2003, Don Brown wrote:
>
> > Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
> > release work. :) I'll throw out some ideas here, then develop them later
> > in the wiki:
> >
> > - Make Inversion of Control central. By using an IoC framework to wire
> > Struts together, it makes it really easy to extend or improve Struts not
> > only for future development but for users as well. I'd recommend Spring's
> > IoC impl as it is small (>100k), really easy to use, and easily
> > extendable. If we wanted to remain more "agnostic", there are "meta" IoC
> > frameworks that let you plug in Pico/Spring/Avalon, etc.
> >
> > - Use XML Schema over DTD's. Give struts config its own default namespace
> > to make it easier for users to mix in elements of other namespaces. An
> > example would be adding custom documentation attributes and elements. Of
> > course the usual arguments for XML Schema over DTD's apply as well.
> >
> > - Replace paths with URL's, allowing for a default protocol. An action
> > path would look like "action://foo" or a tiles forward would be
> > "tiles://tilesdef" This would make it easy to plug in handlers to support
> > different presentation engines. If no protocol is specified, the path is
> > handled as usual.
> >
> > - As Ted said, contine with the wildcard theme. Struts should do
> > everything possible to cut down configuration.
> >
> > - Also, again totally agreeing with Ted, make everything interface based,
> > have default implementations, and free apps of HTTP. Ideally, I'd like to
> > see extra effort going into making it easy if not effortless to take a
> > Struts 2.0 app and use the code in a portlet or web service environment.
> > At least in my area, clients are wanting human and machine interfaces,
> > with the human interface generally being behind a portal.
> >
> > Anyways, those are my "brainstorming" thoughts. If any look interesting,
> > I'll write something up in the wiki.
> >
> > Don
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Martin Cooper <ma...@apache.org>.
Just to add a few more off the top of my head:
* Make the Struts core independent of the Servlets spec and the Portlets
spec, so that it can be used for both, and more.
* Separate view-technology-specific code into separate components, so that
the core is view-technology agnostic. So, for example, all JSP specific
code, including all of the taglibs, would move to a JSP component.
* Rework Tiles into two facets, so that the core is independent of the
Servlets spec and JSP, and the JSP component is part of the view specific
component described above.
* Split out file upload handling into a separate pluggable component, with
its own configuration. I noticed that this is still in the initial Jericho
DTD, but I think it should not be. The file upload implementation is
pluggable, and so should be able to have its own config definition.
I know I have more in notes at home, but just wanted to throw these out.
A sort of meta-question: When is Struts no longer Struts? I mean, how much
change can we introduce in Struts 2.0 before it becomes so different that
it's really a different framework? Do we need to decide on what Struts is,
and is not, before we go too far down the path of Struts 2.0? Or do we let
whatever falls out just fall out and deal with it later?
--
Martin Cooper
On Wed, 17 Dec 2003, Don Brown wrote:
> Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
> release work. :) I'll throw out some ideas here, then develop them later
> in the wiki:
>
> - Make Inversion of Control central. By using an IoC framework to wire
> Struts together, it makes it really easy to extend or improve Struts not
> only for future development but for users as well. I'd recommend Spring's
> IoC impl as it is small (>100k), really easy to use, and easily
> extendable. If we wanted to remain more "agnostic", there are "meta" IoC
> frameworks that let you plug in Pico/Spring/Avalon, etc.
>
> - Use XML Schema over DTD's. Give struts config its own default namespace
> to make it easier for users to mix in elements of other namespaces. An
> example would be adding custom documentation attributes and elements. Of
> course the usual arguments for XML Schema over DTD's apply as well.
>
> - Replace paths with URL's, allowing for a default protocol. An action
> path would look like "action://foo" or a tiles forward would be
> "tiles://tilesdef" This would make it easy to plug in handlers to support
> different presentation engines. If no protocol is specified, the path is
> handled as usual.
>
> - As Ted said, contine with the wildcard theme. Struts should do
> everything possible to cut down configuration.
>
> - Also, again totally agreeing with Ted, make everything interface based,
> have default implementations, and free apps of HTTP. Ideally, I'd like to
> see extra effort going into making it easy if not effortless to take a
> Struts 2.0 app and use the code in a portlet or web service environment.
> At least in my area, clients are wanting human and machine interfaces,
> with the human interface generally being behind a portal.
>
> Anyways, those are my "brainstorming" thoughts. If any look interesting,
> I'll write something up in the wiki.
>
> Don
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Don Brown <mr...@twdata.org>.
I totally agree - let me clarify. I think Struts 2.0 could use an IoC
framework like Spring to help improve its internal structure. Any
configuration files should be stored in the Struts jar, but be able to be
overridden by specifying an alternate IoC configuration path. This lets
advanced users easily modify the structure of Struts itself, but not add
complexity for the casual user. Of course, Spring and probably other
frameworks allow you to easily customize the configuration process.
Don
On Thu, 18 Dec 2003, Martin Cooper wrote:
> On Wed, 17 Dec 2003, Don Brown wrote:
>
> > Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
> > release work. :) I'll throw out some ideas here, then develop them later
> > in the wiki:
> >
> > - Make Inversion of Control central. By using an IoC framework to wire
> > Struts together, it makes it really easy to extend or improve Struts not
> > only for future development but for users as well. I'd recommend Spring's
> > IoC impl as it is small (>100k), really easy to use, and easily
> > extendable. If we wanted to remain more "agnostic", there are "meta" IoC
> > frameworks that let you plug in Pico/Spring/Avalon, etc.
>
> I'm a little hesitant to start depending on other frameworks. It's not
> that I think they don't have anything to offer us, it's just what it does
> to the newcomer to Struts. If someone has to learn Struts *and* Spring
> (for example) to get going, then we've set the bar much higher.
>
> If we do end up deciding to depend on something like this, I believe we'll
> need to put in the work to make it "look" like Struts. Taking Spring as an
> example again, the substantial difference in the "character" of the XML
> config files would easily confuse a newcomer trying to get his/her head
> around the syntax. If we could make those files "look" like Struts config
> files (or vice versa, for that matter), that would help, though.
>
> --
> Martin Cooper
>
>
> >
> > - Use XML Schema over DTD's. Give struts config its own default namespace
> > to make it easier for users to mix in elements of other namespaces. An
> > example would be adding custom documentation attributes and elements. Of
> > course the usual arguments for XML Schema over DTD's apply as well.
> >
> > - Replace paths with URL's, allowing for a default protocol. An action
> > path would look like "action://foo" or a tiles forward would be
> > "tiles://tilesdef" This would make it easy to plug in handlers to support
> > different presentation engines. If no protocol is specified, the path is
> > handled as usual.
> >
> > - As Ted said, contine with the wildcard theme. Struts should do
> > everything possible to cut down configuration.
> >
> > - Also, again totally agreeing with Ted, make everything interface based,
> > have default implementations, and free apps of HTTP. Ideally, I'd like to
> > see extra effort going into making it easy if not effortless to take a
> > Struts 2.0 app and use the code in a portlet or web service environment.
> > At least in my area, clients are wanting human and machine interfaces,
> > with the human interface generally being behind a portal.
> >
> > Anyways, those are my "brainstorming" thoughts. If any look interesting,
> > I'll write something up in the wiki.
> >
> > Don
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Martin Cooper <ma...@apache.org>.
On Wed, 17 Dec 2003, Don Brown wrote:
> Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
> release work. :) I'll throw out some ideas here, then develop them later
> in the wiki:
>
> - Make Inversion of Control central. By using an IoC framework to wire
> Struts together, it makes it really easy to extend or improve Struts not
> only for future development but for users as well. I'd recommend Spring's
> IoC impl as it is small (>100k), really easy to use, and easily
> extendable. If we wanted to remain more "agnostic", there are "meta" IoC
> frameworks that let you plug in Pico/Spring/Avalon, etc.
I'm a little hesitant to start depending on other frameworks. It's not
that I think they don't have anything to offer us, it's just what it does
to the newcomer to Struts. If someone has to learn Struts *and* Spring
(for example) to get going, then we've set the bar much higher.
If we do end up deciding to depend on something like this, I believe we'll
need to put in the work to make it "look" like Struts. Taking Spring as an
example again, the substantial difference in the "character" of the XML
config files would easily confuse a newcomer trying to get his/her head
around the syntax. If we could make those files "look" like Struts config
files (or vice versa, for that matter), that would help, though.
--
Martin Cooper
>
> - Use XML Schema over DTD's. Give struts config its own default namespace
> to make it easier for users to mix in elements of other namespaces. An
> example would be adding custom documentation attributes and elements. Of
> course the usual arguments for XML Schema over DTD's apply as well.
>
> - Replace paths with URL's, allowing for a default protocol. An action
> path would look like "action://foo" or a tiles forward would be
> "tiles://tilesdef" This would make it easy to plug in handlers to support
> different presentation engines. If no protocol is specified, the path is
> handled as usual.
>
> - As Ted said, contine with the wildcard theme. Struts should do
> everything possible to cut down configuration.
>
> - Also, again totally agreeing with Ted, make everything interface based,
> have default implementations, and free apps of HTTP. Ideally, I'd like to
> see extra effort going into making it easy if not effortless to take a
> Struts 2.0 app and use the code in a portlet or web service environment.
> At least in my area, clients are wanting human and machine interfaces,
> with the human interface generally being behind a portal.
>
> Anyways, those are my "brainstorming" thoughts. If any look interesting,
> I'll write something up in the wiki.
>
> Don
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Sgarlata Matt <sg...@bah.com>.
Sorry about that!
You are right, the license is ASF. It says so both on the SourceForge site
and in the license included in Milestone 3. I don't know where I got the
idea that it was LGPL.
Matt
----- Original Message -----
From: "Don Brown" <mr...@twdata.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Wednesday, December 17, 2003 5:20 PM
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
> Nope, Spring is Apache-style, I just checked. You had me worried there
> for a minute :)
>
> Don
>
> On Wed, 17 Dec 2003, Sgarlata Matt wrote:
>
> > ----- Original Message -----
> > From: "Joe Germuska" <Jo...@Germuska.com>
> > To: "Struts Developers List" <st...@jakarta.apache.org>
> > Sent: Wednesday, December 17, 2003 5:04 PM
> > Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
> >
> >
> > > So then, with specific frameworks, I don't understand how Pico's
> > > orientation towards constructors works in an environment where beans
> > > need to be dynamically instantiated, but perhaps I just haven't
> > > thought about it hard enough. Avalon seems too heavy, which leaves
> > > us (or me at least) with Spring and HiveMind. I haven't developed
> > > with either but so far the docs for Spring give me a warm fuzzy
> > > feeling while the HiveMind docs kind of scare me.
> >
> > I agree with your assessment of frameworks 100%. However, Spring is
under
> > an LGPL license, so Struts can't use Spring unless either Struts
switches to
> > LGPL or Spring switches to ASF, right? It would be kind of silly for
Struts
> > to stay under ASF in this case, since the Spring license would force the
> > undesirable LGPL clauses on any projects that were based on Struts. Am
I
> > right?
> >
> > Matt
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Don Brown <mr...@twdata.org>.
Nope, Spring is Apache-style, I just checked. You had me worried there
for a minute :)
Don
On Wed, 17 Dec 2003, Sgarlata Matt wrote:
> ----- Original Message -----
> From: "Joe Germuska" <Jo...@Germuska.com>
> To: "Struts Developers List" <st...@jakarta.apache.org>
> Sent: Wednesday, December 17, 2003 5:04 PM
> Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
>
>
> > So then, with specific frameworks, I don't understand how Pico's
> > orientation towards constructors works in an environment where beans
> > need to be dynamically instantiated, but perhaps I just haven't
> > thought about it hard enough. Avalon seems too heavy, which leaves
> > us (or me at least) with Spring and HiveMind. I haven't developed
> > with either but so far the docs for Spring give me a warm fuzzy
> > feeling while the HiveMind docs kind of scare me.
>
> I agree with your assessment of frameworks 100%. However, Spring is under
> an LGPL license, so Struts can't use Spring unless either Struts switches to
> LGPL or Spring switches to ASF, right? It would be kind of silly for Struts
> to stay under ASF in this case, since the Spring license would force the
> undesirable LGPL clauses on any projects that were based on Struts. Am I
> right?
>
> Matt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Sgarlata Matt <sg...@bah.com>.
----- Original Message -----
From: "Joe Germuska" <Jo...@Germuska.com>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Wednesday, December 17, 2003 5:04 PM
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
> So then, with specific frameworks, I don't understand how Pico's
> orientation towards constructors works in an environment where beans
> need to be dynamically instantiated, but perhaps I just haven't
> thought about it hard enough. Avalon seems too heavy, which leaves
> us (or me at least) with Spring and HiveMind. I haven't developed
> with either but so far the docs for Spring give me a warm fuzzy
> feeling while the HiveMind docs kind of scare me.
I agree with your assessment of frameworks 100%. However, Spring is under
an LGPL license, so Struts can't use Spring unless either Struts switches to
LGPL or Spring switches to ASF, right? It would be kind of silly for Struts
to stay under ASF in this case, since the Spring license would force the
undesirable LGPL clauses on any projects that were based on Struts. Am I
right?
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Don Brown <mr...@twdata.org>.
On Wed, 17 Dec 2003, Joe Germuska wrote:
> >- Make Inversion of Control central. By using an IoC framework to wire
> >Struts together, it makes it really easy to extend or improve Struts not
> >only for future development but for users as well. I'd recommend Spring's
> >IoC impl as it is small (>100k), really easy to use, and easily
> >extendable. If we wanted to remain more "agnostic", there are "meta" IoC
> >frameworks that let you plug in Pico/Spring/Avalon, etc.
>
> Personally I suspect that a meta framework is more trouble than it's
> worth, although I haven't really looked at any too closely. (Have
> any pointers)
>
> So then, with specific frameworks, I don't understand how Pico's
> orientation towards constructors works in an environment where beans
> need to be dynamically instantiated, but perhaps I just haven't
> thought about it hard enough. Avalon seems too heavy, which leaves
> us (or me at least) with Spring and HiveMind. I haven't developed
> with either but so far the docs for Spring give me a warm fuzzy
> feeling while the HiveMind docs kind of scare me.
HiveMind, from what I've read, is more service-oriented. I've been using
Spring for a few months now and totally loving it. It completely stays
out of your way, leaving your code with little or no Spring dependencies.
Furthermore, it supports both javabean and constructor-style dependency
resolution.
> >- Use XML Schema over DTD's. Give struts config its own default namespace
> >to make it easier for users to mix in elements of other namespaces. An
> >example would be adding custom documentation attributes and elements. Of
> >course the usual arguments for XML Schema over DTD's apply as well.
>
> XML Schema?! Naw, RelaxNG!!! After all, it is "now an international
> standard"
> (http://blogs.codehaus.org/people/bob/archives/000505_standards_are_great_everyone_should_have_one.html)
Doesn't matter to me as long as I get namespace support :)
> >- Replace paths with URL's, allowing for a default protocol. An action
> >path would look like "action://foo" or a tiles forward would be
> >"tiles://tilesdef" This would make it easy to plug in handlers to support
> >different presentation engines. If no protocol is specified, the path is
> >handled as usual.
>
> I'm a little sketched out about assigning schemes of our own. I see
> the motivation, and think the goal is good. Wonder if we could find
> another mechanism.
Well, I've seen it used particularly in Forrest to good effect. The key
is keeping the number of "protocols" to a small number, but allowing the
user to develop more if they feel the need.
Don
>
> >- As Ted said, contine with the wildcard theme. Struts should do
> >everything possible to cut down configuration.
>
> hear, hear! (, hear, hear, hear!!)
>
> >- Also, again totally agreeing with Ted, make everything interface based,
>
> a few more hears here ;^)
>
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "We want beef in dessert if we can get it there."
> -- Betty Hogan, Director of New Product Development, National
> Cattlemen's Beef Association
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Joe Germuska <Jo...@Germuska.com>.
>- Make Inversion of Control central. By using an IoC framework to wire
>Struts together, it makes it really easy to extend or improve Struts not
>only for future development but for users as well. I'd recommend Spring's
>IoC impl as it is small (>100k), really easy to use, and easily
>extendable. If we wanted to remain more "agnostic", there are "meta" IoC
>frameworks that let you plug in Pico/Spring/Avalon, etc.
Personally I suspect that a meta framework is more trouble than it's
worth, although I haven't really looked at any too closely. (Have
any pointers)
So then, with specific frameworks, I don't understand how Pico's
orientation towards constructors works in an environment where beans
need to be dynamically instantiated, but perhaps I just haven't
thought about it hard enough. Avalon seems too heavy, which leaves
us (or me at least) with Spring and HiveMind. I haven't developed
with either but so far the docs for Spring give me a warm fuzzy
feeling while the HiveMind docs kind of scare me.
>- Use XML Schema over DTD's. Give struts config its own default namespace
>to make it easier for users to mix in elements of other namespaces. An
>example would be adding custom documentation attributes and elements. Of
>course the usual arguments for XML Schema over DTD's apply as well.
XML Schema?! Naw, RelaxNG!!! After all, it is "now an international
standard"
(http://blogs.codehaus.org/people/bob/archives/000505_standards_are_great_everyone_should_have_one.html)
>- Replace paths with URL's, allowing for a default protocol. An action
>path would look like "action://foo" or a tiles forward would be
>"tiles://tilesdef" This would make it easy to plug in handlers to support
>different presentation engines. If no protocol is specified, the path is
>handled as usual.
I'm a little sketched out about assigning schemes of our own. I see
the motivation, and think the goal is good. Wonder if we could find
another mechanism.
>- As Ted said, contine with the wildcard theme. Struts should do
>everything possible to cut down configuration.
hear, hear! (, hear, hear, hear!!)
>- Also, again totally agreeing with Ted, make everything interface based,
a few more hears here ;^)
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Posted by Don Brown <mr...@twdata.org>.
Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
release work. :) I'll throw out some ideas here, then develop them later
in the wiki:
- Make Inversion of Control central. By using an IoC framework to wire
Struts together, it makes it really easy to extend or improve Struts not
only for future development but for users as well. I'd recommend Spring's
IoC impl as it is small (>100k), really easy to use, and easily
extendable. If we wanted to remain more "agnostic", there are "meta" IoC
frameworks that let you plug in Pico/Spring/Avalon, etc.
- Use XML Schema over DTD's. Give struts config its own default namespace
to make it easier for users to mix in elements of other namespaces. An
example would be adding custom documentation attributes and elements. Of
course the usual arguments for XML Schema over DTD's apply as well.
- Replace paths with URL's, allowing for a default protocol. An action
path would look like "action://foo" or a tiles forward would be
"tiles://tilesdef" This would make it easy to plug in handlers to support
different presentation engines. If no protocol is specified, the path is
handled as usual.
- As Ted said, contine with the wildcard theme. Struts should do
everything possible to cut down configuration.
- Also, again totally agreeing with Ted, make everything interface based,
have default implementations, and free apps of HTTP. Ideally, I'd like to
see extra effort going into making it easy if not effortless to take a
Struts 2.0 app and use the code in a portlet or web service environment.
At least in my area, clients are wanting human and machine interfaces,
with the human interface generally being behind a portal.
Anyways, those are my "brainstorming" thoughts. If any look interesting,
I'll write something up in the wiki.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Discussion Forum
Posted by James Mitchell <jm...@apache.org>.
On Wed, 17 Dec 2003, Don Brown wrote:
> Is there one? I have several ideas I'd like to toss into the discussion.
I'm +1 for keeping it here on the dev list. (if that's what you meant)
>
> Don
>
> On 17 Dec 2003 husted@apache.org wrote:
>
> > husted 2003/12/17 12:49:28
> >
> > Added: contrib/struts-jericho README.txt project.properties
> > project.xml
> > Log:
> > Create whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x.
> >
> > Revision Changes Path
> > 1.1 jakarta-struts/contrib/struts-jericho/README.txt
> >
> > Index: README.txt
> > ===================================================================
> > Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x.
> >
> > Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a codename to a proposal until the Community comes to a consensus.
> >
> > This proposal is called "Jericho" since it tries to tear-down the walls within the Struts architecture. Jericho proposes to open-up Struts by
> >
> > * Declaring interfaces for all core components.
> >
> > * Providing working base implementations for all core components.
> >
> > * Encapsulating alll path references within "Location" objects (fka ActionForwards)and referring only to Locations from all other objects.
> >
> > * Providing additional extension points from core components so that the "Inversion of Control" pattern is fully realized.
> >
> > * Providing "POJO" signatures that encapsulate HTTP classes so that applications can be freed of HTTP semantics, if so desired.
> >
> > * Retain optional access to HTTP objects so that applications can be free to do whatever they need to do.
> >
> > -Backward Compatibility-
> >
> > Jericho is a revolution and backward compatability with prior versions of Struts is not the prime consideration. However, care is being taken to create a clear migration path, where practible, so that Jericho is available to the widest community possible.
> >
> > _DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
> >
> > A second alternative to explore is to provide an alternate configuration loader that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
> >
> > _Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to provided. These classes will provide the Struts 1.2.x behavior but also implement the Struts Jericho interfaces, so that the framework can use them interchangeably.
> >
> > These same techniques may be applied to provide adaptors for other frameworks, so as to make Struts Jericho available to the widest community possible.
> >
> > ###
> >
> >
> > 1.1 jakarta-struts/contrib/struts-jericho/project.properties
> >
> > Index: project.properties
> > ===================================================================
> > # -------------------------------------------------------------------
> > # P R O J E C T P R O P E R T I E S
> > # -------------------------------------------------------------------
> >
> > compile.debug = on
> > compile.optimize = off
> > compile.deprecation = off
> >
> > maven.linkcheck.enable=true
> >
> > # documentation properties
> > maven.xdoc.date=left
> > maven.xdoc.version=${pom.currentVersion}
> > maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
> >
> >
> >
> > 1.1 jakarta-struts/contrib/struts-jericho/project.xml
> >
> > Index: project.xml
> > ===================================================================
> > <?xml version="1.0" encoding="UTF-8"?>
> >
> > <project>
> > <extend>../project.xml</extend>
> > <name>Jericho</name>
> > <id>struts-jericho</id>
> > <currentVersion>0.1-dev</currentVersion>
> > <inceptionYear>2003</inceptionYear>
> > <shortDescription>Struts Jericho 2.x Whiteboard</shortDescription>
> > <description>
> > Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x.
> > Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a codename to a proposal
> > until the Community comes to a consensus.
> > This proposal is called "Jericho" since it tries to tear-down the walls within the Struts architecture.
> > </description>
> > <developers>
> > <developer>
> > <name>Ted Husted</name>
> > <id>husted</id>
> > <email>husted@apache.org</email>
> > <organization></organization>
> > </developer>
> > </developers>
> >
> > <build>
> > <unitTest>
> > <includes>
> > <include>**/*Test.java</include>
> > </includes>
> > </unitTest>
> > </build>
> >
> > </project>
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
--
James Mitchell
Software Developer / Struts Evangelist
http://www.struts-atlanta.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Discussion Forum
Posted by Martin Cooper <ma...@apache.org>.
On Wed, 17 Dec 2003, Don Brown wrote:
> Is there one? I have several ideas I'd like to toss into the discussion.
Yep. This is it.
--
Martin Cooper
>
> Don
>
> On 17 Dec 2003 husted@apache.org wrote:
>
> > husted 2003/12/17 12:49:28
> >
> > Added: contrib/struts-jericho README.txt project.properties
> > project.xml
> > Log:
> > Create whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x.
> >
> > Revision Changes Path
> > 1.1 jakarta-struts/contrib/struts-jericho/README.txt
> >
> > Index: README.txt
> > ===================================================================
> > Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x.
> >
> > Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a codename to a proposal until the Community comes to a consensus.
> >
> > This proposal is called "Jericho" since it tries to tear-down the walls within the Struts architecture. Jericho proposes to open-up Struts by
> >
> > * Declaring interfaces for all core components.
> >
> > * Providing working base implementations for all core components.
> >
> > * Encapsulating alll path references within "Location" objects (fka ActionForwards)and referring only to Locations from all other objects.
> >
> > * Providing additional extension points from core components so that the "Inversion of Control" pattern is fully realized.
> >
> > * Providing "POJO" signatures that encapsulate HTTP classes so that applications can be freed of HTTP semantics, if so desired.
> >
> > * Retain optional access to HTTP objects so that applications can be free to do whatever they need to do.
> >
> > -Backward Compatibility-
> >
> > Jericho is a revolution and backward compatability with prior versions of Struts is not the prime consideration. However, care is being taken to create a clear migration path, where practible, so that Jericho is available to the widest community possible.
> >
> > _DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
> >
> > A second alternative to explore is to provide an alternate configuration loader that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
> >
> > _Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to provided. These classes will provide the Struts 1.2.x behavior but also implement the Struts Jericho interfaces, so that the framework can use them interchangeably.
> >
> > These same techniques may be applied to provide adaptors for other frameworks, so as to make Struts Jericho available to the widest community possible.
> >
> > ###
> >
> >
> > 1.1 jakarta-struts/contrib/struts-jericho/project.properties
> >
> > Index: project.properties
> > ===================================================================
> > # -------------------------------------------------------------------
> > # P R O J E C T P R O P E R T I E S
> > # -------------------------------------------------------------------
> >
> > compile.debug = on
> > compile.optimize = off
> > compile.deprecation = off
> >
> > maven.linkcheck.enable=true
> >
> > # documentation properties
> > maven.xdoc.date=left
> > maven.xdoc.version=${pom.currentVersion}
> > maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
> >
> >
> >
> > 1.1 jakarta-struts/contrib/struts-jericho/project.xml
> >
> > Index: project.xml
> > ===================================================================
> > <?xml version="1.0" encoding="UTF-8"?>
> >
> > <project>
> > <extend>../project.xml</extend>
> > <name>Jericho</name>
> > <id>struts-jericho</id>
> > <currentVersion>0.1-dev</currentVersion>
> > <inceptionYear>2003</inceptionYear>
> > <shortDescription>Struts Jericho 2.x Whiteboard</shortDescription>
> > <description>
> > Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x.
> > Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a codename to a proposal
> > until the Community comes to a consensus.
> > This proposal is called "Jericho" since it tries to tear-down the walls within the Struts architecture.
> > </description>
> > <developers>
> > <developer>
> > <name>Ted Husted</name>
> > <id>husted</id>
> > <email>husted@apache.org</email>
> > <organization></organization>
> > </developer>
> > </developers>
> >
> > <build>
> > <unitTest>
> > <includes>
> > <include>**/*Test.java</include>
> > </includes>
> > </unitTest>
> > </build>
> >
> > </project>
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Context attributes (was: Struts 2.0 Discussion Forum)
Posted by Hubert Rabago <ja...@yahoo.com>.
What about allowing Action objects to add the parameters themselves? It adds a
great deal of flexibility, and doesn't limit the set of parameters that can be
used, nor does it require using the request or session attributes.
ActionForward forward = mapping.findForward("lookup");
forward.addParameter("param1","value1");
forward.addParameter("param2",2);
forward.addParameter("param3",3.0);
return forward;
Or maybe support for both (merge and addParameter).
This will also make bug 866 go away.
--- Ted Husted <hu...@apache.org> wrote:
> Don Brown wrote:
> > Is there one? I have several ideas I'd like to toss into the
> > discussion.
> >
> > Don
>
> There's a Whiteboard page in the Wiki.
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard
>
> I'll be posting more about Jericho, but wanted to get what I had so far
> (a starter DTD) under CVS.
>
> One other idea that I've been meaning to bring up in the wake of
> wildcard Mappings, is the idea of merging context attributes into
> ActionForward paths. For example, we could do something like
>
> <forward name="lookup" merge="true" path="/lookup.do?key={key}" />
>
> and have it replace {key} with request.getAttribute("key") (or session
> if not found).
>
> -Ted.
>
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts 2.0 Discussion Forum
Posted by Ted Husted <hu...@apache.org>.
Don Brown wrote:
> Is there one? I have several ideas I'd like to toss into the
> discussion.
>
> Don
There's a Whiteboard page in the Wiki.
http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard
I'll be posting more about Jericho, but wanted to get what I had so far
(a starter DTD) under CVS.
One other idea that I've been meaning to bring up in the wake of
wildcard Mappings, is the idea of merging context attributes into
ActionForward paths. For example, we could do something like
<forward name="lookup" merge="true" path="/lookup.do?key={key}" />
and have it replace {key} with request.getAttribute("key") (or session
if not found).
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org