DO NOT REPLY [Bug 32947] - FormFile.getFileSize() returns 0 when size of uploaded file is big

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32947





--- Additional Comments From [EMAIL PROTECTED]  2005-01-05 12:18 ---
The maximum Java integer value (2147483647) works up to 2 *gigabytes*. 
Furthermore, if an integer value overflows, it appears as a negative number, not
zero.

Perhaps your problem is instead that you need to increase the "maxFileSize"
value in the controller, although the default is 250 MB.  I seem to remember
some case where files too large were being discarded without any error, although
that may have been a bug in an early version of the chained request processor.

Perhaps there are people who actually need to upload files > 2 GB, but 
I'm afraid you've mis-diagnosed your problem.  

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32954] New: - Wildcard support in exception handlers

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32954

   Summary: Wildcard support in exception handlers
   Product: Struts
   Version: 1.2.6 Beta
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Standard Actions
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


It seems to me that  elements nested inside  element 
would benefit of wildcard action mapping as much as nested  already do.

In particular I would suggest to modify the 
ActionConfigMatcher.convertActionConfig method in order to treat 
ExceptionConfigs in much the same way as ForwardConfigs (code not compiled):

ExceptionConfig[] exConfigs = orig.findExceptionConfigs();
ExceptionConfig exCfg = null;
for (int x = 0; x < exConfigs.length; x++) {
exCfg = new ExceptionConfig();
exCfg.setPath(convertParam(exConfigs[x].getPath(), vars));
// copy other meaningful properties here
config.removeExceptionConfig(exConfigs[x]);
// note that the previous line is missing in the current code,
// but asimilar one is used to handle ForwardConfigs
config.addExceptionConfig(exCfg);
}

Regards, Fabio.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32947] - FormFile.getFileSize() returns 0 when size of uploaded file is big

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32947


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|enhancement |minor
 Status|NEW |RESOLVED
 Resolution||INVALID




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Coupling, Struts and JSF

[Dakota Jack]

I realize it was an answer, Jan.  My question, however, is whether
there is a problem when someone does not chain actions and whether
there is not a way to avoid doubling actions or whether there is a
real problem.  Is that unreasonable?  Or, are we just supposed to
assume there is some imagined problem at the root of needing to change
an entire archetecture?

Jack


