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 fo
Dakota Jack wrote:
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
b
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 <[EMAIL PROTECTED]> wrote:
> I'd been waiting to announce/propose this until I could write up a
> decent proposal
On 8/3/05, Frank W. Zammetti <[EMAIL PROTECTED]> 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
On 8/2/05, netsql <[EMAIL PROTECTED]> 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 t
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.
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 p
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 lik
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, b
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
On 8/2/05, Don Brown <[EMAIL PROTECTED]> 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 coupl
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 hav
Michael Jouravlev wrote:
* 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
On 8/2/05, Don Brown <[EMAIL PROTECTED]> 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
> addi
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.
E
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 call
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 proce
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 class
18 matches
Mail list logo
