Re: EO Object Lifespan / Editing Context (Goodbye Bill)
Re: EO Object Lifespan / Editing Context (Goodbye Bill)
- Subject: Re: EO Object Lifespan / Editing Context (Goodbye Bill)
- From: email@hidden
- Date: Fri, 18 Jul 2003 9:36:52 CDT
- Priority: 3 (Normal)
[demime could not interpret encoding binary - treating as plain text]
On Thu, 17 Jul 2003 22:40:57 -0400 Arturo Pirez wrote:
> The pattern above fails for frameworks (at least under 4.5). That is,
> when you customize the Session object to
> include these sorts of things and then break up an application into
> frameworks you'll find that the frameworks
> won't know about the Session instance variables you added. In that
Interestingly, if the information really does belong in the Session,
framework code can store
info in the sessoin with:
session().setObjectForKey( someData, "someKey");
session().objectForKey( "someKey" );
These are methods on the standard WOSession, and will work on any
WOSession, no need
to make assumptions about a custom subclass.
Just make sure the String you are using for a key isn't going to be used
by any other code
that might be included in the application or other frameworks, which you
don't even
neccesarily know about when you are writing the code. I often prefix the
name of the client
class onto the key, as a way of being sure I won't get any keyname collisions.
I've rarely needed to use this design---in fact, I rarely find it
appropriate to store data in the
Session at all, usually I just pass it from page to page. But when I do
need framework code
that stores information in the session, the above pattern is invaluable.
Good thinking
whatever engineers originally put those methods in WOSession.
--Jonathan
> case, you have to do the
>
> > SomeComponent nextPage = (SomeComponent) pageWithName("SomeComponent");
> > nextPage.setSomeValue( myOwnSomeValue );
>
>
> I personally prefer the following idiom instead (same difference, as
> they say)
>
> WOComponent nextPage = pageWithName("SomeComponent");
> nextPage.takeValueForKey( myOwnSomeValue, "someValue" );
>
>
> because it makes it easier to "borrow" code and move things around. I
> believe I'm aware of all the
> downsides.
> -------
> WebObjects in Philadelphia. You want a cheesesteak with that?
_______________________________________________
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.