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: Loren Cahlander <email@hidden>
- Date: Wed, 22 Mar 2006 15:30:33 -0600
Check out this page:
http://developer.apple.com/documentation/WebObjects/PB_for_WO_Developers/WOinPB/chapter_1_section_4.html
According to that link, the application target is an aggregate target. It appears that you should just use the two and ignore the aggregate target.
On Wednesday, March 22, 2006, at 03:18PM, Jeffrey Pearson <email@hidden> wrote:
>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
>
>
_______________________________________________
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