Return-Path: 
 <dev-return-8696-apmail-beehive-dev-archive=beehive.apache.org@beehive.apache.org>
Delivered-To: apmail-beehive-dev-archive@www.apache.org
Received: (qmail 26126 invoked from network); 19 Jan 2006 22:37:05 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 19 Jan 2006 22:37:05 -0000
Received: (qmail 90643 invoked by uid 500); 19 Jan 2006 22:37:03 -0000
Delivered-To: apmail-beehive-dev-archive@beehive.apache.org
Received: (qmail 90619 invoked by uid 500); 19 Jan 2006 22:37:03 -0000
Mailing-List: contact dev-help@beehive.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@beehive.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@beehive.apache.org>
List-Post: <mailto:dev@beehive.apache.org>
List-Id: <dev.beehive.apache.org>
Reply-To: "Beehive Developers" <dev@beehive.apache.org>
Delivered-To: mailing list dev@beehive.apache.org
Received: (qmail 90607 invoked by uid 99); 19 Jan 2006 22:37:03 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Jan 2006 14:37:03 -0800
X-ASF-Spam-Status: No, hits=2.1 required=10.0
	tests=RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS_SOCKS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of richfeit@gmail.com designates
 64.233.184.197 as permitted sender)
Received: from [64.233.184.197] (HELO wproxy.gmail.com) (64.233.184.197)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Jan 2006 14:37:02 -0800
Received: by wproxy.gmail.com with SMTP id i23so416286wra
        for <dev@beehive.apache.org>; Thu, 19 Jan 2006 14:36:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=Km4jzW2z2TsLFL7FP5E34lJde78vq/r/Gy6zP+oUrDlETfukAzHC3VgL3hp9rh0KkOSrf+mH3Xnsj3eWAyKMeiKYqe9vAL+IPArz5jOQT7Dz4j5MuxD39UBqtTCh0EuEtqHxLVhc+n41HfT7Sc6EK9XfjpCltilEdNljJ9CINlE=
Received: by 10.54.66.4 with SMTP id o4mr1416125wra;
        Thu, 19 Jan 2006 14:36:41 -0800 (PST)
Received: from ?10.1.1.216? ( [72.16.188.244])
        by mx.gmail.com with ESMTP id d7sm1234175wra.2006.01.19.14.36.36;
        Thu, 19 Jan 2006 14:36:37 -0800 (PST)
Message-ID: <43D01473.3090909@gmail.com>
Date: Thu, 19 Jan 2006 15:36:35 -0700
From: Rich Feit <richfeit@gmail.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Beehive Developers <dev@beehive.apache.org>
Subject: Re: NetUI BVT - StrutsMerge test4 question
References: <ba6911de0601182204h6a9a4806t2bd60fde6f35dba3@mail.gmail.com>
In-Reply-To: <ba6911de0601182204h6a9a4806t2bd60fde6f35dba3@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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
>
>