Re: Deploying with image woes AGAIN????
Re: Deploying with image woes AGAIN????
- Subject: Re: Deploying with image woes AGAIN????
- From: Jonathan Rochkind <email@hidden>
- Date: Tue, 6 Apr 2004 14:51:34 -0500
[Steve Quirk sent me an off-list reply. I'm sending my reply to the
list, because I realize I've had this conversation off-list with
several people before, and might as well send it to the list so
everyone can see it; maybe I'll need to have it off-list less often
now. :) ]
Replying off list, since this is just opinion. I use absolute URLs and
assume all resources are on the web server because of the projects I've
worked on - mostly large corporate-wide things where I was on a team that
includes a webmaster (in charge of html, gifs, etc), and sysadmin (who
doesn't like funny WO deployment nonsense). I leave decisions of the web
server to them (offloading work!).
Yeah, I understand why that might make sense for you. I've had this
conversation off list with Chuck Hill before too.
Here, we don't really have seperate staff in charge of GIFs and such;
the same developer team in charge of WO code is also in charge of
html, gifs, etc. So for us, it's a lot easier to keep the web server
resources inside the project----now they are controlled by CVS inside
the same area as the rest of the project, when you want to change or
modify an existing web server resource, you just do it to the copy in
the project itself, and when you deploy the project, the deploy
scripts will automatically do the 'split install' and put the web
server resources in the right place. It's one less thing to think
about---if we had source control of images entirely seperate from
the WO project, it would be one more thing to keep track of.
But I understand the reasons for doing it the other way too. I think
it ends up being a developer preference----I don't think either way
of doing it should be considered "The Right Way" for everyone. Under
a split install, even though my web server resources are in the
project, they STILL get URLs generated directly to the web server,
they are not served by the WO app. This is the point of split
install, of course.
Other considerations:
1) If you change where your web server resources are going to be
located for deployment (say, move them to a different machine for
load balancing)---how hard is it to change your WO code to point to
the right place? Under my way of doing it, it's relatively
easy---you can even provide a custom sub-class of WOResourceManager
if neccesary. Under your way of doing it---it depends on how you do
it, if you are hard-coding the direct URLs into the "src" binding of
WOImage, or using some other method/object to create those URLs,
providing a central location to make the change.
2) Do you want your images to show up when editing the page in
WOBuilder? It is very convenient to have them show up, and makes it
easier to edit the page in WOBuilder and figure out what's going on,
especially if you have a lot of graphics for buttons and nav bars and
such. Under my way of doing it, WOBuilder is smart enough to be able
to look up the image and show you it (sometimes, depending on how you
do it, as long as WOBuilder hasn't gotten confused; it isn't as
simple as I'd like, I'd admit). Under your way of doing it: if you
hard-code the URLs directly in, WOBuilder can probably do it (do you
have to use a static IMG, or can WOBuilder still do it for a WOImage,
so long as the "src" is bound to a string literal? Not sure, since I
don't do that.). But if you hard-code your URLs directly in, see #1
above.
--Jonathan
For instance, Dave mentioned that he's trying to reference the corporate
logo - it's probably already on the web server somewhere convenient. The
CSS with the corporate look & feel is also likely to exist there. If he
internalizes that to his app, he's looking at a world of hurt when
everything changes with the next whimsical management edict.
For smaller projects, it probably makes sense. My method works in all
cases so I've just made it a habit. Hopefully, my other how-to post on
this matter is clear enough to be helpful.
- sq
_______________________________________________
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.