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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
