I just realized something I could do. The jsp I forward to has a tiles
definition like the following:
<tiles:insert definition=".popupLayout">
<tiles:put name="pageTitle">
<bean:message key="my.message.key.to.page.title"/>
</tiles:put>
<tiles:put name="formId" value="maintenanceForm"/>
<tiles:put name="formAction" value="/postaction"/>
<tiles:put name="body" value="/pages/test-body.jsp" />
</tiles:insert>
The test-body.jsp then has the following statements at the top:
<bean:define id="formBean"><tiles:getAsString
name="formId"/></bean:define>
<bean:define id="actionBean"><tiles:getAsString
name="formAction"/></bean:define>
Then when I'm working with my form:
<html:form action="<%=actionBean%>">
<html:hidden name="<%=formBean%>" property="myField1"/>
<html:text name="<%=formBean%>" property="userName" size="25"
maxlength="32" />
<html:submit><bean:message
key="global.forms.button.submit.label"/></html:submit>
</html:form>
I can also use the statement:
<c:out value="${formBean}"/>
Therefore, if I create my action form classes as such:
public class CheckboxPagedForm extends ActionForm
public class MaintenanceForm extends CheckboxPagedForm
I can define multiple action mappings in struts-config.xml like:
<action
path="/maintMfrLookup"
type="com.setech.catalog.CatalogMaintenanceAction"
name="maintenanceForm">
<forward name="success" path="/pages/catalog/mfrlookup.jsp"/>
</action>
<action
path="/maintMainCategoryLookup"
type="com.setech.catalog.CatalogMaintenanceAction"
name="maintenanceForm">
<forward name="success"
path="/pages/catalog/maincategorieslookup.jsp"/>
</action>
Each of the above two JSPs referenced in the forwards would include the same
base BODY JSP page, thus when I need to make changes to how these popups
work, I only make the change in 1 place and its applicable to all.
Another alternative to having multiple action mappings would be to derive my
action from a dispatch action instead of an action forward thus giving me
only 1 mapping with multiple forwards which may make more sense.
Anyone have any thoughts on this approach?
----- Original Message -----
From: "Linck, Ken" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, June 17, 2004 3:08 PM
Subject: RE: Forms/JSP
I have never seen any good strategy crossing oo-concepts like
inheritance and user interface patterns. I always end up back at the
containment approach(Breaking your interfaces into smallest re-usable
pieces).
If I had the time I would collaborate with you. If you have some kind
of white paper concept already, I will be happy to read it though and
provide some feedback.
Ken
-----Original Message-----
From: mike [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 2:46 PM
To: Struts Users Mailing List; Struts Users Mailing List
Subject: Re: Forms/JSP
Hello, Chris,
I sent out a note some time back on this saying that I think we should
all collaborate and build something this is new on this issue. This is
a major recurrent issue. The current solutions all "suck" to some
extent either in bloating the session and creating difficulty with
multiple windows, or in requiring too much coding when the MVC
structure, which I believe in "way deeply", is adhered to strictly. I
think something other than the normal scopes for retaining and accessing
data is what is required, i.e. something out-of-the-present box. I
still think that this is necessary, and if there had been a response of
any kind, I would have set about working collaboratively on it. I guess
this is a time to reassert the need and to ask if anyone on the list
would like to collaborate. I think that someone going off on their own,
whjich I will do eventually if no one responds, is less advisable
because the collective wisdom of the list is helpful. This is a good
issue, I think, for the dev list as well.
Specifically on your issue, there is a simple answer depending on what
your question is. You can always reference a super class from a
subclass, if that is the question. If the question is whether you can
reference another instance of the superclass, the answer is that you can
if you have parked it somewhere and have access to it. Is this a fair
answer, or am I misunderstanding you?
Michael
At 11:32 AM 6/17/2004, Chris Cranford wrote:
>Any thoughts anybody?
>
>----- Original Message -----
>From: "Chris Cranford" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Sent: Thursday, June 17, 2004 12:17 PM
>Subject: Forms/JSP
>
>
>I have created a form hierarchy as follows:
> public class CheckboxPagedForm extends ActionForm
> public class MaintenanceForm extends CheckboxPagedForm
>
>I did this because there are form-specific attributes for the
>maintenance form, but we have multiple forms which are going to need to
>leverage the paged checkbox form stuff. In the maintenance.jsp I need
>to open a new window and work with only the data in the base class
"CheckboxPagedForm".
>
>What I'd like to do is have this JSP common so that no matter what
>extended form calls it, it gets the data, permits the user to make
>changes to the data and then when the window is closed, the data gets
>sent back to the "maintenanceform" with a parameter that tells it to
update itself,etc.
>
>Right now I had to write my JSP so that I checks like:
>
><logic:present name="maintenanceForm">
> .. do maintenance form logic
></logic:present>
><logic:present name="searchForm">
> .. do search form logic
></logic:present>
>
>Is there not a way that no matter what the extended form is, since both
>are "checkboxpageform", I can just reference that?
>
>Thanks
>Chris
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
