Re: Basic Question (Webobjects-dev Digest, Vol 3, Issue 187)
Re: Basic Question (Webobjects-dev Digest, Vol 3, Issue 187)
- Subject: Re: Basic Question (Webobjects-dev Digest, Vol 3, Issue 187)
- From: Jeffrey Pearson <email@hidden>
- Date: Wed, 22 Mar 2006 13:18:02 -0800
So,
Targets:
When I create a new application, it sets up three targets:
1) the project name
2) application server
3) web server
So if I understand this correctly,
1) if you set the target to web server, it copies to /library/
WebServer/documents for apache to deal with
2) if you set application server, it copies to you web objects
project directory for the webobject application server to serve
what does the projectname target do then?
On Mar 22, 2006, at 1:00 PM, Travis Cripps wrote:
Yeah... Targets are somewhat confusing. Think of them as something
like where you want the build products of that particular target to
go: application server or web server. Almost everything should be
added to the Application Server target. The notable exception is
the things that you want to end up deployed to the web server.
I'm not sure I understand your question about the rendering of
components. If you're asking about the view of the output while
developing.... Yes, you'll see output that sometimes looks
strange. The html renderer in WOBuilder (WebObjectsBuilder) is
pretty basic, and much of the content is usually a placeholder for
things that will be filled in at runtime. If I misunderstood your
question, please correct me, and I'll do my best to answer it more
appropriately.
I may be straying into territory that you didn't ask about, but
this is the basic process of rendering a component. It's called
the "Request-Response cycle/loop" in WO lingo.
1. The client sends a request to the web server
2. The web server sees it's a request to WebObjects (the ../cgi-bin/
WebObjects/... part of the url) and forwards it to the WebObjects
Adaptor
3. The adaptor parses the incoming request url and figures out what
application is being requested, which instance of the application,
and which session the request belongs to, among other things.
This is where WO gets interesting:
4. The adaptor dispatches the request to the appropriate
application and instance. The application calls its awake method,
looks for the session from the WOSessionStore, and if it is
available and not expired, calls the awake method on the session.
The session looks at the "context" of the incoming request to
figure out which WOComponent needs to handle the request and then
calls the "awake" method on that component. Since the component is
really a sort of tree, with embedded components, it walks the tree
of its subcomponents, calling awake on each of them in turn.
5. The next step is takeValuesFromResponse phase. That method is
invoked on the active component to tell it to read the incoming
response values. It does something similar to the awake method and
propagates the method call to all of its child components.
6. Once every component has had a chance to get the information it
needs from the request, the method invokeAction is called. The
correct subcomponent to handle the action is determined from the
context of the request, and the method that needs to handle the
request is invoked on the that subcomponent (or the top-level
component). That method will return something that can be turned
into the response.
7. Every component gets a chance to render itself into the response
in the addToResponse phase. This is the phase that actually
produces the output you'll get as html, xml, pdf, etc. The
addToResponse method is invoked on every subcomponent in the
component tree (in order traversal, I think).
8. The aggregated response from all the components is sent back to
the adaptor, which forwards it out to the web server and back to
the client.
9. The sleep method is called on each piece of the component (depth-
first traversal) to put everything back to "sleep". Then it's
called on the session, and then the application.
It will be very useful for you to understand the "Request-Response
cycle" as you work with WebObjects. You can override any of the
steps for your components to customize their behavior, and even on
the session/application steps. Most often, the steps you'll
probably override are takeValuesFromRequest and appendToResponse.
I'm not sure how this compares to JSP/JSF, but it's probably
similar. I'm passingly familiar with servlets and jsps, but it's
been a long time since I worked with them.
Anyway, now that you have WAY more information than you wanted...
Have a good day.
Travis
On Mar 22, 2006, at 11:54 AM, Jeffrey Pearson wrote:
I THINK I can get this straight after some experimentation. I will
post if I get lost....the whole target thing is still unclear.
I had this conversation with my coworkers just last week in
regards to JSF. I am wondering if you have the same rendering
issues that you do with jsf.
For example, if you have a jsf table. It contains an html element
such as an image or a <hr>. Then you apply style sheets on top of
that, you end up with a really weird laid out page.
Because the jsf servlet builds the table from its component tags
which then sends the output html to tomcat which renders the
standard html stuff and then finally the browser displays the html
and applies the style sheets....
Do you have this issue with WebObjects?
_______________________________________________
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