Re: WOImage, WebServerResources, and absolute paths
Re: WOImage, WebServerResources, and absolute paths
- Subject: Re: WOImage, WebServerResources, and absolute paths
- From: Catherine Seppanen <email@hidden>
- Date: Mon, 20 Jun 2011 13:46:31 -0400
On Jun 19, 2011, at 12:06 PM, Ramsey Gurley wrote:
> It uses WOContext _urlForResourceNamed which calls WOResourceManager urlForResourceNamed(). If you are using Wonder, ERXResourceManager is used which provides a fix for using paths relative to your resource. (Wonder makes a '?' into a '/' I believe).
>
> So if the script and the image are in the same framework, it should be doable. It might help if you dig around in Wonder's ajax framework to see how they do it there. Judging by the directories, it looks like the ibox.js is loading images relative to the script.
>
> Also, the WOFrameworksBaseURL property will allow you to set a custom framework path for the WSR.
>
> http://developer.apple.com/legacy/mac/library/documentation/WebObjects/WOAppProperties/WOAppProperties.pdf
Aha! WOFrameworksBaseURL is what I'm after, which I see is also set in the build.xml file down in the woapplication task (previously I was just looking at the split target).
So, after weighing the pros and cons, I came up with three options and for my situation, I'm going with option 3:
1. Manage the JavaScript library and its CSS files outside of WebObjects altogether. This is actually how the majority of the web server docs are currently handled. But I'm finding it easier to keep track of things if the files are in a framework (easier to remember to check things into SVN and remember to deploy updated versions). Also, by keeping things in the frameworks or app, I can use the fantastic AjaxUtils routines like addStylesheetResourceInHead and addScriptResourceInHead (so handy when your page template is about five layers away from where your page content is being generated).
2. Change WOFrameworksBaseURL to not include the application name. After initially thinking this was the way to go, I remembered that it caused me troubles previously because I deploy apps to a couple different web servers and use separate directories on the web server for different clients. This means I'd have to keep track of which frameworks are needed for which apps and clients so I get all the right ones deployed. Blech.
3. Create separate versions of the offending CSS file customized for each app; then include the app name when adding the resource programatically. This could get unwieldy over time but for now, with only 6 apps using the JavaScript library, it's not too bad. In the future, I could opt to dynamically generate the whole CSS file (with all the attendant caching needed there).
So, at the end of the day I guess I really didn't need to delve into the resource manager docs or muck about with the frameworks base URL but it never hurts to learn something new.
> [OT] cicada.com... WebObjects... in Raleigh, NC? I didn't know anyone was doing WO in Raleigh. (^_^)
Yep, I work at Cicada Consulting Group in Raleigh. We're a fairly small shop as I am the entire WebObjects development team. :) If anyone on the list remembers Mark McCraw, I took over from him a few years ago (has it been that long already?).
Thanks all!
Catherine _______________________________________________
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