Re: How to Retrieve Session User?
Re: How to Retrieve Session User?
- Subject: Re: How to Retrieve Session User?
- From: Mike Schrag <email@hidden>
- Date: Tue, 10 Apr 2007 09:58:13 -0400
You may want to make your life slightly easier and just set Forums to
Cache in Memory rather than use the shared editing context, but
that's just me. SEC gives me the willies. There's a section of the
wikibook that talks about the implications of setting Cache in
Memory, but given you problem description, it's probably OK. The
willies I have are purely my own deadlock-fear-induced willies.
Others may be entirely willy-free. YMMV.
ms
On Apr 10, 2007, at 9:53 AM, Fred Shurtleff wrote:
I mis-spoke re the Topics entity - only the Forums entity is
fetched into the SharedEditingContext; and you are correct - the
Topics' posts attribute is changing for each Reply made.
Thanks
David Avendasora wrote:
See below
On Apr 6, 2007, at 11:31 AM, Fred Shurtleff wrote:
SEE BELOW
Art Isbell wrote:
On Apr 5, 2007, at 4:13 PM, Fred Shurtleff wrote:
Also I know what you are saying about the use of the primary
key use and EOF discouraging its explicit usage; but this does
not appear to be such a bad transgression in that it is not
ever displayed nor used as a user manipulated attribute.
How is it a form value then? Is it written to a hidden text
field?
The topicID value has to come from somewhere. Maybe it's a
foreign key in an object that your Java code already knows
about. In any event, it seems likely that you can refer to the
Topic object that topicID represents as a relationship value
from a "parent" object or in some way that avoids using the
primary key explicitly.
This is a 3 entity situation driving from parent entity(Forums) >
child/related entity(Topics) > final entity(Posts/Replys), and
uses the primary key to link/drill down thru these entities. The
user never sees/uses this primary key. Behind the scene each page
has a link bound to a DA key (?forumID = forumID;) where the
component class has a key retrieval method as follows:
public Integer forumID() {
NSDictionary primaryKey = EOUtilities.primaryKeyForObject
(forum.editingContext(), forum);
return (Integer) primaryKey.valueForKey("forumID");
Next the DA methods uses the passed key to fetch the related
Topics and stuff them into the response component as follows:
public WOActionResults topicsAction() {
WOComponent nextPage = pageWithName("ForumTopics");
Number forumID = request().numericFormValueForKey("forumID",
new NSNumberFormatter());
EOEnterpriseObject forum =
EOUtilities.objectWithPrimaryKeyValue(WOApplication.application
().sharedEditingContext(), "Forum", forumID);
Are you using a Direct Action so you can book-mark the
"ForumTopics" page? If so, I guess using the primary key as a URL
parameter is a correct-enough way to do it, but you also stated
that the user never sees/uses this key. I would suggest coming up
with a more human-readable, yet still-unique attribute and put
that in the URL so a user might have some clue as to where the URL
was taking them by just looking at it.
If you don't require the ForumTopics page to be bookmarkable, then
I would suggest not using a Direct Action. It is much easier to
simply pass the object between the pages instead of passing only a
reference that then requires another lookup.
WOComponent nextPage = pageWithName("ForumTopics");
nextPage.setForum(forum);
return nextPage;
in the ForumTopics component you would have:
public EOEnterpriseObject forum;
public void setForum(EOEnterpriseObject requestedForum) {
forum = requestedForum;
}
Number index = request().numericFormValueForKey
("displayBatchIndex", new NSNumberFormatter());
// set variables
nextPage.takeValueForKeyPath(forum,
"topicsDisplayGroup.masterObject");
if (index != null) nextPage.takeValueForKeyPath(index,
"topicsDisplayGroup.currentBatchIndex");
return nextPage;
As you can see there is a sharedEditingContext used I presume
based on the assumption that the Forums and Topics tables are not
very dynamic, and uses localized version of the shared context to
perform edits.
But the Topic OBJECT (not table - you are still thinking in terms
of the database) is changing ALL THE TIME. Every time a user
submits a Post/Reply, you must update the Topic OBJECT'S posts/
replys() to-many relationship. This doesn't have any impact on the
Topic TABLE in the database, but it does impact the Topic OBJECT.
I don't think that this is a proper use of a sharedEditingContext
at all.
As far the questionable use of the primary key, it looks to me as
simply an example of using built-in WO methods to filter an EC
using primary keys - not so bad.
Re:EOSharedEditingContext it is 'crossed out' in the Eclipse
IDE and shows a context message indicating this is a deprecated
method. But then the code you see was written in 2002 for a
demo app in "WebObjects Developer's Guide"(SAMS Publisher).
Shared objects can be tricky to use correctly. Failure to
do so can result in deadlocks and other problems. The best
description I have found is at <http://developer.apple.com/
documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/
System/Documentation/Developer/WebObjects/DeltaDoc/
EOF.html#CBGCHAIA>. It's a pretty quick read that can save much
grief later.
Thanks for the link :-)
Aloha,
Art
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40comcast.net
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:
40avendasora.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:
40mdimension.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