You could get what you're doing now running using ArrayList as a form property. and then nest your hibernate Beans in there until such a time as you have enough time to change things .


<form-bean name="creditCostsForm" type="...">
        <form-property name="creditCosts" type="java.util.ArrayList" />


DyanaActionForm theForm = (DynaActionForm) form;


List costList = (List) theForm.get("creditCosts");

.. add your beans into the list and a new one if you so wish.

theForm.set("creditCosts",costList);

..


<html:form action="/save.do"> <logic:iterate id="item" name="creditCostsForm" property="creditCosts">

On 22 Mar 2004, at 11:30, Joe Hertz wrote:


In a word, "Doh"!


I'm using a DynaForm, and frankly, wanted this as a form property, but
well...Let's just say I was brainwashed by my previous paradigm.

Rather than using a List in the dynaform, I'm going to create a bunch of
String[] properties. Not even so much for the decoupling aspect (which isn't
AS big of a deal as it usually is because this JSP by definition is going to
be a maintenance screen for this particular Object regardless) but I'm going
to need sic the validator onto the fields on the screen, so string arrays it
is.


JOC, is it kosher for me to be setting the form properties in the Action that
leads into the JSP, or should I be doing it somewhere in the form's class.
(This seems like a basic question, but in the home grown framework I was
raised on, this concept was a bit of a no-no. Much like chaining actions is
in Struts.


Thanks for your help.

-Joe

-----Original Message-----
From: Mark Lowe [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 4:20 AM
To: Struts Users Mailing List
Subject: Re: There *has* to be an easy way to do this...


Your using OM objects and stuffing them into your view but this should still work anyhow.

CreditCost newCost = new CreditCost(); creditCostList.add(newCost);

Have an add action do the above, I assume you're scoping to
session as
you're iterating through a scoped array/list and not a form property.

IMO you want to have things looking more like this

<logic:iterate id="item" name="costsForm" property="creditCosts">

and in your actions

CreditCostsForm theForm = (CreditCostsForm) form;

List costList = theForm.getCreditCosts();

costList.setCrediCost(costList.size(),new CreditCostForm());

Notice CreditCostForm not CreditCost from you OM, although you could
get away with using CreditCost as a form property it will make life
harder if you ever want to decouple the web and model tiers.

If you cant be arsed having webtier beans/forms then perhaps
use a map
or dynabean to do the same thing.

On 22 Mar 2004, at 08:42, Joe Hertz wrote:



I have a simple iterate in a piece of JSP (snippet follows) that
provides an
interface inside of an HTML table to modify items that came
out of the
database.

What I want to do is provide an extra row or two for new items to be
inserted
into the database. Short of embeddeding scriptlet code to
generate the
property identifiers (which are in a List), is there a good
way to do
this?

Basically the ideal answer would be to have a way to tell
logic:iterate to go
for an extra round, with the tag being smart enough to "do the
needful".

tia

-Joe

<table border=1 cellpadding=1>
<tr>
<th>Minimum Purchase</th>
<th>Cost Per Credit</th>
<th>Begin Date</th>
<th>End Date</th>
</tr>
<logic:iterate id="item" name="creditCost" indexId="index"
type="bb.hibernate.Creditprice"> <tr><td><html:hidden name="item"
property="id" indexed="true" /> <html:text maxlength="5"
name="item"
property="minPurchase" size="5" indexed="true" /></td>
<td><html:text maxlength="5" name="item"
property="creditCost" size="5"
indexed="true" /></td>
<td><html:text maxlength="10" name="item" property="beginDate"
size="10"
indexed="true" /></td>
<td><html:text maxlength="10" name="item"
property="endDate" size="10"
indexed="true" /></td></tr>
</logic:iterate>



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



Reply via email to