• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: WebObjects and linked CSS.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WebObjects and linked CSS.


  • Subject: Re: WebObjects and linked CSS.
  • From: Jonathan Rochkind <email@hidden>
  • Date: Mon, 9 Feb 2004 11:27:00 -0600

Under normal WO deployment environment, a 'split install' exists. That is, all of your 'Web Server Resources' are in a certain path under the web server document root. [If you are deploying to non OSX machine, and/or if your web server is a _different host_ than your app server, you may need to move the Web Server Resources folder to the proper place manually, it won't be installed automatically by any build scripts or anything].

And WOResourceManager should return URLs that point to the web server resource via the web server itself, not a URL to the application. WOResourceURL uses the WOResourceManager to generate it's URLs.

I've never actually tried this with a web server on a different machine than the WO app server. It ought to work somehow, but I'm not sure how to make it work (WOResourceManager would need to know the hostname of your web server somehow, obviously). If it doesn't, you could subclass WOResourceManager and fix it. Or you could just run a web server on your app server machine, if ony for the purpose of serving Web Server Resources of your apps and frameworks.

'Split install' configuration in general can get kind of confusing. I'm never sure what tells the running WO app (that is, the WOResourceManager) if it's in split install mode or not. But there ought to be a not too dificult way to get things working, so you can include web server resources in your project, and they will still be served up (in a deployed app) by the (or 'a') web server directly, without going though your WO app. That is the intent of the Web Server Resources. In my own situation, with my web server on the same machine as my app server, this has always worked pretty seamlessly, it just works---once I install the WebServerResources folder in the proper place under the web server document root. [Explaining the 'proper place' can get kind of confusing, even though it isn't once you understand it. If you are deploying to OSX and using ProjectBuilder/XCode to install, it will do it for you.]

--Jonathan

At 3:48 PM -0500 2/6/04, Drew Thoeni wrote:
But doesn't this store the project.css on the application server instead of on the web server where it could be served up with less overhead?

Drew

On Feb 6, 2004, at 2:13 PM, David LeBer wrote:

Use WOResourceURL.

I usually use something like this in my component html head:

<link rel="stylesheet" type="text/css" href="<WEBOBJECT NAME=ResourceURL1></WEBOBJECT>">

and this in my wod:

ResourceURL1: WOResourceURL {
	filename = "project.css";
	framework = "app";
}

On 6-Feb-04, at 12:16 PM, Andy Satori wrote:

OK, I'm a total WO newbie. I've been fascinated by it since it was a NeXT project, but never justified the costs. I'm comfortable writing JSP, ASP, and ASP.NET code and from what I've found with WO, it's very very good, with a couple of exceptions. One of those is that I can't figure out a way to get the <link > tag for a CSS set correctly.

I have put the .css in the web resources group, and included them in the project as if they were gif's. I have a <link> tag all set up and I've placed a WOString in the url. All of this works, and it loads the CSS fine. The problem is that I have to give it a fully qualified URL using this method. What I want is to use the 'filename' type property that the WOImage tag that resolves to the resources folder with the gif's.

Any and all suggestions are welcomed :-)


Andy Satori - Druware Software Designs - email@hidden
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.



;david

--
David LeBer
Codebase Software Systems
site: http://www.codebase.ca
blog: http://david.codebase.ca
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >WebObjects and linked CSS. (From: Andy Satori <email@hidden>)
 >Re: WebObjects and linked CSS. (From: David LeBer <email@hidden>)
 >Re: WebObjects and linked CSS. (From: Drew Thoeni <email@hidden>)

  • Prev by Date: Shared vs regular editing contexts
  • Next by Date: Re: ReportMill Alternatives?
  • Previous by thread: Re: WebObjects and linked CSS.
  • Next by thread: Globally unique IDs
  • Index(es):
    • Date
    • Thread