On 7/15/05, Schaub, Stephen <[EMAIL PROTECTED]> wrote:
>
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 13, 2005 3:22 PM
> > To: Struts Users Mailing List
> > Subject: Re: Putting execute() in ActionF
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 13, 2005 3:22 PM
> To: Struts Users Mailing List
> Subject: Re: Putting execute() in ActionForm
>
> [snip]
>
> If I were to use this strategy, I'd select the param
On 7/11/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> Just remember ... the lifetime of Struts 1.x (five years since initial
> conception, four years since 1.0) is basically a geologic era in terms
> of Internet time :-).
Ahh, but time is an illusion, and Internet time doubly so :)
It seems
On 7/13/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> Most importantly, I'd make very sure that all my "code-behind
> ActionForms" were request scope, probably by changing the factory
> default.
In this case this form would not be stateful. At least for me, it is
the whole point of sticking data and
In 7/11/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> I wanted to post something like "Rick, Ted and other orthodox guys,
> check out this guy's suggestion", but then I decided not to ;-)
Wow! That may have been the first time anyone has ever accused me of
being "orthodox" :)
I've never used
On 7/13/05, Yaroslav Novytskyy <[EMAIL PROTECTED]> wrote:
> Hello!
>
> Craig McClanahan wrote:
> > On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> >
> >>Craig McClanahan wrote:
> >>
> >>>I think of the state information represented by an ActionForm (in
> >>>Struts 1.x) or potentially as
Hello!
Craig McClanahan wrote:
On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Craig McClanahan wrote:
I think of the state information represented by an ActionForm (in
Struts 1.x) or potentially as properties of an "action" class (per the
current discussion) to be part of the *view
Michael Jouravlev wrote:
> Also, Struts
> is based on idea of subclassing, thus if you already subclassing
> something like ValidateForm, you cannot subclass another form, which
> you would want to because it has needed event handlers.
Good point.
>
> What if it were a solid dispatching Actio
On 7/11/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
>
> Very few had the idea of passing ActionForm as VO to persistence
> layer. This is some kind of backwards MVC. Contrary, the idea was to
> use BOs in ActionForm with session scope, thus making it a stateful
> interactive business object.
On 7/11/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> I think of the state information represented by an ActionForm (in
> Struts 1.x) or potentially as properties of an "action" class (per the
> current discussion) to be part of the *view* tier. Further, I see the
> role of the execute method
On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> Craig McClanahan wrote:
> > There are reasons to have an "application scoped" front controller.
> > There are reasons to have a "view-scoped" front controller. There is
> > *no* reason I am aware of that requires these controllers to be th
Craig McClanahan wrote:
There are reasons to have an "application scoped" front controller.
There are reasons to have a "view-scoped" front controller. There is
*no* reason I am aware of that requires these controllers to be the
same :-).
Good point. In fact, I don't think it would take much
On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> Craig McClanahan wrote:
> > I think of the state information represented by an ActionForm (in
> > Struts 1.x) or potentially as properties of an "action" class (per the
> > current discussion) to be part of the *view* tier. Further, I see
Craig McClanahan wrote:
I think of the state information represented by an ActionForm (in
Struts 1.x) or potentially as properties of an "action" class (per the
current discussion) to be part of the *view* tier. Further, I see the
role of the execute method on an action as being an Adapter Patte
On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
[snip]
> By combining Actions and ActionForms, you are breaking the separation.
> There *IS* clearly benefit to doing so... cutting down class count is
> something I'm always in favor of, so long as line count doesn't increase
> as a resul
Schaub, Stephen wrote:
What I'm wanting is an explanation of why I should keep the ActionForm class
_separate_ from the Action class. It seems to me that this unnecessarily
complicates the application design.
When a Struts-based app is "properly" architected, the Actions are
nothing more tha
On 7/11/05, Schaub, Stephen <[EMAIL PROTECTED]> wrote:
> Michael Jouravlev wrote:
> > On the other hand, Stephen, why do you want to have one class per
> > page?
>
> Because I don't want to have to have two classes per page. :)
you got me :) I wanted to ask, why would you want to have one *set of
Michael Jouravlev wrote:
>
> First of all, to get it over with, Struts Dialogs has plans to combine
> Action and ActionForm but it is not there yet :)
>
> Second, the concept of Struts Dialogs is different. Stephen wants to
> have one class -> one page relation. JSF or ASP.NET is the way to go
>
On 7/11/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> Ok, yes they'd have to extend that in order to utilize your processing
> in the ActionForm functionality. Bottom line is I think all you've done
> is move where you do the processing... you moved it from the Actions to
> the ActionForms. If you
Schaub, Stephen wrote the following on 7/11/2005 3:56 PM:
Yes -- it is supposed to be abstract -- each ActionForm subclass must
define an execute() method to perform the processing for that form.
(Right but in your example you were showing LoginAction as the
implementing class and you still k
On 7/11/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> Schaub, Stephen wrote the following on 7/11/2005 2:07 PM:
>
> > With this approach, most JSP pages could have a single Java class --
> > a SimpleActionForm subclass that handles both validation and
> > processing for the page:
>
> Michael, is
Zarar Siddiqi wrote:
> I think the ideal that you're searching for is "one class per
> view". Take a look at JSF.
That's correct. And I'm familiar with JSF -- but it's way too complicated for
my needs. Plus Struts is dictated for this project...
Stephen
--
I think the ideal that you're searching for is "one class per view". Take a
look at JSF.
- Original Message -
From: "Schaub, Stephen" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List"
Sent: Monday, July 11, 2005 3:56 PM
Subject: RE: Puttin
Rick Reumann wrote:
> > With this approach, most JSP pages could have a single Java class --
> > a SimpleActionForm subclass that handles both validation and
> > processing for the page:
>
> Well they certainly wouldn't have a 'single' java class, you
> would have
> a LOT of them.
Sorry -- I m
Schaub, Stephen wrote the following on 7/11/2005 2:07 PM:
public class SimpleAction extends Action { public ActionForward
execute( ActionMapping mapping, ActionForm form, HttpServletRequest
request, HttpServletResponse response) throws Exception {
SimpleActionForm bean = (SimpleActionForm)form
Schaub, Stephen wrote the following on 7/11/2005 2:07 PM:
With this approach, most JSP pages could have a single Java class --
a SimpleActionForm subclass that handles both validation and
processing for the page:
Michael, is this guy a plant from your StrutsDialog camp?:)
--
Rick
---
I'm interested in some feedback on the following:
I prefer to develop web applications using a page-centric model. I like the
simplicity of one JSP <-> one Java class for the view layer (not the model).
Struts, with its separate Action and ActionForm classes, tends toward at least
two Java clas
27 matches
Mail list logo
