From: "Jerry W. Walker" <email@hidden>
Date: Wed, 27 Jul 2005 11:07:57 -0400
To: Darich Runyan/OMNI INFOSEC LTD HQ <email@hidden>
Cc: WebObjects Development <email@hidden>
Subject: Re: Fetch Spec Misunderstanding
Hi, Darich,
On Jul 27, 2005, at 9:20 AM, Darich Runyan/OMNI INFOSEC LTD HQ wrote:
Thanks for the ideas. I fooled around with this some and was never
able to
get it to work. Maybe I am going about this the wrong way. Is
there a
better way to obtain just a single column from the database that is
just the
values and not the key/value pair?
Thanks,
Darich
Yes, use a SQL solution. So long as you're thinking in terms of
columns in a relational database and their values, you're thinking in
the terms around which SQL, as a language, is wrapped. I'll
paraphrase a message I posted on another thread regarding this same
issue.
The question is framed from the perspective of "I have a table of
rows with which I want to do something, now how do I get WO to help
me do that thing to my table in the same way I've always done these
things with SQL?"
Experienced WO developers would think instead of the object graph
that we are manipulating in our object oriented Java application
rather than the rows we have stored in our relational database.
Rephrasing the question, "I have a set of objects 'O' with an
attribute 'a'. How do I obtain the value of that attribute for each
of those objects?"
The obvious answer to your original question is dump WebObjects. It's
a poor technology for doing pure SQL manipulation. Just issue a SQL
"select myColumn from myTable;" and live with the rest of SQL's
shortcomings as an enterprise application development technology.
On the other hand, if you want to use WebObjects, you'll find it much
easier to think in the terms in which it frames the questions, namely
classes, objects, object graphs and object oriented concepts. In
these terms, the database is more appropriately thought of as an
"object store", or place to hold my objects rather than a relational
database. In these terms, you'll find it much easier to simply fetch
the objects from the database and extract their values as you would
the values of any other objects.
Perhaps those objects have already been cached and we don't need to
fetch raw rows. That is, if they've already been fetched earlier for
some other operation, their snapshots are already cached in memory
and we would have been doing a redundant fetch rather than
economizing.
Failing those possibilities, I would still write the fetch without
referencing raw rows and get it to work. Then, if the result is
clearly taking too long or requiring too much memory, I would profile
where the delays are occurring or the memory is being consumed and,
if in database fetches, then would start to consider raw rows. The
point being that referencing raw rows is a last resort rather than a
way to move into the comfort zone of old habits with result sets.
So what are the down sides to just moving immediately to raw rows?
* a missed opportunitiy to get used to the WO way
* the short circuiting of several elegant features built into WO
to help one deal with objects rather than rows
* potential extra database accesses to objects already cached in
memory
* the higher probability of weak object oriented design built up
from this raw row decision
If you take the natural WebObjects route and stop trying to get a
single value out of a table, the advice I gave in my earlier response
still holds in general. Except, instead of dealing with
NSDictionaries, you will be dealing with Enterprise Objects, or EOs.
The code sample I supplied would look more like this, in that case:
Presume that myFetchSpec exists, that the class name for the EO that
you've persisted in that table of the database is MyObject, that the
name of the element of that class whose value you are interested in
is myAttribute, and that you've fetched an array named myObjects as
follows:
NSArray myObjects =
myEditingContext.objectsWithFetchSpecification(myFetchSpec); //
Fetches instances of MyObject
NSDictionary anObject; // Iteration variable
NSDictionary selectedObject; // used to hold selected element
from WOPopUpButton
Now, set up your WOPopUpButton with the following bindings:
list = myObjects;
item = anObject;
displayString = anObject.myAttribute
selection = selectedRow
You'll find this easier, in general, than working with the raw rows,
because you can do the bindings visually and directly in WebObjects
Builder rather than having to type them in as you would have to do
with the NSDictionaries resulting from a raw rows fetch. The
WOPopUpButton should display what you want.
Good luck with WebObjects.
Best regards,
Jerry
From: "Jerry W. Walker" <email@hidden>
Date: Wed, 27 Jul 2005 00:45:27 -0400
To: Darich Runyan/OMNI INFOSEC LTD HQ <email@hidden>
Cc: WebObjects Development <email@hidden>
Subject: Re: Fetch Spec Misunderstanding
Hi, Darich,
Raw fetches return NSArrays of NSDictionaries, of which, an
EOMutableKnownKeyDictionary is probably a subclass (I'm not really
familiar with it, per se).
So long as it's an NSDictionary, you should simply be able to bind
your pop-up button to the key name of the key-value pair you
retrieved and it should display only the value based on that
key. The
fact that each of your dictionaries in the array contains only one
key-value pair, notwithstanding.
So, presume that myFetchSpec exists and that you've fetched an
array
named myObjects as follows:
NSDictionary aRow; // Iteration variable
NSDictionary selectedRow; // used to hold selected element
from
WOPopUpButton
myFetchSpec.setRawRowKeyPaths(new NSArray
( "myAttribute" ); // sets the keypath for fetching raw rows
with
only one key-value pair
NSArray myObjects =
myEditingContext.objectsWithFetchSpecification(myFetchSpec); //
Fetches raw rows as specified above
Now, set up your WOPopUpButton with the following bindings:
list = myObjects;
item = aRow;
displayString = aRow.myAttribute
selection = selectedRow
Replace "myAttribute", of course, with the name of the attribute
that
you want displayed. The WOPopUpButton should display what you want.
The above was done from memory, so may contain errors.
Regards,
Jerry
On Jul 27, 2005, at 12:14 AM, Darich Runyan/OMNI INFOSEC LTD HQ
wrote:
I found out a bit more. Looks like the Raw Fetch is returning a
EOMutableKnownKeyDictionary which is not quite what I want. Seems
that I
need to be using a formatter. Is there any good docs on how to
set
one of
these up?
Thanks,
Darich
From: Darich Runyan/OMNI INFOSEC LTD HQ <email@hidden>
Date: Tue, 26 Jul 2005 23:41:05 -0400
To: WebObjects Development <email@hidden>
Subject: Fetch Spec Misunderstanding
All,
This solution to the problem I am having should be easy yet I am
unable to
find an answer. Up until this evening my application has only
allowed users
to input data and return complete sets via WORepetitions. This
works
nicely. I now have a request to provide just portions of a
certain tables,
specifically a single column from each that will then be used to
populate a
WOPopUpButton. To do this I have created a Raw Fetch
Specification in the
EOModel that returns just the column that I want from the entity.
This
almost works fine except it returns the values in the following
format:
{columnName = "value";}
So my PopUpButton gets populated with a bit of extraneous
information. Do I
have to parse this prior to creating the WOPopUpButton in
order to
only have
the values added to it or is there some way to have the fetch
spec
just
return the value sans the column name?
Thanks,
Darich
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40omni-
infosec.co>
m
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:
40codefab.com
This email sent to email@hidden
--
__ Jerry W. Walker, Partner
C o d e F a b, LLC - "High Performance Industrial Strength
Internet Enabled Systems"
email@hidden
212 465 8484 X-102 office
212 465 9178 fax
--
__ Jerry W. Walker, Partner
C o d e F a b, LLC - "High Performance Industrial Strength
Internet Enabled Systems"
email@hidden
212 465 8484 X-102 office
212 465 9178 fax