struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <>
Subject Re: Spring and XWork in Ti
Date Thu, 01 Sep 2005 21:54:37 GMT
At this stage in the project, we are exploring problems and solutions.  It can 
be misleading to follow the dev discussion thinking this is what the user will 
need to know and understand in order to use the project.  Each of the components 
discussed here are solutions to problems.  What Ti is trying to determine is 
what problems it will tackle and what components already provide solutions.

In the end, I envision the average Struts developer not knowing or caring about 
90% of this stuff.  They will write Controller classes, annotated with tags that 
request validation, views, etc., then Ti will take care of it from there.  My 
goal is for the user to not even know they are using XWork, just that when they 
add the @ti.action annotation, they can call that action from a URL.  If they 
want validation, they add a @ti.validationRequired tag.  They shouldn't know or 
care if it is commons-validator under the covers that does the work or XWork 

This level of user abstraction, I feel, hasn't been a priority for many projects 
and causes confusion.  I'm tired of the confusion caused by Struts apps being a 
mix of Tiles, commons-validator, Struts, Beanutils, etc., and those are just the 
out-of-the-box components Struts ships with.  Some projects like Tapestry solve 
this by rolling their own IoC, HTML template language, component model, etc., to 
present a unified face to the developer.  I'm hoping to also provide a simple, 
unified framework to the developer, but take advantage of all the hard work 
folks have put into projects like Spring, WebWork, Beehive, etc. under the covers.

This may not be a reachable goal, but I'm hoping we can give it a shot.


netsql wrote:
> As MF says: "Comprehensiveness is the enemy of comprehensibility".
> To that end, if there is a way to have one, but not both, it's a plus.
> Spring + CoR + WebWork + XYZ... that looks scary (and still not 
> defulting to "Ajax").
> Don, If you like IoC, lets start w/ HiveMind (or whatever IoC + iBatis 
> DAO) and ignore CoR, and build clean and build for Ajax example of the 
> bat (the 2 Ajax libs that MC talks about, and then rig Faclets or 
> whatever else later, that would give us a sweet spot).
> It has to be teachable at the end.
> .V
> Ted Husted wrote:
>> My only point would be that these tools seem close enough that we
>> should be able to extend one to fill the role of the other.
>> -- 
> Broadband interface (RIA) + mail box safety =
> <>
> *Your* clubs, no sign up to read, ad supported; try broadband internet.
> cell: 917 825 3035 in DFW
> email: netsql at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message