Re: Where to set display group bindings i java-file
Re: Where to set display group bindings i java-file
- Subject: Re: Where to set display group bindings i java-file
- From: Jean-François Veillette <email@hidden>
- Date: Fri, 02 Dec 2005 15:58:45 -0500
Hi Micky,
I am new to Webobjects and have no knowledge of Java. I learned C++
many years ago and have done some C and a lot PHP since then. So then
I could not get the DisplayGroup binding to work I became frustrated
and searched the internet for another solution and found some code
that worked. I am not realy used to object oriented programming or
thinking to this degree. I guess I do not care about what knows
what... or I am not aware of it anyway... ;) Your example makes sense
though.
Well then, welcome to WebObjects and this wonderful world !
I do beleive you're a brave soul to enter a new world you do not have a
mentor to guide you in, Bravo !
I'll try to explain apropriatly.
However, I used the DisplayGroup binding code that Wolfram suggested
like this:
public void appendToResponse(WOResponse aResponse, WOContext
aContext) {
topic = subjectItem.subjectText();
quoteDisplayGroup.queryBindings().takeValueForKey("emne",
topic);
quoteDisplayGroup.qualifyDataSource();
super.appendToResponse(aResponse, aContext);
}
this assume :
- you have a proper quoteDisplayGroup instanciated
- topic is not null
But it says null pointer exception in the appendToResponse function
when it display the webpage. What is the (WOResponse aResponse,
WOContext aContext) part of the function?
In WO, to generate a page, it goes like this (not exactly, but close
enough for now) :
- the application object receive the request (the url that point to
your app)
- somewhere it's dispatched to the right session object
- first, WO try to takeValuesFromRequest(...) if the request was a
form submit, this is when values are extracted.
- second, WO try to take action from that request : invokeAction(...),
the result of the action is going to be the answer returned for the
http request
- third, most of the time, invokeAction(...) return a WOComponent as
the result of an action, so we have to transform this WOComponent into
an http response (WOResponse), WO does it by invoking
appendToResponse(...) to fill the response object before returning it's
content.
So to answer your exact question, appendToResponse is invoked by WO to
ask your component to generate a response stream in WOResponse, that
will be ultimately returned to the requested client.
I then tried using it like this:
public WOComponent visEmne() {
topic = subjectItem.subjectText();
quoteDisplayGroup.queryBindings().takeValueForKey ("emne", topic);
quoteDisplayGroup.qualifyDataSource();
return null;
}
visEmne() will be called as part of 'invokeAction(...)' (see above),
returning null, mean to WO that it should ask the same component used
to generate the page the last action was somewhere part of.
WO will find that page (context().page()) and ask it to
appendToResponse(...)
I have made a binding from quoteDisplayGroup.queryBinding.emne to a
WORepetion with two strings in it:
Repetition1: WORepetition {
list = quoteDisplayGroup.queryBindings.emne;
item = quoteItem;
}
String1: WOString {
value = quoteItem.author.firstName;
}
String2: WOString {
value = quoteItem.quoteText;
}
When a user clicks a link it uses the function visEmne() as an action.
But no entries from the Quote table show up.
Hmmm ... this is where it doesn't match up !
pretty sure quoteDisplayGroup.queryBindings.emne won't return an
NSArray
I'm not sure what you try to do, but try that instead :
list = quoteDisplayGroup.allObjects();
at least you might be closer to what you are looking for.
- jfv
/Micky
On 02/12/2005, at 19.15, Jean-François Veillette wrote:
Hi Micky,
1 ---
I don't mean to be picky, or to argue about the color of the
wallpaper, but I see something here that leave me perplex ...
The code seem to be in a WOComponent subclasss, and in this « display
» layer, you seem to know a lot about the « persistent » layer.
Such code snippets is commonly found on the net as code sample, and I
give it myself as well, but once you get that code and integrate it
in your own code, you shouldn't leave it that way. Such code should
be divided into proper class, depending on responsibilities, etc.
The « display » layer (com.webobjects.appserver.*) shouldn't know and
deal too much with the logic layer. Well, the problem is not much
that it's knowing something about the logic layer, it's more about it
know more about the logic internals than the logic layer itself !
For example,
// in « display / view » layer (WOComponent subclass) :
public WOComponent visEmne() {
emne = subjectItem.subjectText();
NSArray qts =
Quote.quoteWithSubject(session().defaultEditingContext(),
subjectItem);
quoteDisplayGroup.setObjectArray(qts);
return null;
}
// in the Quote class, part of the « logic / model / business » layer
public static NSArray quoteWithSubject(EOEditingContext ec, Subject
subj) {
NSArray args = new NSArray(new Object[] { subj });
String qualifierString = "(subject=%@)";
EOQualifier qualifier =
EOQualifier.qualifierWithQualifierFormat(qualifierString, args);
EOFetchSpecification fetchSpec = new EOFetchSpecification("Quote",
qualifier, null);
return ec.objectsWithFetchSpecification(fetchSpec);
}
This hide the internals of the relation between a quote and a subject.
This will gradually beef up your « logic » layer to a point where you
could rewrite the same app, using a different gui framework (think
console based tools, web-service front-end or rich java-client), and
use a rich model to drive it.
As you can see, I've also changed the qualifier string, to test
against the subject object, not the subject string it contain. This
allow EOF to do a primary key join instead of a search on a text
column that you might not want to index.
2 ---
If you are building a search page with a form to qualify against some
attributes, you get values in instance variables, and then user push
'search' to see the results.
For such situation, instead of binding the form element to instance
variable, you could bind it directly to the displaygroup.queryMatch
attributes.
For the above example, you could use a WOToOneRelationship component
to qualify on the quote.subject relationship. I do not have sample
code to give you, but I'm pretty sure there is a lot somewhere on the
web (or maybe right on your disk as part of the wo example code).
3 ---
there is not point 3 ;-)
- jfv
Le 05-12-02, à 10:49, Micky Holdorf a écrit :
On 01/12/2005, at 18.15, Jean-François Veillette wrote:
I have a display group quoteDisplayGroup in a webcomponent.
The question is where in the components Java file I set the
binding:
quoteDisplayGroup.queryBindings().takeValueForKey(value,
"attributeValue");
and how...
Another question... in my research I have come upon this one:
quoteDisplayGroup.queryBindings().setObjectForKey(value,
"attributeValue");
Which one should I use?
think of queryBindings() as a NSMutableDictionary (
NSKeyValueCoding ), thus you can use both interfaces.
you can do it almost anywhere you want ( as far as it make sense
;-) ).
- jfv
Hi there...
I never got it to work but I found another way to show the data from
the database. I use this code instead. It generates a qualifier and
fetch specification programmiticaly and populate my displaygroup
with the fetched data.
public WOComponent visEmne() {
emne = subjectItem.subjectText();
NSArray args = new NSArray(new Object[] { emne });
String qualifierString = "(subject.subjectText=%s)";
EOQualifier qualifier =
EOQualifier.qualifierWithQualifierFormat(qualifierString, args);
EOFetchSpecification fetchSpec = new EOFetchSpecification("Quote",
qualifier, null);
EOEditingContext ec = session().defaultEditingContext();
NSArray tempResultsArray =
ec.objectsWithFetchSpecification(fetchSpec);
quoteDisplayGroup.setObjectArray(tempResultsArray);
return null;
}
/Micky Holdorf
http://www.freeiPods.com/?r=21419063
http://www.freeiPods.com/?r=21419063
_______________________________________________
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