Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Agree, but on the other hand, this lazy-loading of components mean that
some buggy declarations will not be detected at startup time, which
would be better in a production environment.
This leads again to the discussion about "running modes" [1] where some
developer-oriented features (e.g. lazy startup, cocoon stacktraces on
screen, client-side alerts in Ajax libraries) would only be enabled in
development mode. IIRC, ruby on rails has this kind of modes too.
Now, considering how many things are loaded at runtime in Cocoon
(sitemaps, XSLs, templates, etc), we can just consider that components
are just yet another thing loaded at runtime and set lazy mode as the
default one.
Thoughts, especially about running modes?
One interesting question is, what is the default mode we ship?
Development or production? I think we should ship development settings
as the default.
Interesting question. If we ship with dev mode on, many people will
deploy in dev mode. On the other hand, if we ship in production mode,
many people won't see the features of dev mode.
A solution is to ship in dev mode, but ensure that people know they're
in dev mode. With a big splash, either in the console, in a transient
Swing window (appear for 5 seconds and disappear) or why not as the
first page displayed in the browser.
Now, for the modes, if we solve everything with properties, we can
provide one directory for each mode containing different property files
and then simply tell Cocoon to load all property files from a specific
directory. This is already implemented in 2.2 anyway.
You mean that we can already choose at startup time where the property
files are loaded from?
The lazy loading is a property, too. And properties can be used inside
xconf and I think sitemaps as well to replace tokens.
Sounds good.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
