RE: new/update form patterns
RE: new/update form patterns
- Subject: RE: new/update form patterns
- From: <email@hidden>
- Date: Fri, 27 May 2005 10:01:10 +0200
- Thread-topic: new/update form patterns
Hi!
I do create the EO and insert it into an editing context dedicated to the task of creating and eventually saving that EO. That editing context is peer to the default editing context. Actually all my edits happen in dedicated peer contexts. The session default is used for reads only. This eliminates the risk of having a pending change hang around.
Doing so I get the default values set in awakeFromInsertion() in my initail form.
I however do not bind the EO directly to the form. I transform the EO into a dictionary of strings. Using key-value coding I first extract a set of values I want in the form. Then again using key-value coding as well as formatters I derive a string representation for each value. The form is bound to a _clone_ that dictionary of values.
After the form is submitted I compare the modified clone to the original dictionary. Only for the changed values I do a reverse transformation from String to object or EO value. This is done by first parsing the string using a formatter and the possibly calling a fetch specification.
This has the following advantages:
- I can map to-one relationships to a plain form
- I only set actually modifed values on the EO
- I do not lose precision on a value which internally had a higher precision than what the form shows
- I handle parsing exceptions in code. For one this allows keeping the unparsable value in the form
Pierre
-----Original Message-----
From: webobjects-dev-bounces+pierre.bernard=email@hidden
[mailto:webobjects-dev-bounces+pierre.bernard=email@hidden]On
Behalf Of Mike Schrag
Sent: Thursday, May 26, 2005 9:52 PM
To: webobjects-dev Development
Subject: new/update form patterns
I'm curious what pattern people use for "new-EO" forms -- that is,
when you have a form to fill in the initial values of a new EO that
the user has requested to create. For instance, do most of you
create the EO up-front and attach the form fields directly to the
attributes of the EO, or do you clone the fields into the WOComponent
and attach to those, then move them into a new EO in the "save"
action? The problem with the first route is that if someone
navigates away, you've got an empty EO inserted into the EC and the
user doesn't realize that it's still sitting in their session, but
it's obviously nicer because you can just wire up directly to the EO
attributes and you don't have to keep the Component and the EO fields
in-sync (well, other than in the html/wod).
While I'm soliciting methodologies, I'm curious how many of you use
the ObjC/WO naming for accessor methods vs the JavaBeans convention
(i.e. do you use "name()" or "getName()"). WO has made me very
schizophrenic wrt my get method naming. I feel urges to name them
like WO/ObjC now and I don't know who is on the dark side in this
battle :) The ObjC-style has definitely grown on me, though.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
**********************************************************************
This email and any files transmitted with it are intended solely for
the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender
of this message. (email@hidden)
This email message has been checked for the presence of computer
viruses; however this protection does not ensure this message is
virus free.
Banque centrale du Luxembourg; Tel ++352-4774-1; http://www.bcl.lu
**********************************************************************
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden