beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlin Rogers <carlin.rog...@gmail.com>
Subject Re: NetUI BVT - StrutsMerge test4 question
Date Thu, 19 Jan 2006 23:25:34 GMT
Excellent. Thanks for the reply.

Carlin

On 1/19/06, Rich Feit <richfeit@gmail.com> wrote:
>
> I think you're right, and I have no idea why the JSP used the
> disambiguated action directly.  This is an implementation detail (which
> incidentally didn't always work this way), and isn't doc'ed or
> supported, and which would take some digging even to uncover for the
> common user.  I certainly don't object to modifying it.
>
> Rich
>
> Carlin Rogers wrote:
> > I was wondering if anyone knows the history of this particular NetUI BVT
> for
> > Struts merge. The test is in
> netui/test/webapps/drt/web/strutsMerge/test4/.
> > The page flow Controller has a five actions. One is the begin action,
> and
> > the others are overloaded...
> > jpfAction1(Form1 inForm)
> > jpfAction1(Form2 inForm)
> > jpfAction2(Form1 inForm)
> > jpfAction2(Form2 inForm)
> >
> > where Form1 is declared locally in the page flow,
> > strutsMerge.test4.Jpf1.Form1, and Form2 is a class in the
> > strutsMerge.test4package of the src dir. Form2 is also defined as a
> > <form-bean> in the local
> > Struts config file being merged with the page flow Controller.
> >
> > For these four actions/methods, the NetUI compiler ends up creating six
> > <action>'s in the action-mappings of the Struts config module we
> generate.
> > Since the actions are overloaded the NetUI compiler disambiguated the
> action
> > paths using the form bean parameter of the action method. So we get
> action
> > paths...
> > /jpfAction1
> > /jpfAction1_strutsMerge_test4_Form2
> > /jpfAction1_strutsMerge_test4_Jpf1_Form1
> > /jpfAction2
> > /jpfAction2_strutsMerge_test4_Form2
> > /jpfAction2_strutsMerge_test4_Jpf1_Form1
> >
> > Note that there are first two are really the same action
> (jpfAction1(Form2
> > inForm)) and the fourth and fifth are the same actions jpfAction2(Form2
> > inForm).
> >
> > In the test, the page Jsp2.jsp directly uses the generated disambiguated
> > actions for the anchor and form tags in the page. I'm wondering what
> this is
> > testing and why we have this? Would a user ever directly want to use our
> > generated values for the action paths? For instance the test page has a
> > tag...
> >
> > <netui:anchor
> > action="jpfAction2_strutsMerge_test4_Form2">continue</netui:anchor>
> >
> > But this is really the same as (and behaves the same in the runtime
> as)...
> >
> > <netui:anchor action="jpfAction2">continue</netui:anchor>
> >
> > The reason I ask is related to work I've done to solve some issues with
> > overloading actions and our DelegatingActionModel. I believe that there
> > should just be four actions in the struts config file for the four
> actions
> > in the page flow controller (five including the begin action) and that
> the
> > two extra a just a side effect of our current implementation. With my
> > implementation, the generated struts config module would only have the
> > actions...
> >
> > /jpfAction1
> > /jpfAction1_strutsMerge_test4_Jpf1_Form1
> > /jpfAction2
> > /jpfAction2_strutsMerge_test4_Jpf1_Form1
> >
> > where /jpfAction1 and /jpfAction2 are for the overloaded actions that
> use
> > Form2.
> >
> > However, I have no idea why this test page would use the generated
> > disambiguated name. Anyway, the reason I ask is that with my changes,
> this
> > test will fail because I will no longer have the extra action entries in
> the
> > mapping.
> >
> > If nobody has any idea about the history of this test, is there any
> > objection to me modifying the test page to use the "jpfAction2" action?
> >
> > Thanks,
> > Carlin
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message