At risk of sounding like I'm brown-nosing, I think it is not just
dedication - it is 50% elegant ideas and quality code.
On 11/12/2004 08:38 AM Erik Weber wrote:
I would like to offer one more opinion on the paradigm discussion, and
then I'll shut up. I think it's important for younger developer
Craig,
Why is this considered to be Struts? I have nothing against the
proposal, but it seems like it is not Struts and, if this becomes
Struts, this essentially destroys Struts as we know it, doesn't it?
If so, why do that? Why not have Shale and Struts?
Jack
On Mon, 8 Nov 2004 09:33:15 -08
I would like to offer one more opinion on the paradigm discussion, and
then I'll shut up. I think it's important for younger developers to
realize this.
Every paradigm will have its strengths and weaknesses, and some can even
be judged to be "better overall" than competing paradigms by a majori
Craig McClanahan wrote in <[EMAIL PROTECTED]>
>> I think page-driven development frameworks would exacerbate this problem
>> unless they clarify with eloquence up-front how to make a clear
>> seperation of the POST processing from the page preparation required for
>> the next page.
>>
>
>Yep, that
Craig McClanahan wrote:
Struts needs to do something useful in the *application controller*
tier ... the view has been done.
Struts is already proved most useful for coming on 5 years and will
continue to have
https://equinox.dev.java.net/framework-comparison/WebFrameworks.pdf
pg 21. )
It als
uses a
standard bit of software to access the app.
Daniel.
-Original Message-
From: Erik Weber [mailto:[EMAIL PROTECTED]
Sent: 11 November 2004 15:20
To: Struts Users Mailing List
Subject: [OT] Re: A new paradigm of Struts development
Vic, why we would want to continue to write apps for I
Erik Weber wrote:
I have invested a lot in writing custom UI classes, custom paint
methods, custom UI defaults properties, etc., to get my Swing components
looking the way I want (I'm sorry but, changing the background colors,
and other easily-scriptable stuff, doesn't cure Swing's out-of-the-bo
t
> Subject: [OT] Re: A new paradigm of Struts development
>
>
> Vic, why we would want to continue to write apps for Internet Explorer
> and Netscape after discovering a technology like this is beyond me. My
> chips are in with you. I have been pushing my web-app minded
Craig McClanahan wrote:
On Thu, 11 Nov 2004 11:13:57 +, Adam Hardy
<[EMAIL PROTECTED]> wrote:
A lightweight framework must be simple to implement, for RAD or for
prototyping or for web newbies. Given a large complicated application,
should an architect choose a lightweight framework? No. She
Vic, why we would want to continue to write apps for Internet Explorer
and Netscape after discovering a technology like this is beyond me. My
chips are in with you. I have been pushing my web-app minded clients
toward Swing all along, but technologies like Java Web Start and now
JDNC are really
Craig McClanahan wrote:
Intermixed.
On Tue, 9 Nov 2004 10:47:34 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
Thanks, Joe,
Some thoughts below:
On Tue, 9 Nov 2004 12:26:22 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
Aren't Struts and JSF in the end really competitors? Seems so to me.
I
On Thu, 11 Nov 2004 11:13:57 +, Adam Hardy
<[EMAIL PROTECTED]> wrote:
> A lightweight framework must be simple to implement, for RAD or for
> prototyping or for web newbies. Given a large complicated application,
> should an architect choose a lightweight framework? No. She / he must
> recognis
Adam Hardy wrote:
What I want to see in the future for big apps is a DTD or xml schema
that brings JSP code and XHTML mark-up under control. Something that is
easily editable by my editor of choice, using syntax-highlighting to
show me where my XHTML is up the swanny.
Just in case you missed m
A lightweight framework must be simple to implement, for RAD or for
prototyping or for web newbies. Given a large complicated application,
should an architect choose a lightweight framework? No. She / he must
recognise the limitations of the framework.
JSF seems to be lightweight. It simplifies
Craig McClanahan wrote:
The point that Vic is making is that there are people who don't
consider the fact that EJB is part of J2EE is sufficient reason to
justify its use. That's fair -- and I don't justify it that way; it's
only a reassurance that it's not just a shot in the dark technology,
an
On Wed, 10 Nov 2004 10:25:07 +, Adam Hardy
<[EMAIL PROTECTED]> wrote:
> On 11/10/2004 01:01 AM Zoran Avtarovski wrote:
> > Am I missing something or is everybody saying the same thing. What struts
> > needs is a view controller mechanism. The only difference is the specifics
> > of the mechanis
On Wed, 10 Nov 2004 00:46:26 +, Adam Hardy
<[EMAIL PROTECTED]> wrote:
> On 11/09/2004 11:30 PM Joe Germuska wrote:
>
>
> > I obviously have an affinity for the way we do it here (something I
> > elaborated about in more detail in this list post:
> > http://article.gmane.org/gmane.comp.jakarta
Intermixed.
On Tue, 9 Nov 2004 10:47:34 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> Thanks, Joe,
>
> Some thoughts below:
>
>
>
>
> On Tue, 9 Nov 2004 12:26:22 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
>
> >
> > >Aren't Struts and JSF in the end really competitors? Seems so to me.
Intermixed as well.
On Tue, 9 Nov 2004 12:26:22 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> Various people's comments are interspersed with my own below...
>
>
>
> >What intrigues me about JSF which I haven't been able to find out
> >yet, is whether JSF is also only meant for light-weight
I'm going to start responding here to a few interesting points in this
thread ... some will probably be repeated later, either by me or
others (I haven't studied it all yet), but
On Tue, 09 Nov 2004 16:47:23 +, Adam Hardy
<[EMAIL PROTECTED]> wrote:
> In my experience on big projects, develope
Rick,
Thanks for the feedback.
Your point is pre-population, right?
Rick Reumann wrote in <[EMAIL PROTECTED]>
>1) I have a DispatchAction that handles related functionality to a
>particular task at hand... related CRUD stuff... ie. getEmployees,
>updateEmployee, getEmployee etc. There is also a
Tak Yoshida wrote the following on 11/7/2004 7:05 PM:
I would like to introduce Page Driven development, OzStruts, to all Struts
developers,
which makes Struts application more clean and maintainable.
Ok, dang, I must be missing something. I've been using Struts now for
over four years developing
On 2004-11-10 at 00:46:26 +, Adam Hardy wrote:
> On 11/09/2004 11:30 PM Joe Germuska wrote:
>...
> I think the learning curve for struts is already humungous! Wouldn't the
> addition of a command-chain or a renderer steepen it further?
Hmm, I don't think you would have to use it, if you don't
> Yes you are missing something ;)
>
> I am saying struts doesn't need a "view controller" because you can
> implement the post-redirect-get pattern and struts is complicated enough
> already. Although no-one is arguing for or against me :)
>
> I think it is more a case of JSF needing a better con
On 11/10/2004 01:01 AM Zoran Avtarovski wrote:
Am I missing something or is everybody saying the same thing. What struts
needs is a view controller mechanism. The only difference is the specifics
of the mechanism. JSF v. a struts specific mechanism (OzStruts) or the
adaptation of something else.
Wh
You shouldn't use
ActionForms to pass arbitrary data from java code to JSP code, except
for pre-populating form fields.)
Could you please explain with example for this?
I'm not sure what "pass arbitrary data from java code to JSP code" means?
For example, suppose that there's a page to edi
Bill,
>pass information from the browser to the Action. You shouldn't use
>ActionForms to pass arbitrary data from java code to JSP code, except
>for pre-populating form fields.)
Could you please explain with example for this?
I'm not sure what "pass arbitrary data from java code to JSP code" m
OK, that makes sense. I'm not sure what the normal struts usage pattern
is. I think that it makes sense to have one ActionForm for each logical
request, but maybe other people don't do that. So, I agree with your
idea of OzPage. (Also, I think that ActionForms should only be used to
pass in
Hi Bill,
>Then AddVendorAction takes AddVendorForm as input, and then creates a
>DisplayVendorDetailForm in the request context before forwarding to
>displayVendor.jsp.
Thanks for your feedback.
You're right, but you're doing it by yourself in application code.
This is one of the main idea of OzS
Am I missing something or is everybody saying the same thing. What struts
needs is a view controller mechanism. The only difference is the specifics
of the mechanism. JSF v. a struts specific mechanism (OzStruts) or the
adaptation of something else.
What I don't understand is what people have agai
On 11/09/2004 11:30 PM Joe Germuska wrote:
I obviously have an affinity for the way we do it here (something I
elaborated about in more detail in this list post:
http://article.gmane.org/gmane.comp.jakarta.struts.devel/22034) but I
would be happy to adjust my ideas if we got anything approaching
Hi Tak.
(B
(B>addVendor.jsp has a "submit" button to send with parameters to
(B>create a Vendor,
(B>and application routes to vendorDetail.jsp when it's sucsessfuly done. It also
(B>routes to
(B>addVendor.jsp when it's failed to add or validation errors.
(B>In this multiple destination
Ooohhh,
Let's start a rumor. Craig is going over to Microsoft... It must be true
'cause I heard it on the list.
-Original Message-
From: Joe Germuska [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 09, 2004 3:41 PM
To: Struts Users Mailing List
Subject: Re: A new paradigm
At 11:00 PM + 11/9/04, Adam Hardy wrote:
On 11/09/2004 06:26 PM Joe Germuska wrote:
I think this is exactly the point. JSF's controller model may not
scale to a large application. However, in the Shale proposal,
JSF's controller model is only being asked to control the view.
Right now, Str
Sorry for going on so long.
Nonsense. That's why we have *discussion* lists.
I may have misunderstood, and I am at a disadvantage because I am
still trying to get a good idea of what JSF is all about, but I
thought that Craig saw any merger between Struts and JSF as a
temporary thing which was fun
On 11/09/2004 06:26 PM Joe Germuska wrote:
I think this is exactly the point. JSF's controller model may not scale
to a large application. However, in the Shale proposal, JSF's
controller model is only being asked to control the view. Right now,
Struts doesn't have a separate concept of a "vi
Joe Germuska wrote in <[EMAIL PROTECTED]>
>am finding that a limitation. I would like a clean facility for
>prepopulating forms from system data which interoperates with the
>existing mechanism for prepopulating forms when validation fails and
>the user must try again. I would also like a clea
Thanks, Joe,
Some thoughts below:
On Tue, 9 Nov 2004 12:26:22 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
>
> >Aren't Struts and JSF in the end really competitors? Seems so to me.
> >I cannot see them merging in any sensible solution.
>
> No, I don't think so. JSF is primarily focused on
Various people's comments are interspersed with my own below...
What intrigues me about JSF which I haven't been able to find out
yet, is whether JSF is also only meant for light-weight apps. Does
JSF's tendency towards page-driven Commands Pattern implementation
as Craig mentioned put it in dan
I don't think that this note by "Vinny" is unimportant. I like the
idea of something like JSF for the view. I am not sure I like the
controller architecture which it uses and which, i think, ultimately
is a choice inconsistent with Struts, which I like.
Jack
On Tue, 09 Nov 2004 06:18:47 -0600,
Aren't Struts and JSF in the end really competitors? Seems so to me.
I cannot see them merging in any sensible solution.
Jack
On Tue, 9 Nov 2004 10:16:07 +0100, Jesse Alexander (KBSA 21)
<[EMAIL PROTECTED]> wrote:
> -Original Message-
>
> (of course I am unhappy about JSF part )
>
>
In my experience on big projects, developers must understand the
intricacies of HTTP request and response, GETs, POSTs etc to allow them
to implement their Command Pattern effectively. Otherwise it leads to
Bitter Java-type anti-patterns and spaghetti code and unmaintainable apps.
I think Tak's
and (unfortunately) it's often him who "Ack"'s oder "Nak"'s our projects
and tools...
-Original Message-
From: Andrew Hill [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 09, 2004 2:34 PM
To: Struts Users Mailing List
Subject: Re: A new paradigm of
The average PHB thinks EJB *is* J2EE...
:-(
Vic (Vinny) Cekvenich wrote:
Jesse Alexander (KBSA 21) wrote:
JSF will be part of J2EE (as of version 1.5). That will make it hard
to explain to "pointy hairy boss" type managers why one wants to use
another
framework.
So is EJB a part of J2EE for a l
Bill,
(B
(BThanks for the feedback. I should re-write this, it's not clear.
(B
(B>> Here is an example from OzStruts sample application. VendorDetail.jsp
(B>> has two
(B>> source pages, one is vendorSearch.jsp, and another is addVendor.jsp. In
(B>> addVendor.jsp to vendorDeatil.jsp transiti
Jesse Alexander (KBSA 21) wrote:
JSF will be part of J2EE (as of version 1.5). That will make it hard to
explain to "pointy hairy boss" type managers why one wants to use another
framework.
So is EJB a part of J2EE for a lot longer, and people avoid it.
.V
>From what I've seen of JSF, I don't think it's that bad. I agree with Craig
in that struts strength is as a controller framework and that technology
like JSF, or velocity or whatever should be used at the display end.
If it's a matter of discussion I'm one for JSF, those who I know don't like
it
-Original Message-
(of course I am unhappy about JSF part )
-/Original Message-
Well. I am HAPPY that Craig's proposal adjusts Struts in that direction.
JSF will be part of J2EE (as of version 1.5). That will make it hard to
explain to "pointy hairy boss" type managers why one w
Hi Tak. I read your OzStruts documentation. It was interesting, but it
was a little hard for me to understand too. Basically, your description
of "normal struts" sounds strange to me:
Here is an example from OzStruts sample application. VendorDetail.jsp
has two
source pages, one is vendorSearch
At 4:46 PM -0600 11/8/04, Vic (Vinny) Cekvenich wrote:
Tak, just so you know, source is here:
http://svn.apache.org/repos/asf/struts/trunk
(of course I am unhappy about JSF part )
Why? It's not like Shale is carved in stone yet. (er... no pun
intended). Now is the time for people who are intere
Tak, just so you know, source is here:
http://svn.apache.org/repos/asf/struts/trunk
(of course I am unhappy about JSF part )
.V
Tak Yoshida wrote:
Craig,
Thank you so much for useful information about Struts in the future.
I didn't know that Struts 2.0 will support Page oriented programming,
and am
Craig,
Thank you so much for useful information about Struts in the future.
I didn't know that Struts 2.0 will support Page oriented programming,
and am also surprised that Shale View Controller has simillar features that
OzStruts does.
What I want to have on OzStruts are
1:Page oriented program
Hi Adam,
Thanks for your interest on OzStruts.
Adam Hardy wrote in <[EMAIL PROTECTED]>
>tak,
>read the pdf intro and i'm still in the dark about what ozstruts
>actually does. I appreciate all of the problem spots you highlight in
>struts, but it's really not clear how your page-driven classes o
Is there any estimated date for when Shale might appear as a production
release?
Wiebe
-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
Sent: Monday, November 08, 2004 9:33 AM
To: Struts Users Mailing List
Subject: Re: A new paradigm of Struts development
Tak,
You
Tak,
You and others who like the page oriented development environment will
enjoy reading about "Shale" -- it's my proposed architecture for
Struts 2.0 (basically providing application controller features on top
of JavaServer Faces), and the ViewHandler API has many of the same
characteristics you
tak,
read the pdf intro and i'm still in the dark about what ozstruts
actually does. I appreciate all of the problem spots you highlight in
struts, but it's really not clear how your page-driven classes overcome
them all.
For instance, you want to look up the action class. You have to go
throu
56 matches
Mail list logo
