Re: OT : Coding Standards (was New WebObjects 15 Minute Tutorial in Quicktime)
Re: OT : Coding Standards (was New WebObjects 15 Minute Tutorial in Quicktime)
- Subject: Re: OT : Coding Standards (was New WebObjects 15 Minute Tutorial in Quicktime)
- From: "Jonathan 'Wolf' Rentzsch" <email@hidden>
- Date: Sun, 28 Mar 2004 21:46:40 -0600
Owen McKerrow, email@hidden, wrote:
>I just watched the Jonathan's 15 min Intro to WebObjects ( Great work
>John, keep it up ). However I did notice that he does things a little
>differently to how I've seen WO taught before. These being :
>1) He didn't make a java class of his Entity, he just imported the
>EOModel
Yes, generating Java code is wonderfully optional in WebObjects/EOF. In
my experience, Java code generation buys you two things:
1. A place to put your EO's logic.
If all you're doing in your logic is populating default values in your
EO's attributes, there are alternative places you can extend D2W+WOF+EOF
to make this non-entity-specific. I find most of my custom EO "logic" is
setting these default values, so replacing a bunch of entity-specific
Java code with a framework extension can often completely mitigate the
need for code generation altogether.
2. Type-safety/convenience.
I seem to have a mental threshold. When coding WOWebLog, I had no problem
writing ((EOEnterpriseObject)entry).takeValueForKey( newValue,
"viewCount" ). It's just data.
But when doing an ecommerce site, I prefer the compile-time locked-down
safety of entry.setViewCount( newValue ). Sure, it ends up being a simple
wrapper over the same call, but I really like the idea of an
inappropriate model change (say yanking that attribute or changing its
type) will cause a compilation failure when the app is rebuilt. Plus I'm
a sucker for transactional semantics of business objects. That is, you
must supply to proper criteria to create the business object, and the
business object will never allow itself to be put into an inconsistent
state. That means I go assertion crazy inside the entity java code, which
definitely means Java code generation (with EOGenerator backing me up by
providing an implementation of the Generation Gap pattern).
The video needed neither of these, and would have added complexity to the
tutorial, so I chose to skip it.
>2) He used instances of String's inside the Main.java file to store the
>values typed into the form and then in the function thats called by the
>submit button, he makes a new instance of his EOEnterpriseObject
>entity and fills in the values with takeValueForKey(newTitle, "title").
>The bit thats different here is making a new instance of
>EOEnterpriseObject and not an instance of the Entity itself, and then
>using takeValueForkey as opposed to setTitle() method that would be a
>part of the Java class ( if he had made it ).
I considered both using a nested/peer editing context+new uncommitted EO
and using a mutable dictionary+takeValuesFromDictionary for
creating+committing a new EO based on the user's input. In the end, I
chose the ivar-per-attribute example because it was the simplest to
explain, and had the least magic. I imagined myself as a bronze-age
programmer, and I felt very reassured seeing those attributes being
populated manually.
>3) When making a NSArray for the repetition, he makes a method that
>simply returns EOUtilities.objectsForEntityNamed(), i.e. he doesn't
>make an array variable in Main, he just returns the results from the
>DB.
Yeah, that's fine if you don't mind excessive round-trips to the database
:)
>Know I know there isn't much difference between what Im used to and how
>he has done things and Im sure lots of otherways people build projects,
>but it does raise the question of what is best practice. As he says on
>his website the idea of the video is to allow you to look over the
>shoulder of someone i.e. "watching a pro use WebObjects to build an
>application"
Ugh, that wording is already coming back to haunt me... :)
>1) Jonathan, is this your normal way of doing things or did you change
>slightly for this simple example ?
I changed things. 15 minutes is awfully short time to build a working
app, while explaining what you're doing, and purposely not using all the
magic at your disposal.
Bottom line: the current short video was not 'best practices', it was
'show off WebObjects in terms a stone-age/bronze-age programmer could
possibly grok'.
| Jonathan 'Wolf' Rentzsch http://rentzsch.com
| Red Shed Software http://redshed.net
| "better" necessarily means "different"
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.