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
validations.
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.
Don
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 = Roomity.com
<http://roomity.com/demo.jsp>
*Your* clubs, no sign up to read, ad supported; try broadband internet.
cell: 917 825 3035 in DFW
email: netsql at roomity.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
