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 2005/08/02 17:44:14 UTC
[Proposal] Struts Ti
I'd been waiting to announce/propose this until I could write up a
decent proposal and have the code in a better state, but with all the
talk about Struts 2.0, "good" now is better than "better" tomorrow I
suppose. The following is a proposal for Struts Ti, a possible
successor to Struts classic:
Struts Ti is a simplified Model 2 framework for developing webapps which
allows the developer better access to the underlying servlet/portlet
environment. It serves a niche of web applications that don’t want the
additional complexity of server-side components and verbose
configuration, yet want the structure and controller features of a
modern web framework. Struts Ti builds on the directions of Struts 1.x,
yet re-implements the framework to provide a clean slate for the next
generation of Struts Ti. It aims to combine the simplicity of Ruby on
Rails and NanoWeb, the refinement of WebWork 2, the tool-friendly
authoring and Page Flow of Beehive, and the lessons learned from Struts 1.x.
The key word for Struts Ti is simplicity. Ideally, Struts Ti should
approach Ruby on Rails levels of easy of use, yet scale up to large
applications providing a smooth transition to JSF/Shale if desired.
Key Features
* POJO-based action that combines an Action and ActionForm in a
similar manner to JSF backing beans and WebWork 2 Commands
* Intelligent defaults utilizing naming and placement conventions
to require minimal, if any, configuration per page, however it will be
possible to override everything on a global and per-action basis
* Configuration can be “assumed” or declared through annotations,
xml or properties files, or any other pluggable mechanism
* Pluggable EL for data binding defaulting to JSP 2.0 EL but
allowing OGNL or even BeanUtils
* Integration of a dialog or page flow capability drawing from
Beehive, Spring’s web flow, and Shale’s Dialogs.
* Per-Action optional interceptor chain ala WebWork 2
* Built-in dependency injection support
Design Goals
* No servlet dependency in core framework, portlet and JSF support
out of the box
* Spring-based dependency injection in core to allow for pluggability
* No bias to any view technology
* Ability to layer Struts 1.x compatibility on top
* Highly toolable
* Smooth integration into a portal/portlet environment
* AJAX-friendly
Implementation
* Built on the backbone of commons-chain
* No restriction on multiple Servlets and/or Servlet Filter
implementations
* Key decision points (action selection for example) use CoR chain
for maximum flexiblity
* Configuration specified using XDoclet (Java 1.4) or Annotations
(Java 5+), both supported out of the box
Dependencies
* Servlets 2.4
* Java 1.4 runtime, Java 1.5 to build
* JSP 2.0 if taglibs used
Existing project collaboration
* XWork/WebWork using their XWork and possibly parts/all of their
tag libraries
* Beehive using the Page Flow and annotations
Status
I've setup a project site for myself and have a working, if feature
sparce, framework in place. In feeling out the scope of the project,
I've been working with the two projects above as I want to avoid
reimplementing anything I don't have to, and think there is a lot of
synergy to be had.
At this point, the project site, code, and more detailed design
discussions are on my personal server:
https://www.twdata.org/projects/struts-ti
However, I plan to move everything over to the sandbox to start the
incubation process and await acceptance by the Struts PMC and developer
community. I've stated before and I'm sure I'll be stating again, and
again, Struts Ti does NOT compete with Struts Shale, as I see them, if
accepted, as two sibiling projects serving different niches.
I've been watching the Struts 2.0 threads with interest and hope this
proposal meets the needs of the Struts community for a successor to
Struts Classic.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by Don Brown <mr...@twdata.org>.
Dakota Jack wrote:
<snip />
> How are you going to allow IoC dependency injection and build on the
> backbone of commons-chain? Those seem to be inherently incompatible.
> Isn't the chain necessary only where you use a Template-Method Pattern
> rather than a Strategy Pattern, as the recommended relationship
> between the view and the controller by GoF, and accordingly have IoC
> problems?
In Struts Ti, they are used for two entirely different purposes:
commons-chain is used when it needs to define a business process in a
flexible, extendable manner (do this, then do this, then this, etc), and
Spring when I want to abstract the creation of objects from the code
(provide a Servlet-specific implementation without the target code
knowing or caring). Commons-chain is important as it lets the developer
inject code into Ti processes or handle a decision differently. Spring
lets me load an entirely different object set based on environment
(servlet, portlet, etc) so I can keep the core clean of platform
dependencies.
In Struts 1.3, we use one big chain commons-chain (two if you include
the exception handling) to handle the request, but in Ti, I'm looking
into using smaller, single-purposed chains to abstract key decisions
like Action creation to allow Ti to ship with support for WebWork
actions, Page Flow controllers, or classic Struts Actions, yet the
developer can easily add chain commands to add support for their
preferred Action implementation.
Don
>
>
>>At this point, the project site, code, and more detailed design
>>discussions are on my personal server:
>>
>>https://www.twdata.org/projects/struts-ti
>>
>
>
> This looks promising. I will be following with a lot of interest. Good show!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by Dakota Jack <da...@gmail.com>.
This all sounds good, Don, and I have been an admirer of your "horse
sense" for some time. I especially like the emphasis on KISS. I have
a few comments infra.
On 8/2/05, Don Brown <mr...@twdata.org> wrote:
> I'd been waiting to announce/propose this until I could write up a
> decent proposal and have the code in a better state, but with all the
> talk about Struts 2.0, "good" now is better than "better" tomorrow I
> suppose. The following is a proposal for Struts Ti, a possible
> successor to Struts classic:
I like the name Struts-Titanium too. That has the right feel for what
would be a good framework's attributes: light and strong.
>
> Struts Ti is a simplified Model 2 framework for developing webapps which
> allows the developer better access to the underlying servlet/portlet
> environment. ..........
> The key word for Struts Ti is simplicity. Ideally, Struts Ti should
> approach Ruby on Rails levels of easy of use, yet scale up to large
> applications providing a smooth transition to JSF/Shale if desired.
GREAT!
> * POJO-based action that combines an Action and ActionForm in a
> similar manner to JSF backing beans and WebWork 2 Commands
Allowing multiple ActionForms per Action would be a blessing, This
would allow you, where you have the following flow ActionA --> FormA
--> ActionB --> FormB --> ActionC and allow ActionB to share FormA
with ActionA and FormB with ActionC.
> * Spring-based dependency injection in core to allow for pluggability
GREAT!
> * Built on the backbone of commons-chain
How are you going to allow IoC dependency injection and build on the
backbone of commons-chain? Those seem to be inherently incompatible.
Isn't the chain necessary only where you use a Template-Method Pattern
rather than a Strategy Pattern, as the recommended relationship
between the view and the controller by GoF, and accordingly have IoC
problems?
> At this point, the project site, code, and more detailed design
> discussions are on my personal server:
>
> https://www.twdata.org/projects/struts-ti
>
This looks promising. I will be following with a lot of interest. Good show!
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by Don Brown <mr...@twdata.org>.
Michael Jouravlev wrote:
<snip />
>> * POJO-based action that combines an Action and ActionForm in a
>>similar manner to JSF backing beans and WebWork 2 Commands
>
>
> I am all in for this, but preserving compatibility with current
> Action/ActionForm
Struts Ti and particularly its underlying workhorse XWork, allows you to implement Actions however you'd like. The
default implementation will be a JSF/Ruby on Rails style POJO controller with annotations. We will provide a Struts
compatibility layer which will support regular Struts actions and forms.
>> * Integration of a dialog or page flow capability drawing from
>>Beehive, Spring's web flow, and Shale's Dialogs.
>
>
> How about Struts Dialogs? They are fully compatible with current
> codebase and provide dialog and wizard support. Beehive seem to be too
> heavy for me.
The Beehive folks are re-implementing their Page Flow on top of Struts Ti and XWork. They bring experience with
toolability and Java 5 annotations which I personally don't have. My main complaint of Beehive is their verbose
annotations, however, they are working on that and for those that like it as simple as possible, Ti supports
XDoclet-style annotations simultaneously.
>
>
>>Design Goals
>>
>> * No servlet dependency in core framework,
>
>
> I don't like that. This is a *web* framework, I want to have easy
> access to plumbing. I can see how WebWork guys are tired of answering
> questions "how I can get my request".
As I said, Ti will have a Struts classic compatibility layer which will let you use Actions and ActionForms, if you are
more comfortable with them.
>
>
>>portlet and JSF support
>>out of the box
>
>
> Does not Shale support JSF out of the box? What is the point for Ti
> then? I would say, than new Struts version should work with current
> technologies like JSP and not force using new markup.
If you are happy with JSF and/or Shale, feel free to use it. Struts Ti is aiming for a simple, clean framework that
requires no configuration, is Action-first rather than Page-first, can run in multiple environments, and use any
presentation technology, JSF and JSP included.
Regarding flow, have a closer look at Beehive. Their page flow is intuitive and tested, not to mention toolable. In
fact, they just had their first open source release and I believe are now a top level Apache project.
Don
>
>
>> * No bias to any view technology
>
>
> Well, using scope objects like request or session, every Java
> framework is biased towards JSP. Is it not true?
>
> Couple of words about flow. I think about flow for the third year, I
> had several iterations, and now I came to thinking that flow is not
> needed. I mean, the global application flow is not needed. It only
> ties up actions/pages to each other, and is hard to maintain.
>
> What I think of istead of flow, is "web islands", autonomous actions
> which can have built-in mini-flow in them if needed. That is, one
> action has set of states and can render different pages according to
> state.
>
> Moving from action to action, from web island to web island should be
> flow-less. Either an action accept input in its current state, or is
> not. Either it can render itself in its state, or its not. How does a
> user get to this action, should not be hardcoded.
>
> Why would not you take a look at the simple wizard that can be created
> using current Struts codebase:
> http://struts.sourceforge.net/strutsdialogs/wizardaction.html There is
> a live demo available which you can try.
>
> I want to donate my project to Struts and I am open to suggestions.
>
> I rewrote MailReader using Struts Dialogs, I wanted to clean it up and
> to write decent docs, but I guess no time for that, so I will upload
> it to my demo server in couple of days.
>
> Michael.
>
> ---
> Struts Dialogs: build components, controls and wizards easier.
> http://struts.sourceforge.net/strutsdialogs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by Michael Jouravlev <jm...@gmail.com>.
On 8/2/05, Don Brown <mr...@twdata.org> wrote:
> Struts Ti is a simplified Model 2 framework for developing webapps which
> allows the developer better access to the underlying servlet/portlet
> environment.
This is I agree with.
> It serves a niche of web applications that don't want the
> additional complexity of server-side components and verbose
> configuration, yet want the structure and controller features of a
> modern web framework.
This I don't get.
> Key Features
>
> * POJO-based action that combines an Action and ActionForm in a
> similar manner to JSF backing beans and WebWork 2 Commands
I am all in for this, but preserving compatibility with current
Action/ActionForm
> * Pluggable EL for data binding defaulting to JSP 2.0 EL but
> allowing OGNL or even BeanUtils
Nice
> * Integration of a dialog or page flow capability drawing from
> Beehive, Spring's web flow, and Shale's Dialogs.
How about Struts Dialogs? They are fully compatible with current
codebase and provide dialog and wizard support. Beehive seem to be too
heavy for me.
> Design Goals
>
> * No servlet dependency in core framework,
I don't like that. This is a *web* framework, I want to have easy
access to plumbing. I can see how WebWork guys are tired of answering
questions "how I can get my request".
> portlet and JSF support
> out of the box
Does not Shale support JSF out of the box? What is the point for Ti
then? I would say, than new Struts version should work with current
technologies like JSP and not force using new markup.
> * No bias to any view technology
Well, using scope objects like request or session, every Java
framework is biased towards JSP. Is it not true?
Couple of words about flow. I think about flow for the third year, I
had several iterations, and now I came to thinking that flow is not
needed. I mean, the global application flow is not needed. It only
ties up actions/pages to each other, and is hard to maintain.
What I think of istead of flow, is "web islands", autonomous actions
which can have built-in mini-flow in them if needed. That is, one
action has set of states and can render different pages according to
state.
Moving from action to action, from web island to web island should be
flow-less. Either an action accept input in its current state, or is
not. Either it can render itself in its state, or its not. How does a
user get to this action, should not be hardcoded.
Why would not you take a look at the simple wizard that can be created
using current Struts codebase:
http://struts.sourceforge.net/strutsdialogs/wizardaction.html There is
a live demo available which you can try.
I want to donate my project to Struts and I am open to suggestions.
I rewrote MailReader using Struts Dialogs, I wanted to clean it up and
to write decent docs, but I guess no time for that, so I will upload
it to my demo server in couple of days.
Michael.
---
Struts Dialogs: build components, controls and wizards easier.
http://struts.sourceforge.net/strutsdialogs
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Session tracking with URL rewriting does not work with higher
versions of struts.
Posted by Joe Germuska <Jo...@Germuska.com>.
>On further analysis this is what we have found out.
>There is no "RequestProcessor.java" in struts 1.0.2 . This class is been
>introduced from struts1.1. Enabling struts trace i could see that struts
>ActionServlet is calling "sendError 400 Invalid path
>;jsessionid=0000gE0mwjqt37IqNxCy0s2UO15:-1 was requested" when it cannot
>find the path mapping. The reason i think same code is working on v5 and
>not on v6 is there might be a behavior change to "request.getPathInfo()"
>method. What i noticed is in v5, when there is jsessionid in path it is
>getting ignored by getPathInfo but in v6 its returning even jsessionid.
>Ideally, struts code should be handling the case where we have jsessionid
>for the path info.
>It looks like struts may need to trim off path parameters (ones that
>start with ;jsessionid) when checking if pathInfo exists or not.
What servlet container are you using? Struts should have no
responsibilities regarding session management; this should all be
dealt with before the servlet is invoked; in fact, I do not believe
that any servlet container I've ever used passes the jsessionid as
part of the path info, although I can't say that I've definitively
tested it.
You refer to "v5" and "v6" with no referents. Are those versions of
the servlet container you use? Or of your application?
I've been writing Struts apps for years that run on Tomcat 4 and 5
and JBoss 3.2.x without ever having any problems with path-encoded
session IDs. But it's been quite a while since I was working on a
Struts 1.0.x app.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Session tracking with URL rewriting does not work with higher versions of
struts.
Posted by Anju Geethabai <ag...@in.ibm.com>.
Our application is built on struts frame work..
Moving from a previous version of struts (1.0.2) to struts 1.1 we have
seen that Session management using URL rewriting is not working properly.
Our logs shows that the class RequestProcessor from struts is throwing
the below error
[4/7/05 15:26:21:449 IST] 00000029 RequestProces E Invalid path
;jsessionid=0000YA6Ii38gBdA2u8Nbf7EKc8c:-1 was requested
We tried printing out the request paramters when invoking an applicatiion
which is using session handling through URL rewriting.
The results:
using Struts 1.0.2
URL invoked ->
http://localhost:9080/snoop;jsessionid=0000gE0mwjqt37iqNxCy0s2U015:--1
Pathinfo =<none>
Using Struts 1.1
URL invoked ->
http://localhost:9080/snoop;jsessionid=0000gE0mwjqt37iqNxCy0s2U015:--1
pathinfo =;jsessionid=0000gE0mwjqt37iqNxCy0s2U015:--1
On further analysis this is what we have found out.
There is no "RequestProcessor.java" in struts 1.0.2 . This class is been
introduced from struts1.1. Enabling struts trace i could see that struts
ActionServlet is calling "sendError 400 Invalid path
;jsessionid=0000gE0mwjqt37IqNxCy0s2UO15:-1 was requested" when it cannot
find the path mapping. The reason i think same code is working on v5 and
not on v6 is there might be a behavior change to "request.getPathInfo()"
method. What i noticed is in v5, when there is jsessionid in path it is
getting ignored by getPathInfo but in v6 its returning even jsessionid.
Ideally, struts code should be handling the case where we have jsessionid
for the path info.
It looks like struts may need to trim off path parameters (ones that
start with ;jsessionid) when checking if pathInfo exists or not.
Please let us know if this issue has been resolved or will be taken up.
Thanks for any help regarding this
Regards
Anju
Re: [Proposal] Struts Ti
Posted by Don Brown <mr...@twdata.org>.
Joe Germuska wrote:
> I agree that the EL support, especially if designed to be pluggable,
> should be as consistent as possible between projects. I'd like to see
> how Don has set up the configurability in Struts-Ti (btw, how is that
> pronounced anyway? Is it like "Titantium"? or like "tie"? or like
> "tea"? Am I really the first one to ask?)
I'm going with Titanium. I'm an ultralight backpacker so Titanium is near and dear to my heart - very light, yet
surprisingly strong.
Regarding configurability, that is where Spring and interface-driven development comes in. Commons-chain helps with key
decision points to allow someone to plug in their own behavior. Concerning EL support, XWork, the action framework for
Ti, relies on OGNL. I'm working with the WebWork guys on abstracting that out so it will be pluggable. OGNL has a lot
of power, however, if you are using JSP 2.0, you might want to keep the EL consistent.
Don
>
> Joe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by Joe Germuska <Jo...@Germuska.com>.
At 3:41 PM -0500 8/2/05, Michael Rasmussen wrote:
> I wrote a patch for Chain a couple weeks ago that created support
>for an EL. It uses JSTL-EL by default and was designed with the idea
>that it would be pluggable. The patch is just sitting there, I don't
>know what you are using for Struts-Ti, but it seems like if you are
>going to add pluggable EL support and use chain it should be
>consistent across the projects. THe patch is not committed yet. Joe
>Germuska was going to look at it when he got back from vacation, but
>he seems to have taken a LONG vacation.
I wish! I just haven't had much spare time to devote to open source
projects since I've been back.
I agree that the EL support, especially if designed to be pluggable,
should be as consistent as possible between projects. I'd like to see
how Don has set up the configurability in Struts-Ti (btw, how is
that pronounced anyway? Is it like "Titantium"? or like "tie"? or
like "tea"? Am I really the first one to ask?)
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by Michael Rasmussen <ra...@gmail.com>.
On 8/2/05, Don Brown <mr...@twdata.org> wrote:
> Key Features
> * Pluggable EL for data binding defaulting to JSP 2.0 EL but
> allowing OGNL or even BeanUtils
>
> Design Goals
>
> Implementation
>
> * Built on the backbone of commons-chain
Don,
I wrote a patch for Chain a couple weeks ago that created support
for an EL. It uses JSTL-EL by default and was designed with the idea
that it would be pluggable. The patch is just sitting there, I don't
know what you are using for Struts-Ti, but it seems like if you are
going to add pluggable EL support and use chain it should be
consistent across the projects. THe patch is not committed yet. Joe
Germuska was going to look at it when he got back from vacation, but
he seems to have taken a LONG vacation.
The bugzilla ticket is here if you are interested.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35326
The patch is for CVS and not SVN, which I need to change, but haven't
gotten around to.
Excuse my "patch plugging", I just thought it might be useful to your work.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by Don Brown <mr...@twdata.org>.
netsql wrote:
> Don Brown wrote:
>
>> * No servlet dependency in core framework, portlet and JSF support
>> out of the box
>>
> 1. + Ajax, Jax-WS, Axis/DocLit... JDNC, XUL, .... for us lunies doing
> UI layer rendering on the client. There has to be a "process request"
> signature that lets us do all.
> Ex: List process(Context)
I agree it is important to keep it platform-independent. Since Struts
Ti is built on OpenSymphony's XWork and Apache's commons-chain, the core
can be kept clean and should allow more adventurous developers like
yourself to adapt it to new environments. One interesting feature of
WebWork2 I've been discussing with those guys is their view-independent
taglib. Not only is it not tied to HTML, but not tied to JSP. We are
looking at ways to collaborate so both projects can benefit.
Which reminds me, I want to reiterate the purpose of Struts Ti -
simplicity, but if I picked a second purpose, it'd be collaboration.
There are a lot of great ideas and code out there, yet few instances of
open source projects working together. Struts Ti started out from
discussions with WebWork/XWork and Beehive and it is my goal to continue
to collaborate rather than compete.
>
> 2. I would also say... a big benfit would be a DAO interface. The famous
> populate().... or populate(Map) or my fave ArrayList populate(Map)
> For the people that want to have a way to swap a Dao impl.
>
> 3. And to make it C# possible... all user exposed classes should be an
> interface (so that same interface could be reimplemented).
> Ex: BeanActionApi x = new BeanActionImpl()
> and put all Api into one package
> org.struts.api
> So one could have
> org.struts.csharpimpl
> (an issue on ibatis is that 2 api are different).
Very interesting point; I hadn't thought of that. Currently, the core
is interface-driven, almost to a fault, which would hopefully facilitate
multi-language use. Thanks for pointing this out.
Take a look at what we have so far and let me know what you think.
While I do want to keep it on the view tier, let me know if it is in
line with what you are thinking.
Don
> 4. JMX. To track requests, users, dao, etc.
>
> I think it could help put all on same page.
> How about this:
> All "layers" should do
> List execute(Context)
> Ex:
> Contex ctx= {populate, selectCient, client=GM}
> List populate(ctx) to dao, to get rows
> or
> List process(ctx) for "RPC", to return to rendering layer all known /
> needed info.
>
> (Note how collections are a not too strongly typed)
>
> that's all ;-)
>
> .V
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by Ted Husted <te...@gmail.com>.
On 8/2/05, netsql <ne...@roomity.com> wrote:
> Michael, in esence, one could just cut and paste the code from
> "org.struts.api" to C#, fixing syntax as needed.
Struts Classic would be hard port, because of all the HTTP references.
There are .NET equivalents, but the syntax is very diffeent, and the
paradigm would not be so useful for ASP.NET applications (ASP classic,
maybe).
Commons Chain of Responsiblity, on the other hand, was a very easy
port. CoR is a very nifty way to call business logic from the
code-behinds, especially when you throw Spring.Web into the mix.
>
> Then in esence people that use it in one or the other have the same
> signature. Some users may never know how it's implemented. The issue is
> more interesting on iBatis, where they have "smilar" usage, but not same.
Once you get past the config, they are very much alike. Mainly, there
are feature-set differences where one implementation is running ahead
or behind the other. The expected feature-set will probably be
resolved in the 3.x timeframe. My own goal is to be able to reuse the
iBATIS mapping files, as is, between implementations.
Some Struts-like frameworks with multiple implementations, like
FuseBox, can also share configuration files between implementations.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by Laurie Harper <la...@holoweb.net>.
I've also seen at least one JVM stack for .Net, allowing you to
mix-and-match Java and C# in the same application.
L.
netsql wrote:
> Michael, in esence, one could just cut and paste the code from
> "org.struts.api" to C#, fixing syntax as needed.
>
> Then in esence people that use it in one or the other have the same
> signature. Some users may never know how it's implemented. The issue is
> more interesting on iBatis, where they have "smilar" usage, but not same.
>
> .V
>
>
> Michael Rasmussen wrote:
>
>> netsql wrote:
>>
>>> 3. And to make it C# possible... all user exposed classes should be an
>>> interface (so that same interface could be reimplemented).
>>
>>
>>
>> I don't get this. maybe I missed something here, (entirely possible)
>> but how are you going to write an underlying implementation in C# that
>> can be called by Java? Or vice versa? I totally agree that all the
>> API should be interfaces, but I'm not sure that the reason should be
>> that you can reimplement it in C#. Please explain.
>>
>> Thanks,
>> Michael
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/laurie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by netsql <ne...@roomity.com>.
Michael, in esence, one could just cut and paste the code from
"org.struts.api" to C#, fixing syntax as needed.
Then in esence people that use it in one or the other have the same
signature. Some users may never know how it's implemented. The issue is
more interesting on iBatis, where they have "smilar" usage, but not same.
.V
Michael Rasmussen wrote:
> netsql wrote:
>
>>3. And to make it C# possible... all user exposed classes should be an
>>interface (so that same interface could be reimplemented).
>
>
> I don't get this. maybe I missed something here, (entirely possible)
> but how are you going to write an underlying implementation in C# that
> can be called by Java? Or vice versa? I totally agree that all the
> API should be interfaces, but I'm not sure that the reason should be
> that you can reimplement it in C#. Please explain.
>
> Thanks,
> Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by Michael Rasmussen <ra...@gmail.com>.
netsql wrote:
>3. And to make it C# possible... all user exposed classes should be an
>interface (so that same interface could be reimplemented).
I don't get this. maybe I missed something here, (entirely possible)
but how are you going to write an underlying implementation in C# that
can be called by Java? Or vice versa? I totally agree that all the
API should be interfaces, but I'm not sure that the reason should be
that you can reimplement it in C#. Please explain.
Thanks,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by netsql <ne...@roomity.com>.
Don Brown wrote:
> * No servlet dependency in core framework, portlet and JSF support
> out of the box
>
1. + Ajax, Jax-WS, Axis/DocLit... JDNC, XUL, .... for us lunies doing
UI layer rendering on the client. There has to be a "process request"
signature that lets us do all.
Ex: List process(Context)
2. I would also say... a big benfit would be a DAO interface. The famous
populate().... or populate(Map) or my fave ArrayList populate(Map)
For the people that want to have a way to swap a Dao impl.
3. And to make it C# possible... all user exposed classes should be an
interface (so that same interface could be reimplemented).
Ex: BeanActionApi x = new BeanActionImpl()
and put all Api into one package
org.struts.api
So one could have
org.struts.csharpimpl
(an issue on ibatis is that 2 api are different).
4. JMX. To track requests, users, dao, etc.
I think it could help put all on same page.
How about this:
All "layers" should do
List execute(Context)
Ex:
Contex ctx= {populate, selectCient, client=GM}
List populate(ctx) to dao, to get rows
or
List process(ctx) for "RPC", to return to rendering layer all known /
needed info.
(Note how collections are a not too strongly typed)
that's all ;-)
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by Ted Husted <te...@gmail.com>.
On 8/3/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> With that thought in mind, I personally see the next evolution almost
> really being two frameworks that work in tandem... and maybe even it is
> *literally* that... one the usual server-side framework, but now with a
> client-side component that is a fair ways beyond anything we have today.
> They have to be intimately tied together to really make it worth it,
> but I see them both being fairly complex endeavors.
I would go so far as to suggest three layers, the client-side (Ajax),
the server-side (Struts), and the business-side (XWork or Nexus).
In practice, many web application frameworks end up doing double duty.
Since there are few business logic frameworks, developers tend to put
features into presentation frameworks that don't need to be there. We
just don't have another place to put them :)
I've been working on a view-agnostic business-logic framework in the
sandbox, based on Commons CoR, but, alas, all the code is still in C#.
* http://opensource.atlassian.com/confluence/oss/display/OVR/WhitePaper
> We're seeing a lot of experimentation in that direction... ASP.Net, JSF,
> all the various Java frameworks out there, more open-source projects
> than you can count... but I'm not sure any of them are quite "right"
> yet.
And, unlike ASP.NET and JSF, the open source frameworks represent the
technologies that front-line developers actually *want* to use.
Otherwise, we would not have built them :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I'm kind of surprised with all the replies indicating the willingness to
think much more revolutionary rather than evolutionary... I can't say I
expected that, but I'm really quite happy about being wrong :)
I really think web applications to this point, on the whole, have been
rather lousy. I'm not saying anything new when I say that web-based
applications set interface design back at least five years. We're only
now starting to recover from that bit.
With that thought in mind, I personally see the next evolution almost
really being two frameworks that work in tandem... and maybe even it is
*literally* that... one the usual server-side framework, but now with a
client-side component that is a fair ways beyond anything we have today.
They have to be intimately tied together to really make it worth it,
but I see them both being fairly complex endeavors.
We're seeing a lot of experimentation in that direction... ASP.Net, JSF,
all the various Java frameworks out there, more open-source projects
than you can count... but I'm not sure any of them are quite "right"
yet. So, when Martin says "We've learned a lot from Struts' evolution,
and we can and should learn from how other projects have tackled some of
the same problems", I couldn't agree more... I think the next evolution
of Struts will most definitely be a fusion of a lot of the ideas we're
playing with today, and more that we haven't yet thought of.
Exciting times for sure :)
Frank
Martin Cooper wrote:
> This looks really good, and fits well with my belief that the way to get
> to Struts 2.0 is to start by building a new core first, and then adding
> a compatibility layer on top of that to help people migrate.
>
>> From my own perspective, it shouldn't be a surprise to most on this list
>
> that I have a particular interest in facilitating the creation of rich
> web applications - applications which may be component based, but not
> server side components. This proposal sets out on the right path towards
> that goal, and I'm planning on furthering that.
>
> One other aspect that Don didn't mention explicitly (but which I know he
> had in mind) is designing for testability. Right from the get-go, we
> need to build in tests wherever we can.
>
> We've learned a lot from Struts' evolution, and we can and should learn
> from how other projects have tackled some of the same problems. Also, as
> Don said, it's time we started collaborating more closely with some of
> these other projects, so that we can pool our resources rather than
> duplicate effort.
>
> --
> Martin Cooper
>
>
> On Tue, 2 Aug 2005, Don Brown wrote:
>
>> I'd been waiting to announce/propose this until I could write up a
>> decent proposal and have the code in a better state, but with all the
>> talk about Struts 2.0, "good" now is better than "better" tomorrow I
>> suppose. The following is a proposal for Struts Ti, a possible
>> successor to Struts classic:
>>
>> Struts Ti is a simplified Model 2 framework for developing webapps
>> which allows the developer better access to the underlying
>> servlet/portlet environment. It serves a niche of web applications
>> that don?t want the additional complexity of server-side components
>> and verbose configuration, yet want the structure and controller
>> features of a modern web framework. Struts Ti builds on the directions
>> of Struts 1.x, yet re-implements the framework to provide a clean
>> slate for the next generation of Struts Ti. It aims to combine the
>> simplicity of Ruby on Rails and NanoWeb, the refinement of WebWork 2,
>> the tool-friendly authoring and Page Flow of Beehive, and the lessons
>> learned from Struts 1.x.
>>
>> The key word for Struts Ti is simplicity. Ideally, Struts Ti should
>> approach Ruby on Rails levels of easy of use, yet scale up to large
>> applications providing a smooth transition to JSF/Shale if desired.
>>
>> Key Features
>>
>> * POJO-based action that combines an Action and ActionForm in a
>> similar manner to JSF backing beans and WebWork 2 Commands
>> * Intelligent defaults utilizing naming and placement conventions
>> to require minimal, if any, configuration per page, however it will be
>> possible to override everything on a global and per-action basis
>> * Configuration can be ?assumed? or declared through annotations,
>> xml or properties files, or any other pluggable mechanism
>> * Pluggable EL for data binding defaulting to JSP 2.0 EL but
>> allowing OGNL or even BeanUtils
>> * Integration of a dialog or page flow capability drawing from
>> Beehive, Spring?s web flow, and Shale?s Dialogs.
>> * Per-Action optional interceptor chain ala WebWork 2
>> * Built-in dependency injection support
>>
>> Design Goals
>>
>> * No servlet dependency in core framework, portlet and JSF support
>> out of the box
>> * Spring-based dependency injection in core to allow for pluggability
>> * No bias to any view technology
>> * Ability to layer Struts 1.x compatibility on top
>> * Highly toolable
>> * Smooth integration into a portal/portlet environment
>> * AJAX-friendly
>>
>> Implementation
>>
>> * Built on the backbone of commons-chain
>> * No restriction on multiple Servlets and/or Servlet Filter
>> implementations
>> * Key decision points (action selection for example) use CoR chain
>> for maximum flexiblity
>> * Configuration specified using XDoclet (Java 1.4) or Annotations
>> (Java 5+), both supported out of the box
>>
>> Dependencies
>>
>> * Servlets 2.4
>> * Java 1.4 runtime, Java 1.5 to build
>> * JSP 2.0 if taglibs used
>>
>> Existing project collaboration
>>
>> * XWork/WebWork using their XWork and possibly parts/all of their
>> tag libraries
>> * Beehive using the Page Flow and annotations
>>
>> Status
>>
>> I've setup a project site for myself and have a working, if feature
>> sparce, framework in place. In feeling out the scope of the project,
>> I've been working with the two projects above as I want to avoid
>> reimplementing anything I don't have to, and think there is a lot of
>> synergy to be had.
>>
>> At this point, the project site, code, and more detailed design
>> discussions are on my personal server:
>>
>> https://www.twdata.org/projects/struts-ti
>>
>> However, I plan to move everything over to the sandbox to start the
>> incubation process and await acceptance by the Struts PMC and
>> developer community. I've stated before and I'm sure I'll be stating
>> again, and again, Struts Ti does NOT compete with Struts Shale, as I
>> see them, if accepted, as two sibiling projects serving different niches.
>>
>> I've been watching the Struts 2.0 threads with interest and hope this
>> proposal meets the needs of the Struts community for a successor to
>> Struts Classic.
>>
>> Don
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by netsql <ne...@roomity.com>.
Re: gut=Grand Unitfication theory of weak and strong forces
This proposal may lead to unifing client side rendering of UI and server
side rendering of UI, for re-use like so:
1st, lets assume that we know how to do request processing server side
w/ UI emited on server side, lets put that away for a minute, ignore it
and come back to it at end.
As a revolution, lets design it for a diferent use, for client side
rendering.
Like so:
RPC (all kinds of rpc) request comes in, mapped to a service or a
servlet or something that ends up calling or implementing:
ArrayList invoke(Map args) { } * // I assume stateless
and it calls a RequestProcessor
boolean process(Map ctx) { } // a chain based impl
( that likely calls a DAO
ArrayList execute(Map arg) { } // were execute="populate,
querry="findClients", id=101
but as a chain it could call anything... lucene for example )
* I know this can get invoked by JDNC. I think that other services can
call it as well. XML-RPC, Ajax, DHTML, HtmlServlet, Rest, Soap, Net
remoting, Spring remote services. In esence a servlet end up calling
invoke, and making most of the Request pats into a Map.
And it retures a list of results, for example into a JTableModel or a
single row into a "JFormModel".
This is how Flex UI rednering calls J2EE services!!!
I assume the primary use case is Ajax - fashion of the season.
Now that we have revoltion.... lets see if we can bring into it the
server side rendering folk (only after we get above working... it' a
revolution after all).
1. DisplayTag. Before calling it, we can write a taglib that invokes the
"remote" service and pust the arraylist in scope(and maintain user
session state if needed). DisplayTag renders the list. KISS. HTML tags
could use that same pre-tag.
2.Faclets. We can write a component that does same as 1.
3. A hack: We can have a traditional Shale action, that calls the invoke
directly.. and it does it's steps.
A centerpiece shold be JMX. (I am not sure how to do that w/ .NET
remoting, but at least we can open interfaces, and when somone gets an
itch to montior in C#.. done.). To monitor response times, loads, users.
Also, as we finaly define a DAO interface, JMX should montitor that.
So... it would redefine 3 tier as such (old school)
-Server side services
-UI rendering, client side enabled
-Mangamgnet/Monitoring layer.
Like?
Here is a proposed plan then:
1.Write API's / interfaces. (I think all methods have a single map
arrugment)
2. Write test casese. (socialize it that we have buy in w/ api and test
cases)
3. Refactor Shale to fit API, a Shale fork. (UI impls would be own jars)
My proposal is that Ajax be 1st use case(Frank), and Faclets be 2nd(for
server side ui emiting) use case. (Grovlet tag-libs a 3rd use case? ;-).
Portlets a 4th use case. I'll write the JDNC impl. and Grovlet tag impl
if I have to.
Also.. use a List as "FormBean". That whole indexed prorties is a
kludge. ( A list w/ one elmenet is for "Forms", muti row is for
tables/grids)
One would use this "Shale 2" by defining commands in xml. As soon as
command is declared, it could be "invoked" remotley. (it would have to
get auto-reloaded - hi JMX. ALso means Chain would have to be JMX
integrated)
A benfit is if the boss want's to make JSP into Ajax/DHTML or something
else, we have re-use.
A sample app could be mini CMS:
Get a list of articles. Click on one and display it for CRUD. JMX shows
DAO response time.
(so many apps are CMS)
Why do this?
A few of us wrote a request processor to fit our needs, inspiderd by
what we know about struts. We can keep writing our own. Or ... we can
re-write one together, it be more fun. There is a chance that all the
players could leverage this simple api and put us all back on one page.
No other framework has a UI layer so far removed.
I also think validation should be phase 2. We have to be clear on how
above works 1st. For example, I'd have to hack jGoodies validtaion
(basis for JDNC validator) to remotley read the "validator xml" so it
could do "Swing" ui hints and messages.
Vote:
+1
.V
Martin Cooper wrote:
> This looks really good, and fits well with my belief that the way to get
> to Struts 2.0 is to start by building a new core first, and then adding
> a compatibility layer on top of that to help people migrate.
>
> From my own perspective, it shouldn't be a surprise to most on this
> list that I have a particular interest in facilitating the creation of
> rich web applications - applications which may be component based, but
> not server side components. This proposal sets out on the right path
> towards that goal, and I'm planning on furthering that.
>
> One other aspect that Don didn't mention explicitly (but which I know he
> had in mind) is designing for testability. Right from the get-go, we
> need to build in tests wherever we can.
>
> We've learned a lot from Struts' evolution, and we can and should learn
> from how other projects have tackled some of the same problems. Also, as
> Don said, it's time we started collaborating more closely with some of
> these other projects, so that we can pool our resources rather than
> duplicate effort.
>
> --
> Martin Cooper
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Struts Ti
Posted by Martin Cooper <ma...@apache.org>.
This looks really good, and fits well with my belief that the way to get
to Struts 2.0 is to start by building a new core first, and then adding a
compatibility layer on top of that to help people migrate.
>From my own perspective, it shouldn't be a surprise to most on this list
that I have a particular interest in facilitating the creation of rich web
applications - applications which may be component based, but not server
side components. This proposal sets out on the right path towards that
goal, and I'm planning on furthering that.
One other aspect that Don didn't mention explicitly (but which I know he
had in mind) is designing for testability. Right from the get-go, we need
to build in tests wherever we can.
We've learned a lot from Struts' evolution, and we can and should learn
from how other projects have tackled some of the same problems. Also, as
Don said, it's time we started collaborating more closely with some of
these other projects, so that we can pool our resources rather than
duplicate effort.
--
Martin Cooper
On Tue, 2 Aug 2005, Don Brown wrote:
> I'd been waiting to announce/propose this until I could write up a decent
> proposal and have the code in a better state, but with all the talk about
> Struts 2.0, "good" now is better than "better" tomorrow I suppose. The
> following is a proposal for Struts Ti, a possible successor to Struts
> classic:
>
> Struts Ti is a simplified Model 2 framework for developing webapps which
> allows the developer better access to the underlying servlet/portlet
> environment. It serves a niche of web applications that don?t want the
> additional complexity of server-side components and verbose configuration,
> yet want the structure and controller features of a modern web framework.
> Struts Ti builds on the directions of Struts 1.x, yet re-implements the
> framework to provide a clean slate for the next generation of Struts Ti. It
> aims to combine the simplicity of Ruby on Rails and NanoWeb, the refinement
> of WebWork 2, the tool-friendly authoring and Page Flow of Beehive, and the
> lessons learned from Struts 1.x.
>
> The key word for Struts Ti is simplicity. Ideally, Struts Ti should approach
> Ruby on Rails levels of easy of use, yet scale up to large applications
> providing a smooth transition to JSF/Shale if desired.
>
> Key Features
>
> * POJO-based action that combines an Action and ActionForm in a similar
> manner to JSF backing beans and WebWork 2 Commands
> * Intelligent defaults utilizing naming and placement conventions to
> require minimal, if any, configuration per page, however it will be possible
> to override everything on a global and per-action basis
> * Configuration can be ?assumed? or declared through annotations, xml or
> properties files, or any other pluggable mechanism
> * Pluggable EL for data binding defaulting to JSP 2.0 EL but allowing
> OGNL or even BeanUtils
> * Integration of a dialog or page flow capability drawing from Beehive,
> Spring?s web flow, and Shale?s Dialogs.
> * Per-Action optional interceptor chain ala WebWork 2
> * Built-in dependency injection support
>
> Design Goals
>
> * No servlet dependency in core framework, portlet and JSF support out of
> the box
> * Spring-based dependency injection in core to allow for pluggability
> * No bias to any view technology
> * Ability to layer Struts 1.x compatibility on top
> * Highly toolable
> * Smooth integration into a portal/portlet environment
> * AJAX-friendly
>
> Implementation
>
> * Built on the backbone of commons-chain
> * No restriction on multiple Servlets and/or Servlet Filter
> implementations
> * Key decision points (action selection for example) use CoR chain for
> maximum flexiblity
> * Configuration specified using XDoclet (Java 1.4) or Annotations (Java
> 5+), both supported out of the box
>
> Dependencies
>
> * Servlets 2.4
> * Java 1.4 runtime, Java 1.5 to build
> * JSP 2.0 if taglibs used
>
> Existing project collaboration
>
> * XWork/WebWork using their XWork and possibly parts/all of their tag
> libraries
> * Beehive using the Page Flow and annotations
>
> Status
>
> I've setup a project site for myself and have a working, if feature sparce,
> framework in place. In feeling out the scope of the project, I've been
> working with the two projects above as I want to avoid reimplementing
> anything I don't have to, and think there is a lot of synergy to be had.
>
> At this point, the project site, code, and more detailed design discussions
> are on my personal server:
>
> https://www.twdata.org/projects/struts-ti
>
> However, I plan to move everything over to the sandbox to start the
> incubation process and await acceptance by the Struts PMC and developer
> community. I've stated before and I'm sure I'll be stating again, and again,
> Struts Ti does NOT compete with Struts Shale, as I see them, if accepted, as
> two sibiling projects serving different niches.
>
> I've been watching the Struts 2.0 threads with interest and hope this
> proposal meets the needs of the Struts community for a successor to Struts
> Classic.
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org