Back to the (rephrased) question - The Oracle ADF framework uses a twist
on the DynaForm idea. There is (generally) only one ActionForm in an
Application which is configured at runtime based on an XML bindings file
which describes exactly what data is required for this particular page.
The bin
Rick Reumann wrote the following on 7/12/2005 11:45 AM:
One thing I didn't bring up, though, because I'm not sure how 'best
practice' it is, is the concept of passing your ActionForm and sometimes
the HttpServletRequest off to another class for some processing.
Just realized, thanks to Dav
Rick Reumann wrote:
Dave Newton wrote the following on 7/12/2005 2:50 PM:
Of course not. But you just said that you're passing an ActionForm to
another layer--
Yea, I just realized that was a bad choice of words- "layer" --
totally bad. I didn't really mean another layer in the sense of "vi
Dave Newton wrote the following on 7/12/2005 2:50 PM:
Of course not. But you just said that you're passing an ActionForm to
another layer--
Yea, I just realized that was a bad choice of words- "layer" -- totally
bad. I didn't really mean another layer in the sense of "view" "model",
etc. I j
Rick Reumann wrote:
Dave Newton wrote the following on 7/12/2005 1:57 PM:
Rick Reumann wrote:
For what it's worth, I found a way I can get around passing my
ActionForm to another layer, but in theory, I'm not convinced that
doing so would really mean that I'd be breaking the seperation of
On 7/12/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> I was just replying to a post about keeping your Actions clean and doing
> the business logic in other classes.
>
> One thing I didn't bring up, though, because I'm not sure how 'best
> practice' it is, is the concept of passing your ActionForm
Dave Newton wrote the following on 7/12/2005 1:57 PM:
Rick Reumann wrote:
For what it's worth, I found a way I can get around passing my
ActionForm to another layer, but in theory, I'm not convinced that
doing so would really mean that I'd be breaking the seperation of
components.
How so?
Rick Reumann wrote:
For what it's worth, I found a way I can get around passing my
ActionForm to another layer, but in theory, I'm not convinced that
doing so would really mean that I'd be breaking the seperation of
components.
How so? If I have to include the Struts libraries to compile my
Durham David R Jr Ctr 805 CSPTS/SCE wrote the following on 7/12/2005
12:06 PM:
Rick, I don't like it. :) Seriously, you've created a dependency on
Struts in your business layer, and IMO, that's a big no-no.
Well remember what really makes a "helper" a business layer component? I
no longer
Durham David R Jr Ctr 805 CSPTS/SCE wrote:
So what happens is the Action looks like...
//EmployeeAction
execute(...) or dispatchmethod() {
EmployeForm empForm = (EmployeeForm)form;
//validate form, if success proceed..
boolean success = EmployeeActionHelper.updateEmployee(
empFo
On 7/12/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
> I was just replying to a post about keeping your Actions clean and doing
> the business logic in other classes.
>
> One thing I didn't bring up, though, because I'm not sure how 'best
> practice' it is, is the concept of passing your ActionForm
I would be okay with this if I considered EmployeeActionHelper as
presentation tier object. In fact, since this is getting an
EmployeeForm object, I'd package it with the rest of my Struts classes
(if that's how the package layout worked on the project). To me,
EmployeeActionHelper wouldn't be an
: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 12, 2005 9:45 AM
To: Struts Users Mailing List
Subject: anyone else pass their ActionForm off to another layer
I was just replying to a post about keeping your Actions clean and doing
the business logic in other classes.
One thing I didn&#
To me, the presentation tier's main responsibility is to mediate
between the user and business layer. Validation, forwarding, etc --
that's presentation tier logic that my business tier objects don't
care about (usually). From the business tier's perspective, the meat
is in the conversion between
Rick Reumann wrote:
I was just replying to a post about keeping your Actions clean and
doing the business logic in other classes.
One thing I didn't bring up, though, because I'm not sure how 'best
practice' it is, is the concept of passing your ActionForm and
sometimes the HttpServletReques
> So what happens is the Action looks like...
>
> //EmployeeAction
> execute(...) or dispatchmethod() {
> EmployeForm empForm = (EmployeeForm)form;
> //validate form, if success proceed..
> boolean success = EmployeeActionHelper.updateEmployee(
> empForm, request );
> //messages
I was just replying to a post about keeping your Actions clean and doing
the business logic in other classes.
One thing I didn't bring up, though, because I'm not sure how 'best
practice' it is, is the concept of passing your ActionForm and sometimes
the HttpServletRequest off to another class
17 matches
Mail list logo
