btw, normally you would set this from the WO params in the run profile
for you app in Eclipse ... -WOCachingEnabled=false. It should,
however, default to this. I think also WOCachingEnabled doesn't full
solve the problem because I think it will not pickup NEW components,
only modified components.
ms
On Jan 23, 2008, at 1:29 PM, Gavin Eadie wrote:
WO5.4 JavaDoc says:
Sets whether or not component caching is enabled. If this is
enabled, changes to a component will be reparsed after being saved,
assuming the project is under the NSProjectSearchPath. Note that
this has no effect on page caching. This is the cover method for
the property WOCachingEnabled.
older WO documentation says:
... each component has a component definition consisting of the
component's template (the result of parsing the .html and .wod
files) and information about resources the component uses. If you
cache component definitions, the .html and .wod files are parsed
only once per application rather than every time they are changed.
When caching is disabled, at each new instance of a component the
time stamp of the .html and .wod are checked to see if the files
have been modified. If they have, they're reloaded.
To cache component definitions, use WOApplication's
setCachingEnabled method:
public Application() {
super();
this.setCachingEnabled(true);
...
}
By default, this type of caching is disabled as a convenience for
debugging. If component-definition caching is disabled and you're
writing an entirely scripted application, you can change code in a
scripted component and see the effects of that change without having
to relaunch the application. You should always enable component-
definition caching when you deploy an application, since performance
improves significantly.
Instead of using setCachingEnabled, you can also perform component-
definition caching by setting the WOCachingEnabled user default.
On Jan 23, 2008, at 11:19 AM, David Avendasora wrote:
So, can you tell me exactly what this method does? Does it have
undesirable side-effects??
Dave
On Jan 23, 2008, at 10:45 AM, Gavin Eadie wrote:
I ran into this too some days ago and, not realizing that
PB.project dependency, I added
setCachingEnabled (false);
to my Application class and that restored rapid
turnaround .. Gav
On Jan 23, 2008, at 9:42 AM, David Avendasora wrote:
Mike, I'm coming to Richmond to hunt you down and buy you lunch.
I had disabled them (see other thread asking if they were needed
anymore). I figured that maybe this is what was causing my
problem, so I re-enabled the .xcodeproj, but not the PB.project
file.
Turns out Rapid Turnaround needs the PB.project file to be there.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
