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