If someone have not noticed my another message, I have got the article
published. It discusses the idea of two-phase components, JSP controls
and Struts implementation:
http://today.java.net/pub/a/today/2005/08/04/jspcomponents.html
I hope that the article explains better what I has been
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
====
On 7/31/05, Nick Heudecker [EMAIL PROTECTED] wrote:
I think there are a lot of people out there who feel as
you do, but
backwards-compatibility has always been a major theme for those
While backwards
-Original Message-
From: Adam Hardy [mailto:[EMAIL PROTECTED]
====
Pilgrim, Peter on 01/08/05 09:30, wrote:
Struts 2 should force an Action or ActionForm to be interface or
subclass of an abstract type, hence dependency injection.
Oops! My wording was wrong.
Struts 2
On 8/1/05, Ted Husted [EMAIL PROTECTED] wrote:
On 7/31/05, Nick Heudecker [EMAIL PROTECTED] wrote:
I think there are a lot of people out there who feel as you do, but
backwards-compatibility has always been a major theme for those
While backwards compatibility is nice, I would rather
On 8/2/05, Dakota Jack [EMAIL PROTECTED] wrote:
I agree for a third time, and in fact I think that something that is
built for Struts rather than on its own merits and is dependent on the
present community for support is not worth working on at all. I am
personally not willing to associate
I'm definitely interested that so don't forget to
post about it. :)
Regards,
David,
Craig
PS: For a slightly more in depth comparison between
the frameworks mentioned above, watch for me to post
the slides for my O'Reilly Open Source Conference
session tomorrow that compares them. You
Interesting, how different Struts crowd is ;) Some want to keep what
they have, but make it cleaner. Other want the revolution. What about
gradual improvement with compatibility with current code base?
I will try to explain again my ideas. As we all know, there are two
approaches for webapps:
Likewise; I haven't made a detailed comparison of the different frameworks
out there since around the time Tapestry was migrating to Apache! Should be
interesting reading.
L.
David G. Friedman wrote:
I'm definitely interested that so don't forget to
post about it. :)
Regards,
David,
-Original Message-
From: Paul Benedict [mailto:[EMAIL PROTECTED]
====
Frank,
I am fond of these two ideas (see following). Heck, I
would be willing to even write them if I think there
would be a chance of someone actually commiting them
into the Trunk!!
There are four
Peter writes:
(2) Stubbing of abstract attributes for framework
implementation like Tapestry.
Are you talking abouting the ``jwcid'' attribute?
No.
When you create a Tapestry page, you don't have to
implement the getters - or even write the setter
methods for attributes (unless you want to
On 7/31/05, Nick Heudecker [EMAIL PROTECTED] wrote:
I think there are a lot of people out there who feel as you do, but
backwards-compatibility has always been a major theme for those
While backwards compatibility is nice, I would rather see a better
framework for the 2.x release. My
Paul Benedict on 01/08/05 12:54, wrote:
Peter writes:
(2) Stubbing of abstract attributes for framework
implementation like Tapestry.
Are you talking abouting the ``jwcid'' attribute?
No.
When you create a Tapestry page, you don't have to
implement the getters - or even write the setter
Pilgrim, Peter on 01/08/05 09:30, wrote:
Struts 2 should force an Action or ActionForm to be interface or
subclass of an abstract type, hence dependency injection.
If the former is the case, then it follows that calling the action
method should be flexible
public void bluegrass(ActionContext
Paul,
Do you have any specific ideas?
I think there are a lot of people out there who feel as you do, but
backwards-compatibility has always been a major theme for those
stewarding Struts, and rightly so I think, and many of the
revolutionary ideas that have been discussed or could be
I think there are a lot of people out there who feel as you do, but
backwards-compatibility has always been a major theme for those
While backwards compatibility is nice, I would rather see a better
framework for the 2.x release. My personal opinion is that version
compatibility should be
Frank,
I am fond of these two ideas (see following). Heck, I
would be willing to even write them if I think there
would be a chance of someone actually commiting them
into the Trunk!!
There are four things that I am very fond of and they
are all tightly integrated:
(1) POJO for forms
(2)
See, now it gets interesting because debate starts :)
(I'm already thinking this should probably be moved to the dev list by
the way)...
Paul Benedict wrote:
(1) POJO for forms
Agreed, this would be very nice, and I know it has been discussed before.
(2) Stubbing of abstract attributes
Frank W. Zammetti wrote:
See, now it gets interesting because debate starts :)
I would say that key for any new framework is that it has to default
to client side rendering of ui. DHTML/Ajax ... or others ;-)
And then as option be able to do server side generated UI.
.V
roomity.com
netsql wrote:
I would say that key for any new framework is that it has to default
to client side rendering of ui. DHTML/Ajax ... or others ;-)
And then as option be able to do server side generated UI.
What does that really MEAN though? For instance, take the common form
controls we all
Frank W. Zammetti wrote:
what does it really mean for them to be
rendered client-side and where does DHTML/Ajax fit in?
DHTML renders client side(w Ajax RCP). Flex/Lazlo. Swing. XUL. X-Forms?
.V
-
To unsubscribe, e-mail:
20 matches
Mail list logo
