beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <>
Subject Re: NetUI BVT - StrutsMerge test4 question
Date Thu, 19 Jan 2006 22:36:35 GMT
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.


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

View raw message