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
