Re: Picking up .wo changes
Re: Picking up .wo changes
- Subject: Re: Picking up .wo changes
- From: Anders F Björklund <email@hidden>
- Date: Fri, 6 Jun 2003 12:08:03 +0200
Anjo Krank wrote:
It all started when I had modified a component and was looking for
the "reload definition"
method on the component... It seems that the current caching is
either never or forever.
I get the impression that you want to change .wo files in the deployed
application?
You can do this by overriding "template", but I wouldn't do this.
I wanted to change a .html file within a .wo bundle (within the .woa),
yes.
And I did, and restarted ("deployed a new version of") the
application...
Just thought it to be somewhat complex, for a rather simple
modification ?
WO is *not* PHP. You don't go along and edit pages on your live
server. One may argue if that can be streamlined, but in general, a WO
app is and Application, not a distinct set of pages. Normally you do
more than just edit the .wo (changing code etc) and you simply can't
do this reliably on a live server. The normal way to cope with this is
to add more quality control up front so you don't get used to this
edit-the-live-app thing.
Quality Control ? They wanted to change a logo, and some color
schemes...
(some of those were on static pages, and some had been "componentized")
I don't think it would be unrealistic to have a time-to-live on
templates,
and then re-check the definition files to see if they were modified ?
I consider this partly bad, partly good: for tiny changes like
editing some text, it seems overkill to have to restart the app. But
on the other hand, in my experience it is better on your health and
the discipline of your customer if you get them used to a more
release-oriented workflow ("hey, add this edit box over here right
now" ... "what do you mean 'that's not possible'? You also changed
that text and those links the other day":)
That's just the problems with these three-tier web application servers,
in my own not-so-humble opinion.
They transform the rather simple "website development" into the more
complex "application development".
For instance, having the customer make the modifications themselves is
totally out of the question.
Even if it's just a simple text file change to make, or a new color
somewhere on a HTML sub-listing.
IMO, WO is a rather poor tool for building web sites because it
integrates poorly with how a normal web site is supposed to work. But
It is the arguably the best tool for building web *applications*,
though. But when building apps, you also do things like write
automated tests, version control, bug tracking, releases etc.
One of WebObjects problems, I suppose. Too complicated (and pricey) for
simple websites,
and not enough for large web applications - compared to e.g. the Big
Iron J2EE app servers?
Could be that the way Apple handled the WO 4.5 customers and releases
left a bitter taste,
or that they are now with WO 5.2 up against a much larger selection of
java-based servers ?
But it's hard for me to find a place for it, these days.
I just thought it would have been nice if WebObjects could pick up
changes
in the templates (or in the java code or in the database) in an easy
manner...
For the "java" part, you can look at my ERXCompilerProxy from Project
Wonder. It recompiles classes on the fly. I don't know what you mean
with "pickup changes in the templates"? WO does this already...and
what is "in the database" supposed to mean?
Sounds nice, I'll check it out. With "changes to templates" I mean the
.wod/.html files discussed here ?
With "changes in the database" I mean the whole EOF caching thing, and
the workarounds involved there.
(i.e. defaultTimestampLag, changeNotificationFrameworks,
invalidateAllObjects. that kinda jazz)
If you change either the database directly, or through EOs in some
other instance - there is trouble.
--anders
PS. I'm not arguing against Model-View-Controller, or advocate mixing
code and layout together.
Templates and DataObjects are very useful, no matter what the
development environment is...
_______________________________________________
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.