Excellent. Thanks for the reply. Carlin
On 1/19/06, Rich Feit <[EMAIL PROTECTED]> 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 > > > > >
