Re: Picking up .wo changes
Re: Picking up .wo changes
- Subject: Re: Picking up .wo changes
- From: Anders F Björklund <email@hidden>
- Date: Thu, 5 Jun 2003 22:57:20 +0200
Jonathan Rochkind wrote:
Suppose I have to keep even more layout definitions outside the WO
components,
to avoid having to deploy a new application for every little layout
change ?
Perhaps fetch them from the database or read them from a file or
something.
Well, it's actually easy enough for a particular component to NEVER
cache it's .html/.wod information. It's easy enough to make your
component get it's .wod/.html in the usual way, but never cache it.
Just over-ride template(), and your implementation can find the
appropriate .wod/.html files (not sure the right way to do this, but I
know there is an easy one), and then pass them to
templateWithHTMLString and return the result. Now you've got a
component which behaves just the same as usual---but never caches the
WOElement object that results from combining the .html and .wod files.
Because the caching takes place in the default implementation of
template(), which does much the same thing we just discussed, but adds
caching to it.
Probably by just loading the files directly, perhaps using the
WOResourceManager to find them?
One could of course then cache either the files' contents (strings), or
the resultating template.
So if you do this, every single time the page is accessed, the .wod
and .html files will be re-read, and re-parsed, to create the
WOElement object. So there's no good reason to do this, unless for
some reason you want some components that don't ever cache their
WOElement objects. [If you want NO components to cache their
WOElements, it's easier just to turn this off with the relevant flag].
More typically, you might want a component which gets it's .html/.wod
from a non-traditional place, or actually uses different .html/.wod at
different times depending on state, and that's why you'd over-ride
template(), and lose the caching (intentionally or not).
If it was just one component that should load from disk each time, you
would just disable caching for that component?
(And possibly suffer the death-of-a-thousand-threads, but let's assume
the regular single-threaded WO environment)
But what you're asking isn't to lose this caching entirely on a
component-by-component basis, or to make the component get it's
.html/.wod from a non-traditional place----what you're asking is to
have the WOElement-generation and the caching work as normally---but
allow you to invalidate cached WOElements at will. This is what you
can't easily do, because the cache system used by the default
template() implementation is not exposed at all.
Which is more of a WO bug, than anything else. I think I'll radar it as
a "feature request" on the BugReporter.
To have some kind of interface into the template cache (or the entire
WOComponentDefinition) would be helpful.
Serves me right for choosing a proprietary closed source system, I
guess.
If you could re-implement the cache system yourself, then you could
use it in your custom template() implementation, to get a caching
system that performed just like the existing one, but exposed enough
API to allow you to invalidate entries at will. I've never tried to
do anything like this, but it's this that Pierre says he has done, and
he says it wasn't at all easy, so there you go.
Doesn't sound too hard...
if (cachedTemplate == null)
cachedTemplate = templateWithHTMLString(htmlString, wodString, null);
But you don't need to keep the .html/.wod in a non-standard
place---and don't gain anything by doing so. You can keep it in the
standard place, but over-ride template(), using
templateWithHTMLString() in your implementation, to avoid ever caching
the parsed .html/.wod for that component. Which is exactly what you'd
get anyway if you kept the .html/.wod in a non-standard place, like
the db or something.
I didn't mean keeping the .wod and .html files in the database
(interesting, but can't see the benefit?)
I meant replacing my static content with even more dynamic elements,
and load *those* from the database.
(like: background colors, stylesheet used, etc. etc) But that means me
doing it, and not the web designer.
Then again, maybe this is the divine sign that I should rewrite it,
and lose
the pesky .wod files forever and just integrate everything into the
.html files ?
So that one can edit the .wo components in modern webpage editing
tools, I mean...
Like these guys do ? http://www.cluster9.com/examples/index_e.html
(C9WOTemplate)
I suppose.... but I'm not seeing what you'd get from this. Whether
the information to create the dynamic web page is in one file (.html)
or two (.html/.wod), that information will still need to be parsed to
create the actual objects that will generate the web page. And the
results of that parsing either will be cached, or they won't. If they
are cached, you'll either be using the existing component definition
cache (in which case you have no way to invalidate entries) or you'll
be writing your own (which Pierre tells us is no fun). Getting
things to work without a .wod is going to be no fun (unless your page
is just straight html with no dynamic content or sub-components, in
which case it's straight HTML already!), and I can't see how it would
get you anything you are interested in anyhow.
You didn't look at the code example, did you ? (Project C9WOTemplate,
C9Component.java)
Having WebObjects serve static HTML or static images is just a huge
waste of resources, IMHO.
That's what "WebServerResources", or even better regular hrefs outside
the system, are for.
Most non-Mac programs have issues with bundles (or "those weird
directories" as they call it).
This makes having someone not used to WebObjects edit components with a
graphical tool rather hard ?
But you can transform the .wod file and the .html into one combined
file ".wohtml" (or something)
So instead of this:
.html:
<HTML>
<WEBOBJECT NAME=String1></WEBOBJECT>
</HTML>
.wod:
String1: WOString {
value = binding;
}
You would have this:
.html:
<HTML>
<WEBOBJECT componentName=WOString TAGNAME=String1
value=binding></WEBOBJECT>
</HTML>
And you would have a much easier time editing that with real third
party tools such as DreamWeaver.
I agree, it doesn't really relate to resetting the cache, but if one
should rewrite template()...
BTW; None of those above are valid HTML files, of course. But then
again HTML 3.2 isn't very picky.
(There are some other competing template engines that allow for regular
HTML files and attributes...)
--anders
PS: I have already made the change to my html file, deep down in the
.woa bundle's .wod directory,
and restarted the instances of my application. This is now more of
a philosophical argument. :-)
_______________________________________________
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.