Re: new/update form patterns
Re: new/update form patterns
- Subject: Re: new/update form patterns
- From: 時期 精霊 <email@hidden>
- Date: Fri, 27 May 2005 23:17:16 +0900
Hello,
I don't know if this is the best way or not, but I'll just explain my
feeling.
I always insert object in an eo as soon as I have done an (init (so
the object can be saved in the db without throwing a not null
exception)).
But, sometimes, I need the object not being in an editing context.
But then, when I save, I do:
if(myObject.editingContext() == null)
myec.insertObject(myObject);
I need this sometimes to allow user cancel. But as some of you
suggest, I'll try to use child editing context as it seem better.
Anyway, I do not recommend having EO flying around without an editing
context, it gave only pain (relationship...), and again, I use it
only when I have special behavior to do.
Then, for direct binding, it depend of what I have to do.
Normaly, I bind them directly if I use the NSValidation mechanism to
validate them. But sometimes, I need indirect binding (for uploading
files for example, don't bind an eo directlytoa WOForm upload, for
advice). But I try to not be fancy with my coding, I mean I'm not
going to use an nsdictionary, performing validation in a save method
and then on another page, implementing an other mechanism for an
other entity. But as I old ASM and C coder, I'm very strict, and I
got old rules like not having method longer than 25 lines or be very
cautious about the "Do not repeat yourself" and "use the same wheels
for all cars, if you have trucks, then put trucks wheels to your cars".
So, as you read before, my C experience tell me to use name() and not
getName().
I really prefer to do:
private String _name;
public String name() {
return _name;
}
public String setName(String n) {
_name = n;
}
Also, I like to names my private with _ if they are public accessor.
And at last, as I saw on the list, some people play with tapestry and
hibernate/cayenne.
I know this can be OT, but I tried for months, but all I was able to
do was the same result as WO but with more time.
I really wanted to have a cross plateform eclipse with all good java
stuff. But I can't handle it, I have a C way of thinking, and xCode
is really better for me,
I mean I don't like all those fancy stuffs in Eclipse that make your
code blink and so on.
But I agree that Eclipse is a wonderful tool for Java.
But again, if you can do what you want with WO, stay with it. Apple
will definitely upgrade it, they need it.
Regards
Kuon
On May 27, 2005, at 4:52 AM, Mike Schrag wrote:
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:
40goyman.com
This email sent to email@hidden
_______________________________________________
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