beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlin Rogers <>
Subject NetUI BVT - StrutsMerge test4 question
Date Thu, 19 Jan 2006 06:04:04 GMT
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

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

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


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


where /jpfAction1 and /jpfAction2 are for the overloaded actions that use

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

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?


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