On Wed, 5 Jan 2005 07:32:56 -, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Dakota,
> 
> > -Original Message-
> > From: Dakota Jack [mailto:[EMAIL PROTECTED]
> > Sent: dinsdag 4 januari 2005 18:29
> > To: Struts Developers List
> > Subject: Re: Coupling, Struts and JSF
> 
> > Hi, Jan,
> 
> > I am less interested in how people make mistakes but rather in what
> > the problem is for people that don't chain actions.
> 
> It was an answer to your question:
> 
> 
> 
> > In the wiki, you say "[y]et in Struts 1.x, for example, the setup
> logic
> > and processing logic end up in two different Actions, requiring
> > multiple action mappings".  Could you expand on this a bit
> 
> 
> 
> But I did expect this kind of reply.
> 
> > Jack
> 
> Regards, Jan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
--

"You can lead a horse to water but you cannot make it float on its back."

~Dakota Jack~

"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

---

"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Coupling, Struts and JSF

[Ted Husted]

In practice, a rich page will require a lot of setup. For example, it's not 
uncommon for page to have several select boxes that need to be populated. When 
you prepare to setup the page, you might also need to look up a domain record, 
as well as a user profile, and so forth.

After it's displayed, and the form is submitted, and found to be valid, the 
rest of the logic is very different. We don't have to populate the form any 
more, we just have to process the result. The result may mean updating a 
database or doing something else entirely.

There are workarounds and kludges, but in classic Struts 1.x, validation is a 
yes/no setting for each mapping and there is also one validation method per 
mapping. When you are setting up the page, you don't want to validate the input 
(or want to validate it differently). When you are processing the page, you do 
want to validate the input. Hence, a cannonical need for multiple mappings.  
(Again, there are tricks you can plan, but this is not where we discuss tricks, 
it's where we discuss changes that obviate tricks.)

In JSF and ASPX, this problem is addressed with a "postback" state. The 
framework determines whether the page is being displayed or redisplayed, and 
the backing bean (or code-behind) can act differently for each state.

Meanwhile, no one is proposing any revolutionary changes to the Struts 1.x 
architecture. We are discussing a number of evolutionary changes, most of which 
have been reduced to the roadmap, and all of which will be backwardly 
compatible with the prior 1.x release. No matter what happens with Struts 2.x, 
work will continue on Struts 1.x. At least, so long as there are volunteers 
ready, willing, and able to do the work.

In a volunteer environment, Darwin always decides. The better technology 
attracts the best volunteers. Better volunteers do better work, and the spiral 
continues upward.

Which is better? I don't know. Neither do you, or Joe, or Craig. It's not up to 
any one person. It's up to the community of volunteers who do the work, both 
here and on the user list.

-Ted.

On Wed, 05 Jan 2005 07:15:54 -0800, Dakota Jack wrote:
> I realize it was an answer, Jan.  My question, however, is whether
> there is a problem when someone does not chain actions and whether
> there is not a way to avoid doubling actions or whether there is a
> real problem.  Is that unreasonable?  Or, are we just supposed to
> assume there is some imagined problem at the root of needing to
> change an entire archetecture?
>
> Jack
>
>
> On Wed, 5 Jan 2005 07:32:56 -, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>
>> Dakota,
>>
>>> -Original Message-
>>> From: Dakota Jack [mailto:[EMAIL PROTECTED]
>>> Sent: dinsdag 4 januari 2005 18:29
>>> To: Struts Developers List
>>> Subject: Re: Coupling, Struts and JSF
>>>
>>> Hi, Jan,
>>>
>>> I am less interested in how people make mistakes but rather in
>>> what the problem is for people that don't chain actions.
>>>
>>
>> It was an answer to your question:
>>
>> 
>>
>>> In the wiki, you say "[y]et in Struts 1.x, for example, the
>>> setup
>>>
>> logic
>>> and processing logic end up in two different Actions, requiring
>>> multiple action mappings".  Could you expand on this a bit
>>>
>>
>> 
>>
>> But I did expect this kind of reply.
>>
>>> Jack
>>>
>> Regards, Jan
>>
>> --
>> --- To unsubscribe, e-mail: [EMAIL PROTECTED] For
>> additional commands, e-mail: [EMAIL PROTECTED]
>
>
> --
> --
>
> "You can lead a horse to water but you cannot make it float on its
> back."
>
> ~Dakota Jack~
>
> "You can't wake a person who is pretending to be asleep."
>
> ~Native Proverb~
>
> "Each man is good in His sight. It is not necessary for eagles to
> be crows."
>
> ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
>
> ---
>
> "This message may contain confidential and/or privileged
> information. If you are not the addressee or authorized to receive
> this for the addressee, you must not use, copy, disclose, or take
> any action based on this message or any information herein. If you
> have received this message in error, please advise the sender
> immediately by reply e-mail and delete this message. Thank you for
> your cooperation."
>
> 
> - To unsubscribe, e-mail: [EMAIL PROTECTED] For
> additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32956] New: - in unix envrionment html,logic,bean tag libraries do not recognize duplication functions with different params

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32956

   Summary: in unix envrionment html,logic,bean tag libraries do not
recognize duplication functions with different params
   Product: Struts
   Version: 1.1 Final
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: Custom Tags
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


i have a bean called "Packet" which has following functions :


ArrayList getData( int key );
ArrayList getData();


when using the html , bean, logic tag libs provided with struts .. 
it does not recogize the second method "getData()"


this one works fine...



but when i do 

it should actually be calling getData() function but it gives error saying 
no getter set for property data in bean Packet.

Above all this works fine in Windows environment... but the error occurs in 
Unix ( Redhat ) environment

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32956] - in unix envrionment html,logic,bean tag libraries do not recognize duplication functions with different params

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32956





--- Additional Comments From [EMAIL PROTECTED]  2005-01-05 20:51 ---
I'll let someone else decide to officially mark this "INVALID", but I suspect
you're just running afoul of JavaBeans (and, perhaps, BeanUtils). In general,
you shouldn't overload accessor methods the way you've done with the Packet
class. I'll hazard a guess that the different behaviors you're observing have
nothing to do with the OS and everything to do with the JVM. Are you using
different JVM versions and/or vendors on the two OSes?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Bug in DownloadAction?

[Lane, Brad]

I believe there's a bug in org.apache.struts.actions.DownloadAction.
Overriding getBufferSize() doesn't have any effect since the byte array is
created with the static field DEFAULT_BUFFER_SIZE. 
 

Thanks, 
Brad 

Brad Lane 
Software Developer 
Pearson Educational Measurement 
eMeasurement(tm) Services 
http://www.pearsonedmeasurement.com/emeasurement/ 
Ph: (641) 844-0316 
Fx: (641) 754-6580 


 
This email may contain confidential material. 
If you were not an intended recipient, 
Please notify the sender and delete all copies. 
We may monitor email to and from our network. 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Coupling, Struts and JSF

[Dakota Jack]

Thanks, Ted.  I would not have guessed this was the focus without you
having said so.  Let me ask a further question, to get a better
understanding of what this is about.  I still am not clear, and I hope
to explain why in what follows.  I really am just trying to get a
grasp on what the problem is supposed to be as I said at the start of
this thread.  I would appreciate it greatly if you could hang in there
a bit on this one with me.  I like your clarity on these things.

When I use an action to go from A.jsp to B.jsp, I have to validate,
etc. for A.jsp and to setup for B.jsp.  This, in itself, is not a
problem and cannot be what you are talking about, I believe.  (If it
is, please tell me.)  If I want to use the same action going from
C.jsp to D.jsp, then I have the same thing, but a different mapping. 
This too cannot be the problem.  (If it is, again, please tell me.)

Maybe I have just provided myself with a solution, which we all must
do that does not seem like a "kludge" to me or something.  On pages, I
use constants to get information from a map on a form, such as DATA_1,
DATA_2, etc., and also constants for logical/operational information,
such as LOGIC_1, LOGIC_2, etc.  So, my pages have lots of things like
including "...='${whateverForm.map.LOGIC_1}'",
"...='${whateverForm.map.DATA_1)'", etc. and most actions include at
the start "whateverForm.clear()".  You get the idea.

There are lots of things that I see we could do with Struts and most
of them, if not all of them, have been discussed on the list.  But
this one has me mesmerized or confused.  Am I just missing the point
or what?  How could the setup and processing logic end up in two
different actions?  Or, why would anyone chain actions when they can
chain the way something is handled inside a single action?  I am just
not seeing this.  I am not saying there is nothing to see.

Jack


On Wed, 5 Jan 2005 13:21:26 -0500, Ted Husted <[EMAIL PROTECTED]> wrote:
> In practice, a rich page will require a lot of setup. For example, it's not 
> uncommon for page to have several select boxes that need to be populated. 
> When you prepare to setup the page, you might also need to look up a domain 
> record, as well as a user profile, and so forth.
> 
> After it's displayed, and the form is submitted, and found to be valid, the 
> rest of the logic is very different. We don't have to populate the form any 
> more, we just have to process the result. The result may mean updating a 
> database or doing something else entirely.
> 
> There are workarounds and kludges, but in classic Struts 1.x, validation is a 
> yes/no setting for each mapping and there is also one validation method per 
> mapping. When you are setting up the page, you don't want to validate the 
> input (or want to validate it differently). When you are processing the page, 
> you do want to validate the input. Hence, a cannonical need for multiple 
> mappings.  (Again, there are tricks you can plan, but this is not where we 
> discuss tricks, it's where we discuss changes that obviate tricks.)
> 
> In JSF and ASPX, this problem is addressed with a "postback" state. The 
> framework determines whether the page is being displayed or redisplayed, and 
> the backing bean (or code-behind) can act differently for each state.
> 
> Meanwhile, no one is proposing any revolutionary changes to the Struts 1.x 
> architecture. We are discussing a number of evolutionary changes, most of 
> which have been reduced to the roadmap, and all of which will be backwardly 
> compatible with the prior 1.x release. No matter what happens with Struts 
> 2.x, work will continue on Struts 1.x. At least, so long as there are 
> volunteers ready, willing, and able to do the work.
> 
> In a volunteer environment, Darwin always decides. The better technology 
> attracts the best volunteers. Better volunteers do better work, and the 
> spiral continues upward.
> 
> Which is better? I don't know. Neither do you, or Joe, or Craig. It's not up 
> to any one person. It's up to the community of volunteers who do the work, 
> both here and on the user list.
> 
> -Ted.
> 
> On Wed, 05 Jan 2005 07:15:54 -0800, Dakota Jack wrote:
> > I realize it was an answer, Jan.  My question, however, is whether
> > there is a problem when someone does not chain actions and whether
> > there is not a way to avoid doubling actions or whether there is a
> > real problem.  Is that unreasonable?  Or, are we just supposed to
> > assume there is some imagined problem at the root of needing to
> > change an entire archetecture?
> >
> > Jack
> >
> >
> > On Wed, 5 Jan 2005 07:32:56 -, [EMAIL PROTECTED]
> > <[EMAIL PROTECTED]> wrote:
> >
> >> Dakota,
> >>
> >>> -Original Message-
> >>> From: Dakota Jack [mailto:[EMAIL PROTECTED]
> >>> Sent: dinsdag 4 januari 2005 18:29
> >>> To: Struts Developers List
> >>> Subject: Re: Coupling, Struts and JSF
> >>>
> >>> Hi, Jan,
> >>>
> >>> I am less interested in how people make mistakes but rather i

Re: Coupling, Struts and JSF

[Dakota Jack]

Hello, again, Jan,

Having read Ted's response, I can now understand what you were saying.
 I just could not see why doing something like chaining an action made
any sense or believe that people actually do that.  What I would
naturally do is to provide a common helper class, Setup.java (or
Result.java), rather than a helper Action, ResultAction.java or even a
framework to hand the whole issue.  Am I missing something?  I have in
essence asked the same thing of Ted.

Maybe the difference is that I just have not even considered chaining
actions.  I thought that was just an example of something silly that
some people might do.  And, to my embarrassment, I guess that some
people think that is a good idea?

Jack


On Tue, 4 Jan 2005 15:28:05 -, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Jack,
> 
> A use case is:
> 
> - Two struts actions (say CreateAction and EditAction call the same jsp
> to view the result (say result.jsp).
> - This result.jsp needs some setup (eg. a list of items for a selection
> box).
> - The natural way to populate such a list in struts, is in the action.
> - To prevent having the logic to populate the list both in CreateAction
> and in EditAction,
>   some users create a new ResultAction, where they do the view
> preparation.
> - Then they chain the action (this is controversal stuff):
>   . In CreateAction they do creation logic, and than forward to
> ResultAction.
>   . In EditAction they do edit logic, and than forward to ResultAction.
> 
> As discussed in bug 16107:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16107
> 
> Regards, Jan
> 
> -Original Message-
> From: Dakota Jack [mailto:[EMAIL PROTECTED]
> Sent: dinsdag 4 januari 2005 15:34
> To: Struts Developers List
> Subject: Coupling, Struts and JSF
> 
> Craig,
> 
> I have been trying, again, to understand your position on Shale.  In
> the wiki, you say "[y]et in Struts 1.x, for example, the setup logic
> and processing logic end up in two different Actions, requiring
> multiple action mappings".  Could you expand on this a bit,
> remembering, if you would, that I am not a novice.  I have not run
> into a problem here and wonder what you are talking about in concrete
> terms.  I personally do not run into this problem and am
> philosophically counter to the idea that coupling can be good.  I am
> pretty "knee jerk" in favor of decoupling where possible.  This is one
> of the main reasons I have difficulty with JSF.  I really am contrary
> to the coupling.
> 
> Jack
> 
> --
> --
> 
> "You can lead a horse to water but you cannot make it float on its
> back."
> 
> ~Dakota Jack~
> 
> "You can't wake a person who is pretending to be asleep."
> 
> ~Native Proverb~
> 
> "Each man is good in His sight. It is not necessary for eagles to be
> crows."
> 
> ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
> 
> ---
> 
> "This message may contain confidential and/or privileged information.
> If you are not the addressee or authorized to receive this for the
> addressee, you must not use, copy, disclose, or take any action based
> on this message or any information herein. If you have received this
> message in error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation."
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
--

"You can lead a horse to water but you cannot make it float on its back."

~Dakota Jack~

"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

---

"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Coupling, Struts and JSF

[Frank W. Zammetti]

Hope no one minds an extra two cents here...
I've personally chained actions on a couple of ocassions, but what I 
find myself doing more of in cases like this where there is a "setup 
Action" and X number of "processing Actions" possible for a given screen 
is I code the setup Action in such a way that the other Actions can 
simply instantiate it and call execute().  It's relatively simple to 
make it function as a normal Action, as well as basically a helper class 
for another Action (and without any special branching logic or anything 
like that).  This is very similar to chaining, but doesn't incur the 
overhead (however much it really is) doing a forward, and doesn't get 
into all the complexity you can sometimes run into with two request 
contexts in essence when you chain (i.e., ActionForms reseting when you 
don't want them to and dealing with tokens and all that jazz).

Having only taken a cursory glance at JSF at this point, and attended a 
conference or two where it was discussed, I've had mixed feelings on it, 
but I do like the relatively tight coupling you are referring to.  I too 
am generally of the "DECOUPLE EVERYTHING!" mindset, but in this case I 
think it makes sense.  Frankly, I think Microsoft got it mostly right 
with ASP.Net, and JSF can in many ways be compared to that conceptually.

The flip-side (where my mixed feelings come in, partially) is that I've 
never really bought into the whole "call the server to handle every 
little UI event" model.  I suppose that's a separate debate though :)

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Dakota Jack wrote:
Hello, again, Jan,
Having read Ted's response, I can now understand what you were saying.
 I just could not see why doing something like chaining an action made
any sense or believe that people actually do that.  What I would
naturally do is to provide a common helper class, Setup.java (or
Result.java), rather than a helper Action, ResultAction.java or even a
framework to hand the whole issue.  Am I missing something?  I have in
essence asked the same thing of Ted.
Maybe the difference is that I just have not even considered chaining
actions.  I thought that was just an example of something silly that
some people might do.  And, to my embarrassment, I guess that some
people think that is a good idea?
Jack
On Tue, 4 Jan 2005 15:28:05 -, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
Jack,
A use case is:
- Two struts actions (say CreateAction and EditAction call the same jsp
to view the result (say result.jsp).
- This result.jsp needs some setup (eg. a list of items for a selection
box).
- The natural way to populate such a list in struts, is in the action.
- To prevent having the logic to populate the list both in CreateAction
and in EditAction,
 some users create a new ResultAction, where they do the view
preparation.
- Then they chain the action (this is controversal stuff):
 . In CreateAction they do creation logic, and than forward to
ResultAction.
 . In EditAction they do edit logic, and than forward to ResultAction.
As discussed in bug 16107:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16107
Regards, Jan
-Original Message-
From: Dakota Jack [mailto:[EMAIL PROTECTED]
Sent: dinsdag 4 januari 2005 15:34
To: Struts Developers List
Subject: Coupling, Struts and JSF
Craig,
I have been trying, again, to understand your position on Shale.  In
the wiki, you say "[y]et in Struts 1.x, for example, the setup logic
and processing logic end up in two different Actions, requiring
multiple action mappings".  Could you expand on this a bit,
remembering, if you would, that I am not a novice.  I have not run
into a problem here and wonder what you are talking about in concrete
terms.  I personally do not run into this problem and am
philosophically counter to the idea that coupling can be good.  I am
pretty "knee jerk" in favor of decoupling where possible.  This is one
of the main reasons I have difficulty with JSF.  I really am contrary
to the coupling.
Jack
--
--
"You can lead a horse to water but you cannot make it float on its
back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED

Re: Coupling, Struts and JSF

[Dakota Jack]

Lo, Frank,

Very interesting and very helpful.  I think I am starting to see what
you guys are thinking.  I have dealt with the same problems, of
course.

I bet we do something similar, Frank.  Here is a class I use which
uses other classes like actions, but they are not actions.  Is this
what you do?


public final class AdminAction
extends StateBaseAction {

  public AdminAction() {
  }

  public ActionForward execute(ActionMapping mapping,
   ActionForm form,
   HttpServletRequest request,
   HttpServletResponse response)
  throws IOException,
 ServletException {
HttpSessionsession = request.getSession();
StateContainer state   =
((StateContainer)request.getSession().getAttribute(SiteConstant.HOST_STATE_CONTAINER));

if(state == null) {
  state  = StateContainerFactory.getWebmasterStateContainer();
  ServletContext cntxt = servlet.getServletContext();
  cntxt.setAttribute(SiteConstant.HOST_STATE_CONTAINER,state);
}

User user = ((User)((Map)state.getMap()).get(SiteConstant.USER));

if(state == null) {
  state = StateContainerFactory.getStateContainer(user);
  session.setAttribute(SiteConstant.HOST_STATE_CONTAINER,state);
}

String layout = (String)state.get(SiteConstant.LAYOUT);

ActionForward forward= null;
try {
  forward = method(this,mapping,form,request,response);
} catch (Exception e) {
  StdOut.log(SiteConstant.ERROR_LOG,"\n\nAdminAction error = " +
e.getMessage() + " e = " + e);
  ActionMessages errors = new ActionMessages();
  errors.add(Globals.ERROR_KEY, new ActionMessage("webmaster.admin.token"));
  saveErrors(request, errors);

  StringBuffer sb = new
StringBuffer("").append(layout).append("_").append(mapping.getInput());
  forward = new ActionForward(sb.toString());
}

return forward;
  }

  public ActionForward exit (ActionMapping
mapping, ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {
return new AdminActionExit().execute(mapping,form,request,response); }
  public ActionForward guestOptions (ActionMapping
mapping, ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {
return new AdminActionGuestOptions().execute(mapping,form,request,response);
}
  public ActionForward hostGuestChange  (ActionMapping
mapping, ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {
return new AdminActionHostGuestChange().execute(mapping,form,request,response);
}
  public ActionForward hostGuestCreate  (ActionMapping
mapping, ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {
return new AdminActionHostGuestCreate().execute(mapping,form,request,response);
}
  public ActionForward hostGuestDelete  (ActionMapping
mapping, ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {
return new AdminActionHostGuestDelete().execute(mapping,form,request,response);
}
  public ActionForward hostGuestOptions (ActionMapping
mapping, ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {
return new AdminActionHostGuestOptions().execute(mapping,form,request,response);
}
  public ActionForward hostGuestView(ActionMapping
mapping, ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {
return new AdminActionHostGuestView().execute(mapping,form,request,response);
}
  public ActionForward hostHostChange   (ActionMapping
mapping, ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {
return new AdminActionHostHostChange().execute(mapping,form,request,response);
}
  public ActionForward hostHostOptions  (ActionMapping
mapping, ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {
return new AdminActionHostHostOptions().execute(mapping,form,request,response);
}
  public ActionForward hostLookAndFeel  (ActionMapping
mapping, ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {
return new AdminActionHostLookAndFeel().execute(mapping,form,request,response);
}
  public ActionForward hostLookAndFeelChange(ActionMapping
mapping, ActionForm form, HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {
return new 
AdminActionHostLookAndFeelChange().execute(mapping,form,request,response);
}
  public ActionForward w

Re: Coupling, Struts and JSF

[Ted Husted]

I believe the use case is not about going from A to B. It's about going to A 
and then submitting data from A. The design of Struts 1.x encourages us to use 
one mapping to display a form and another to submit a form. (There may or may 
not be more than Action class behind the mappings. I've written many 
application that use one Action class and lots and lots of mappings.) The 
design of JSF and ASPX encourage you to use one mapping for both display and 
submit. Those frameworks are designed around the notion of a "postback" state. 
If it's not a postback, you can initialize the controls and skip to the 
response. If it is a postback, then the validation and update phases fire. 
Moreover, since the controls can maintain their own state, you don't have to 
repopulate them yourself on a postback where validation fails. As a result, 
there are fewer mappings to write (which leads to fewer mappings to debug).

-T.

On Wed, 05 Jan 2005 14:43:16 -0800, Dakota Jack wrote:
> Thanks, Ted.  I would not have guessed this was the focus without
> you having said so.  Let me ask a further question, to get a better
> understanding of what this is about.  I still am not clear, and I
> hope to explain why in what follows.  I really am just trying to
> get a grasp on what the problem is supposed to be as I said at the
> start of this thread.  I would appreciate it greatly if you could
> hang in there a bit on this one with me.  I like your clarity on
> these things.
>
> When I use an action to go from A.jsp to B.jsp, I have to validate,
> etc. for A.jsp and to setup for B.jsp.  This, in itself, is not a
> problem and cannot be what you are talking about, I believe.  (If
> it is, please tell me.)  If I want to use the same action going
> from C.jsp to D.jsp, then I have the same thing, but a different
> mapping. This too cannot be the problem.  (If it is, again, please
> tell me.)
>
> Maybe I have just provided myself with a solution, which we all
> must do that does not seem like a "kludge" to me or something.  On
> pages, I use constants to get information from a map on a form,
> such as DATA_1, DATA_2, etc., and also constants for
> logical/operational information, such as LOGIC_1, LOGIC_2, etc.
> So, my pages have lots of things like including
> "...='${whateverForm.map.LOGIC_1}'",
> "...='${whateverForm.map.DATA_1)'", etc. and most actions include
> at the start "whateverForm.clear()".  You get the idea.
>
> There are lots of things that I see we could do with Struts and
> most of them, if not all of them, have been discussed on the list.
> But this one has me mesmerized or confused.  Am I just missing the
> point or what?  How could the setup and processing logic end up in
> two different actions?  Or, why would anyone chain actions when
> they can chain the way something is handled inside a single action?
>  I am just not seeing this.  I am not saying there is nothing to
> see.
>
> Jack
>
>
> On Wed, 5 Jan 2005 13:21:26 -0500, Ted Husted <[EMAIL PROTECTED]>
> wrote:
>
>> In practice, a rich page will require a lot of setup. For
>> example, it's not uncommon for page to have several select boxes
>> that need to be populated. When you prepare to setup the page,
>> you might also need to look up a domain record, as well as a user
>> profile, and so forth.
>>
>> After it's displayed, and the form is submitted, and found to be
>> valid, the rest of the logic is very different. We don't have to
>> populate the form any more, we just have to process the result.
>> The result may mean updating a database or doing something else
>> entirely.
>>
>> There are workarounds and kludges, but in classic Struts 1.x,
>> validation is a yes/no setting for each mapping and there is also
>> one validation method per mapping. When you are setting up the
>> page, you don't want to validate the input (or want to validate
>> it differently). When you are processing the page, you do want to
>> validate the input. Hence, a cannonical need for multiple
>> mappings.  (Again, there are tricks you can plan, but this is not
>> where we discuss tricks, it's where we discuss changes that
>> obviate tricks.)
>>
>> In JSF and ASPX, this problem is addressed with a "postback"
>> state. The framework determines whether the page is being
>> displayed or redisplayed, and the backing bean (or code-behind)
>> can act differently for each state.
>>
>> Meanwhile, no one is proposing any revolutionary changes to the
>> Struts 1.x architecture. We are discussing a number of
>> evolutionary changes, most of which have been reduced to the
>> roadmap, and all of which will be backwardly compatible with the
>> prior 1.x release. No matter what happens with Struts 2.x, work
>> will continue on Struts 1.x. At least, so long as there are
>> volunteers ready, willing, and able to do the work.
>>
>> In a volunteer environment, Darwin always decides. The better
>> technology attracts the best volunteers. Better volunteers do
>> better work, and the spiral continues upward

DO NOT REPLY [Bug 32959] New: - NullPointerException in FacesRequestProcessor.prcocessActionPerform

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32959

   Summary: NullPointerException in
FacesRequestProcessor.prcocessActionPerform
   Product: Struts
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Struts-Faces Library
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


There is a bug (line 241-242) in FacesRequestProcessor.prcocessActionPerform
that will result in a NullPointerException if the result returned from method
processActionPerform is null and if debug is enabled.  The version I refer to is
the nightly build as at struts-faces-20050104.tar

   protected ActionForward processActionPerform(HttpServletRequest request,
 HttpServletResponse response,
 Action action,
 ActionForm form,
 ActionMapping mapping)
throws IOException, ServletException {

if (log.isTraceEnabled()) {
log.trace("Performing standard action perform");
}
ActionForward result =
super.processActionPerform(request, response, action,
   form, mapping);
if (log.isDebugEnabled()) {
 // ### BUG: result can be null ###
log.debug("Standard action perform returned " +
  result.getPath() + " forward path");
}
return (result);

}

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Coupling, Struts and JSF

[Frank W. Zammetti]

No, I was talking about something even more mundane...
public class AdminSystemControlAction extends Action {
  public ActionForward execute(ActionMapping mapping, ActionForm form, 
HttpServletRequest request, HttpServletResponse response) throws Exception {
ClientFB clFB = new ClientFB();
form.setLogosList(clFB.getLogosList());
form.setSignaturesList(clFB.getSignaturesList());
form.setManagementReportsList(clFB.getReportList());
return mapping.findForward("defaultForward");
  } // End execute()
} // End class

This is an Action I use, with a bunch of other stuff removed for 
brevity, when I initially show the System Control screen of one 
application I did.  These are three ArrayLists, generated from a 
database, which are used to populate some dropdowns.

Now, this particular screen is a high-level admin screen, and you can 
perform probably 40 different functions from it.  So, there's a bunch of 
Actions, generally speaking, one per function.  But, after each, I need 
to populate those dropdowns again.

So, what you could of course do is have a helper class that does the 
above, and everything else required to set up the screen.

But, what has always bothered me about this, and it's a debatable point 
I'll say right up front, is that I tend to view the Control layer as a 
little closer to the View than the Model.  Application flow control I 
consider more of a presentation consideration than a business logic 
consideration.  Having business delegates encapsulating the actual 
business logic of a system makes perfect sense to me, but populating 
dropdowns is really a view task.  So, most people would agree your not 
going to access a database from JSP code to populate dropdowns for 
instance, so your going to be doing it in the Control layer.

But, why add complexity to the code base by having "view delegates"? 
That's really what your doing by having helper classes called from an 
Action to populate a screen.  I think there are some reasonable 
arguments to be made for this, but I've always felt it's just a little 
redundant.

So, getting to my point... instead of adding a helper class to do this 
screen population from the other 40 Actions, I would instead just do 
this at the end of those Actions:

  AdminSystemControlAction ascac = new AdminSystemControlAction();
  af = ascac.execute(mapping, form, request, response);
  return mapping.findForward("whatever");
See?  It's nothing more than treating the first "setup" Action as a 
helper class!  Like I said, pretty mundane.  But what it does, in my 
mind at least, is reduces the number of classes I have.

You do have to be a little careful that the setup Action can function 
this way... It might be possible to write code in it that has some bad 
side-effects when called this way, but it's a pretty minor consideration 
generally speaking.

That's what I was talking about.  Nothing grandiose by any stretch, but 
it's surprising that a lot of Struts developers don't even realize this 
is possible!  I've told this to a number of people and they've reacted 
with surprise, they thought for some reason you couldn't just 
instantiate an Action and call execute() on it.  I guess they forget 
it's just a class after all.

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Dakota Jack wrote:
Lo, Frank,
Very interesting and very helpful.  I think I am starting to see what
you guys are thinking.  I have dealt with the same problems, of
course.
I bet we do something similar, Frank.  Here is a class I use which
uses other classes like actions, but they are not actions.  Is this
what you do?
public final class AdminAction
extends StateBaseAction {
  public AdminAction() {
  }
  public ActionForward execute(ActionMapping mapping,
   ActionForm form,
   HttpServletRequest request,
   HttpServletResponse response)
  throws IOException,
 ServletException {
HttpSessionsession = request.getSession();
StateContainer state   =
((StateContainer)request.getSession().getAttribute(SiteConstant.HOST_STATE_CONTAINER));
if(state == null) {
  state  = StateContainerFactory.getWebmasterStateContainer();
  ServletContext cntxt = servlet.getServletContext();
  cntxt.setAttribute(SiteConstant.HOST_STATE_CONTAINER,state);
}
User user = ((User)((Map)state.getMap()).get(SiteConstant.USER));
if(state == null) {
  state = StateContainerFactory.getStateContainer(user);
  session.setAttribute(SiteConstant.HOST_STATE_CONTAINER,state);
}
String layout = (String)state.get(SiteConstant.LAYOUT);
ActionForward forward= null;
try {
  forward = method(this,mapping,form,request,response);
} catch (Exception e) {
  StdOut.log(SiteConstant.ERROR_LOG,"\n\nAdminAction error = " +
e.getMessage() + " e = " + e);
  ActionMessages errors = new ActionMessages(

DO NOT REPLY [Bug 32959] - NullPointerException in FacesRequestProcessor.prcocessActionPerform

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32959





--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 04:55 ---
Same bug exists in FacesTilesRequestProcessor.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Coupling, Struts and JSF

[gvanmatre]

-- Original message -- 

> I believe the use case is not about going from A to B. It's about going to A 
> and 
> then submitting data from A. The design of Struts 1.x encourages us to use 
> one 
> mapping to display a form and another to submit a form. (There may or may not 
> be 
> more than Action class behind the mappings. I've written many application 
> that 
> use one Action class and lots and lots of mappings.) The design of JSF and 
> ASPX 
> encourage you to use one mapping for both display and submit. Those 
> frameworks 
> are designed around the notion of a "postback" state. If it's not a postback, 
> you can initialize the controls and skip to the response. If it is a 
> postback, 
> then the validation and update phases fire. Moreover, since the controls can 
> maintain their own state, you don't have to repopulate them yourself on a 
> postback where validation fails. As a result, there are fewer mappings to 
> write 
> (which leads to fewer mappings to debug). 
> 
> -T. 
> 

I suppose that if you preferred the action chaining method in struts you might 
consider something similar in JSF.  You might be able to use a servlet as a 
passthru action as long as it has been dispatched thru the faces servlet.  In 
this example I’m using a prefix mapping to the servlet, “/faces/*”.  From the 
A.jsp I have a submit button that forwards to the servlet via faces servlet.  
The servlet redirects to itself a few times using the navigation rules in the 
faces config and finally redirects back to the original page.   
 
I suppose that this is similar to how you might handle it struts.  Kind of 
similar?  The servlet and web deployment descriptor take the place of the 
struts action.  The navigation rules are still defined in a declarative nature. 
 The only catch is that a forward won’t work from the servlet.  
 
IMHO, I really dig JSF, but struts handle this situation better.  The postback 
method that Ted talks about seems like a better JSF solution.

Gary
 
A.jsp
 

 
 
faces-config.xml
 
  
 /A.jsp
 
somethingFat
/StageServlet
 
  
  
  
 /StageServlet
 
next
/A.jsp

 
 
loop
/StageServlet

 
 
  
 
Chained Action Servlet
 
public class StageServlet extends HttpServlet {
 
  public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
 
Integer cntr = (Integer) req.getSession().getAttribute("cntr");
if (cntr == null) {
  cntr = new Integer(1);
} else {
  cntr = new Integer(cntr.intValue() + 1);
}
req.getSession().setAttribute("cntr", cntr);
 
System.out.println("Hello " + cntr.intValue() + " time(s).");
 
String forward = null;
if (cntr.intValue() > 2)
  forward = "next";
else
  forward = "loop";
 
FacesContext context = FacesContext.getCurrentInstance();
NavigationHandler handler =
  context.getApplication().getNavigationHandler();
 
handler.handleNavigation(context, null, forward);
 
  }
 

Re: Coupling, Struts and JSF

[gvanmatre]

-- Original message -- 

> I believe the use case is not about going from A to B. It's about going to A 
> and 
> then submitting data from A. The design of Struts 1.x encourages us to use 
> one 
> mapping to display a form and another to submit a form. (There may or may not 
> be 
> more than Action class behind the mappings. I've written many application 
> that 
> use one Action class and lots and lots of mappings.) The design of JSF and 
> ASPX 
> encourage you to use one mapping for both display and submit. Those 
> frameworks 
> are designed around the notion of a "postback" state. If it's not a postback, 
> you can initialize the controls and skip to the response. If it is a 
> postback, 
> then the validation and update phases fire. Moreover, since the controls can 
> maintain their own state, you don't have to repopulate them yourself on a 
> postback where validation fails. As a result, there are fewer mappings to 
> write 
> (which leads to fewer mappings to debug). 
> 
> -T. 
> 

I suppose that if you preferred the action chaining method in struts you might 
consider something similar in JSF.  You might be able to use a servlet as a 
passthru action as long as it has been dispatched thru the faces servlet.  In 
this example I’m using a prefix mapping to the servlet, “/faces/*”.  From the 
A.jsp I have a submit button that forwards to the servlet via faces servlet.  
The servlet redirects to itself a few times using the navigation rules in the 
faces config and finally redirects back to the original page. 

I suppose that this is similar to how you might handle it struts.  Kind of 
similar?  The servlet and web deployment descriptor take the place of the 
struts action.  The navigation rules are still defined in a declarative nature. 
 The only catch is that a forward won’t work from the servlet.  

IMHO, I really dig JSF, but struts handle this situation better.

Gary

A.jsp


faces-config.xml
 
/A.jsp

   somethingFat
   /StageServlet

 
 
 
/StageServlet

   next
   /A.jsp
   


   loop
   /StageServlet
   

 

Chained Action Servlet

public class StageServlet extends HttpServlet {
 public void doGet(HttpServletRequest req, HttpServletResponse resp)
  throws ServletException, IOException {
  Integer cntr = (Integer) req.getSession().getAttribute("cntr");
  if (cntr == null) {
   cntr = new Integer(1);
  } else {
   cntr = new Integer(cntr.intValue() + 1);
  }
  req.getSession().setAttribute("cntr", cntr);
  System.out.println("Hello " + cntr.intValue() + " times.");
  String forward = null;
  if (cntr.intValue() > 2)
   forward = "next";
  else
   forward = "loop";
  FacesContext context = FacesContext.getCurrentInstance();
  NavigationHandler handler =
   context.getApplication().getNavigationHandler();
  handler.handleNavigation(context, null, forward);
 }

Re: Coupling, Struts and JSF

[Craig McClanahan]

On Thu, 06 Jan 2005 04:32:56 +, [EMAIL PROTECTED]

> [snip]
> IMHO, I really dig JSF, but struts handle this situation better.  The postback
> method that Ted talks about seems like a better JSF solution.

Indeed, the postback approach is what I used in the Shale proposal. 
The basic idea is that there's a backing bean associated with each JSP
page, with the following four lifecycle methods defined:

public void init() - called when the view for this page is either
created or destroyed.  Useful to allocate resources you need for both
form processing and rendering

public void preprocess() - called if this request is a postback ...
i.e. we are about to perform the Apply Request Values through Invoke
Application phases of the JSF lifecycle.  Useful to allocate resources
that are only needed for event handling.

public void prerender() -- called if we are about to render this page
(i.e. the Render Response phase).  Useful to allocate resources (such
as open a JDBC ResultSet that backs a table) needed only for the
duration of rendering.

public void destroy() -- called if init() was ever called.  Useful for
cleaning up any resources allocated in earlier lifecycle events (such
as closing the JDBC ResultSet you might have opened in prerender()).

Interestingly, I got the idea for prerender() directly from Struts
:-).  Tiles has the concept of a Controller
(org.apache.struts.tiles.Controller) whose execute() method is called
at the point in the Struts lifecycle analogous to where prerender() is
called by Shale.

Compared to the typical approaches used in Struts for the setup, this
turns out to be easier to program for a variety of reasons:

* No chaining involved, as you would see in the typical pattern
  of a "process action" for the previous form chained to a
  "setup action" for the next action.

* No need for a helper class to encapsulate the common setup
  logic (nor for Frank's "instantiate the setup action and call execute"
  approach, which is very clever but clearly points out a flaw in
  the current Struts application model :-).

* Since there is no need for a form bean in Shale, all
  "communication" between the various parts of the lifecycle can
  happen via instance variables in a single class, with no need to
  construct multiple classes, or expose those classses via public
  APIs that might be called by anyone.

* ViewControllers are much easier to "get right the first time"
  - you can visually inspect them to see that there is corresponding
cleanup code for every resource allocation.  The framework
guarantees that all the lifecycle methods will be called at the
right time, no matter what configuration settings the developer
uses.
  - you can write unit tests for ViewControllers very easily
compared to what it takes to unit test the combination
of Actions and form beans that it takes to represent the
processing for a single HTTP request in Struts.

> 
> Gary
> 

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Coupling, Struts and JSF

[Dakota Jack]

On Wed, 5 Jan 2005 19:33:39 -0500, Ted Husted <[EMAIL PROTECTED]> wrote:


The design of Struts 1.x encourages us to use one mapping to display a
form and another to submit a form.


When I think of forms I think of .  When I
display the form, I do so from some action.  When I submit it, I do so
to some action.  These may or may not be the same action.  I am fairly
sure this describes what others do.  What "encourages us to use one
mapping to display a form and another to submit a form"?  I am equally
sure you have something to tell me here, but I am not getting it.

Maybe we are looking at things a bit differently?

?Action.java --> display --> A.jsp --> submit --> AAction.java: -->
display --> B.jsp

You see the mappings related to A.jsp and its form(s), which makes two
mappings for the dispaly and submission of the form: the mapping for
?Action.java and AAction.java.  I see a single mapping related to
AAction.java which handles both display (of B.jsp) and submission (of
A.jsp).  You think of display --> submit.  I think of submit -->
display.  So, you think of 1.x as encouraging two mappings; I think of
1.x somewhat necessitating one mapping.

This make sense to you?

Jack

-- 
--

"You can lead a horse to water but you cannot make it float on its back."

~Dakota Jack~

"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

---

"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Coupling, Struts and JSF

[Craig McClanahan]

On Wed, 5 Jan 2005 22:09:28 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:

> This make sense to you?

It certainly does ... but that's only because you and I are wierd :-).

The pattern you describe makes perfect sense to someone who
understands object oriented programming, and design patterns, and
appropriate mechanisms for reuse.  It makes *no* sense at all to
people whose initial exposure to programming was VB, or some scripting
language like PHP or PERL.  What's an "object"?  What's a "class"? 
For that matter, what's "reuse" (because their definition is
"cut-n-paste')?  Now, guess how many people in the world understand
object oriented programming, and appropriate reuse, and all of that,
versus the people that are struggling to write their first non-"Hello
World" application in Java.

It amazes me how many people have gone through this struggle and
actually succeeded, using Struts as their crutch.  It saddens me how
many others of these people find the picture you describe as too
complicated to understand, and therefore give up on Java as being "too
hard."  That's an audience I care about supporting; there's lots of
frameworks around that do a great job for O-O geeks (and many of them
do it much better than Struts, mostly because they came second and not
first, but better nonetheless).  There are basically no frameworks in
the world that a developer familiar with a scripting language will
feel comfortable with out of the box.

> 
> Jack
> 

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Coupling, Struts and JSF

[Craig McClanahan]

On Wed, 5 Jan 2005 22:27:40 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote:

> There are basically no frameworks in
> the world that a developer familiar with a scripting language will
> feel comfortable with out of the box.

Of course "no frameworks" was supposed to say "no Java-based frameworks"

Craig

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Coupling, Struts and JSF

[Dakota Jack]

Ted, I think I may be getting where our communication was breaking
down in my head.

Suppose X.Action --> display --> X.jsp --> submit Y.Action --> display
--> Y.jsp.  Now, what about the ActionForm?

You seem to see the ActionForm as relating primarily to some X.jsp,
i.e. XActionForm.java and the  on that page.  This, of
course, leads rather customarily to two actions and two mappings and
to the sorts of issues you raise.

Is that right?  I apologize if I am misunderstanding you.  I am trying
to see why what you say mystifies me and I might not be getting it
right.

If so, if I am right about what you are doing, my perspective is
different.  I do not see the YActionForm.java as related to Y.jsp but
to X.jsp AND Y.jsp *which could be, of course, the same) and to any
other submission and display JSPs which are mapped to YAction.java.

If I understand your focus, it is on the ActionForm and the ActionForm
is a bridge between Actions, leading to seeing two mappings, two
Actions.  My focus is on the Action and the Action is a bridge between
two siews.  So, your focus leads to ActionForms tied to a paritcular
view and my focus leads to ActionsForms tied to two views.

I hope this is not all wrong-headed and that I have not understood a
word you are saying.  I am a good learner but sometimes slow.  I tend
to learn these things on my own and find out later how others think.

Jack

-- 
--

"You can lead a horse to water but you cannot make it float on its back."

~Dakota Jack~

"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

---

"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Coupling, Struts and JSF

[JAN . Cumps]

Jack,

Ted once suggested to add a 'FrontController'.
That class could be optionally plugged into the action mapping, and
would do the view preparation.

Regards, Jan

-Original Message-
From: Dakota Jack [mailto:[EMAIL PROTECTED]
Sent: donderdag 6 januari 2005 0:00
To: Struts Developers List
Subject: Re: Coupling, Struts and JSF


Hello, again, Jan,

Having read Ted's response, I can now understand what you were saying.
 I just could not see why doing something like chaining an action made
any sense or believe that people actually do that.  What I would
naturally do is to provide a common helper class, Setup.java (or
Result.java), rather than a helper Action, ResultAction.java or even a
framework to hand the whole issue.  Am I missing something?  I have in
essence asked the same thing of Ted.

Maybe the difference is that I just have not even considered chaining
actions.  I thought that was just an example of something silly that
some people might do.  And, to my embarrassment, I guess that some
people think that is a good idea?

Jack


On Tue, 4 Jan 2005 15:28:05 -, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Jack,
> 
> A use case is:
> 
> - Two struts actions (say CreateAction and EditAction call the same
jsp
> to view the result (say result.jsp).
> - This result.jsp needs some setup (eg. a list of items for a
selection
> box).
> - The natural way to populate such a list in struts, is in the action.
> - To prevent having the logic to populate the list both in
CreateAction
> and in EditAction,
>   some users create a new ResultAction, where they do the view
> preparation.
> - Then they chain the action (this is controversal stuff):
>   . In CreateAction they do creation logic, and than forward to
> ResultAction.
>   . In EditAction they do edit logic, and than forward to
ResultAction.
> 
> As discussed in bug 16107:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16107
> 
> Regards, Jan
> 
> -Original Message-
> From: Dakota Jack [mailto:[EMAIL PROTECTED]
> Sent: dinsdag 4 januari 2005 15:34
> To: Struts Developers List
> Subject: Coupling, Struts and JSF
> 
> Craig,
> 
> I have been trying, again, to understand your position on Shale.  In
> the wiki, you say "[y]et in Struts 1.x, for example, the setup logic
> and processing logic end up in two different Actions, requiring
> multiple action mappings".  Could you expand on this a bit,
> remembering, if you would, that I am not a novice.  I have not run
> into a problem here and wonder what you are talking about in concrete
> terms.  I personally do not run into this problem and am
> philosophically counter to the idea that coupling can be good.  I am
> pretty "knee jerk" in favor of decoupling where possible.  This is one
> of the main reasons I have difficulty with JSF.  I really am contrary
> to the coupling.
> 
> Jack
> 
> --
> --
> 
> "You can lead a horse to water but you cannot make it float on its
> back."
> 
> ~Dakota Jack~
> 
> "You can't wake a person who is pretending to be asleep."
> 
> ~Native Proverb~
> 
> "Each man is good in His sight. It is not necessary for eagles to be
> crows."
> 
> ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
> 
> ---
> 
> "This message may contain confidential and/or privileged information.
> If you are not the addressee or authorized to receive this for the
> addressee, you must not use, copy, disclose, or take any action based
> on this message or any information herein. If you have received this
> message in error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation."
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
--

"You can lead a horse to water but you cannot make it float on its
back."

~Dakota Jack~

"You can't wake a person who is pretending to be asleep."

~Native Proverb~

"Each man is good in His sight. It is not necessary for eagles to be
crows."

~Hunkesni (Sitting Bull), Hunkpapa Sioux~

---

"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---