The point of this reply is that you'd want to ensure that your setup
command gets called as part of the render() lifecycle, so that you can
do the setup stuff even if your portlet wasn't the one that processed
this request's form values. It might even mean some thought should be
put into separatin
On Thu, January 6, 2005 1:30 pm, Ted Husted said:
> I'd say JSF and ASPX are similar in the same way that Struts and WebWorks
> and Maverick are similar. The broad strokes of the architectures resonate,
> but there are significant differences in the implementation details.
True enough, and it's in
On Wed, 05 Jan 2005 18:40:40 -0500, Frank W. Zammetti wrote:
> Frankly, I think Microsoft got it mostly right
> with ASP.Net, and JSF can in many ways be compared to that
> conceptually.
I'd say JSF and ASPX are similar in the same way that Struts and WebWorks and
Maverick are similar. The broad
If working in portlets is still an item of interest for a chained
request processor, there's an interesting synergy with the way that
JSR168 defines its request processing lifecycle as well.
When a portlet request comes in, the container passes the request to
the processAction() method of the one-
At 11:03 AM -0600 1/6/05, Hubert Rabago wrote:
Hi Joe,
I've also been interested in these discussions, though our earlier
discussions revolved around the old RequestProcessor. I haven't had a
chance to try out the shiny new chain (or is it still rusty and needs
some polishing?), so lately I've bee
Hi Joe,
I've also been interested in these discussions, though our earlier
discussions revolved around the old RequestProcessor. I haven't had a
chance to try out the shiny new chain (or is it still rusty and needs
some polishing?), so lately I've been limited to lurking.
That said, I too believ
At 7:30 AM + 1/6/05, [EMAIL PROTECTED] wrote:
Ted once suggested to add a 'FrontController'.
That class could be optionally plugged into the action mapping, and
would do the view preparation.
This is an idea I've been poking at and talking about for quite some
time, but I am getting the feelin
I would not have written this had I received Craig's note first.
Sometimes someone has to tell you that you are not nuts.
Jack
On Wed, 5 Jan 2005 22:54:09 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> Ted, I think I may be getting where our communication was breaking
> down in my head.
>
> S
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
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 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 framework
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
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
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 th
-- 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 no
-- 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 no
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();
e 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
>>&
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
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
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.
ing to
> > change an entire archetecture?
> >
> > Jack
> >
> >
> > On Wed, 5 Jan 2005 07:32:56 -, [EMAIL PROTECTED]
> > <[EMAIL PROTECTED]> wrote:
> >
> >> Dakota,
> >>
> >>> -Original Message-
> >
TED]> 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
>>>
>
uari 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 an
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
You might also note, Joe, that I started this thread in an attempt to
find out more about what Craig is saying, in the case that I might be
misunderstanding. I don't have any intentions other than honorable on
this.
Jack
On Tue, 4 Jan 2005 12:10:13 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
Thanks, Joe,
But I have reasons for caring about this that have nothing to do with
you. If there is what seems to be misinformation on a point that
matters to me, I find that worth comment each time the "information"
arises. I realize you would do something different but there are many
paths in
At 9:35 AM -0800 1/4/05, Dakota Jack wrote:
Craig's says that the problem is solved by tight coupling. That also
seems to be true.
Look, Jack: we all realize that you don't care for JSF and don't
think it should be a fundamental component of anything called Struts.
You don't need to toss off res
Craig's says that the problem is solved by tight coupling. That also
seems to be true.
Jack
On Tue, 4 Jan 2005 09:53:07 -0600, Durham David R Jr Contr 805
CSPTS/SCE <[EMAIL PROTECTED]> wrote:
> > I suppose one implication of this is that the logic necessary to
> > "populate" a page is coupled w
Why not just create a helper class common to the two actions and not
chain a third action? Likewise, if this is the main difficulty, why
not just follow through on divorcing the form and the action? That
would be GREAT!
Jack
On Tue, 4 Jan 2005 10:44:11 -0500, Sean Schofield
<[EMAIL PROTECTED]>
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.
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 EditA
> I suppose one implication of this is that the logic necessary to
> "populate" a page is coupled with the page itself (or at least
> the choice of logic).
As I understand it, no, they are not tightly coupled. JSF has a
configuration. You give a bean a name, and you tell a component to use
th
> 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 prev
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 havin
34 matches
Mail list logo
