Hi Mark,
 
Your app seems similar to something taht we are doing
Could you enclose the same action and form class i fpossibel...
Thansks!

Mark Lowe <[EMAIL PROTECTED]> wrote:
This is just my opinion but for editor style forms lookupdispatchaction 
is the dogs. Especially if you want to avoiding scoping forms to 
httpsession. The classes are longer but less.


On 19 Mar 2004, at 12:55, Brendan Richards wrote:

>> prepopulating is exactly what i would do, just in an action not in the
>
>> action form.
>
> Ah! That makes perfect sense. Keep the action form only for temporarily
> holding the data we're input/outputting and do all work in the actions.
> If you want to edit have a 'viewEdit' action that populates the Action
> form and displays. Then to save, have a 'submitEdit' action.
> Sounds like a much better way of going about it...
>
> Thanks.
>
> -----Original Message-----
> From: Mark Lowe [mailto:[EMAIL PROTECTED]
> Sent: 19 March 2004 11:41
> To: Struts Users Mailing List
> Subject: Re: Database backed forms
>
>> How would you suggest implementing view/edit functionality without
>> pre-populating action forms?
>
> prepopulating is exactly what i would do, just in an action not in the
> action form.
>
> Sure you can shoe-horn checking your system state constantly but just
> seems complicated. Surely some transaction management when you come to
> insert/update/delete data should do the job.
>
>> 2) I've extended DynaValidatorActionForm to provide a reset()
>> implementation. If required, the actionForm's properties are populated
>> from the backend model.
>
> If you've got that far then the question of dynamically generating
> fields shouldn't be a problem.
>
>
> On 19 Mar 2004, at 11:58, Brendan Richards wrote:
>
>> I've seen many posts on "Not pre-populating action forms". This seems
>> to
>> be a design decision as action forms are only for validating input.
>>
>> However, in most applications I write I don't want to only input data
>> but to view and edit existing data as well. For me ActionForms seem to
>> be the best way to code an input/output layer between the browser and
>> the backend.
>> In order to view and edit existing data, the action form needs to
>> pre-populate its data from the backend before displaying the form.
>>
>> How would you suggest implementing view/edit functionality without
>> pre-populating action forms?
>>
>> I've coded pre-populating action forms in the following way:
>> 1) I've got session objects to maintain my current system state
>> (whether
>> I'm looking at an extisting object or creating a new one)
>> 2) I've extended DynaValidatorActionForm to provide a reset()
>> implementation. If required, the actionForm's properties are populated
>> from the backend model.
>>
>> -----Original Message-----
>> From: Mark Lowe [mailto:[EMAIL PROTECTED]
>> Sent: 19 March 2004 10:41
>> To: Struts Users Mailing List
>> Subject: Re: Database backed forms
>>
>> If there's talk of having action forms populated by themselves then I
>> wouldn't.
>>
>> For example you want to create a new record, to instantiate a new form
>> bean you'd perhaps have to save a record to the db, and all this
> before
>>
>> the user decides what s/he wants to do with it.
>>
>> niall wrote some classes that could be useful.
>>
>> http://www.niallp.pwp.blueyonder.co.uk
>>
>>
>>
>> On 19 Mar 2004, at 11:05, Brendan Richards wrote:
>>
>>> I guess your first place to look would be DynaActionForm - this base
>>> class dynamically creates FormAction objects setting the properties
>>> from
>>> the struts-config file.
>>>
>>> http://jakarta.apache.org/struts/api/org/apache/struts/action/
>>> DynaAction
>>> Form.html
>>>
>>> DynaValidatorActionForm adds validator support to this.
>>>
>>> Perhaps you could extend this class to add your own methods for
>>> specifying form properties on the fly.
>>>
>>> The key function seems to be initialize(FormBeanConfig) -
>>> FormBeanConfig
>>> "represents the configuration information of a element in
>> a
>>> Struts configuration file".
>>>
>>> So create a FormBeanConfig object in code to represent the dynamic
>> data
>>> you want and then initialize a DynaActionForm with this object.
>>>
>>> Add properties to FormBeanConfig with addFormPropertyConfig.
>>>
>>> That sounds like a realistic starting point...
>>>
>>> Anyone else have any ideas suggestions or corrections?
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Melonie Brown [mailto:[EMAIL PROTECTED]
>>> Sent: 18 March 2004 18:30
>>> To: [EMAIL PROTECTED]
>>> Subject: Database backed forms
>>>
>>> I have written a very rough website page content
>>> management system using Struts and OJB. (The goal
>>> being to allow end users to modify content without
>>> having to know anything about Struts or the code
>>> behind the pages.)
>>>
>>> That's working all well and good, but now they want to
>>> be able to create forms "on the fly".
>>>
>>> I would like to store all of the form components and
>>> validation in the database as well, but I'm not sure
>>> how to represent that in Struts (since there's no
>>> ValidatorActionDatabaseForm).
>>>
>>> I would appreciate any advice, tips/techniques, or
>>> gotchas that you guys could provide.
>>>
>>> __________________________________
>>> Do you Yahoo!?
>>> Yahoo! Mail - More reliable, more storage, less spam
>>> http://mail.yahoo.com
>>>
>>> ---------------------------------------------------------------------
>>> 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]
>>
>
>
> ---------------------------------------------------------------------
> 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]
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam

Reply via email to