Re: Lazy mode (was Re: [RT] Is Cocoon Obsolete?)

2005-10-10 Thread Carsten Ziegeler
Berin Loritsch wrote:
 
 The Ruby on Rails solution is to use an environment variable that 
 defaulted to Development.  In production the environment variable 
 would be set on the server to Production.  For the unit tests, the 
 generators automatically run in Test mode.  Now, I know that Java 5 
 has the re-introduction of environment variables, and we still need Java 
 1.4 support--so some sort of equivalent would be decent.
 
I just implemented a first version for this. You can specify the
org.apache.cocoon.mode system property on startup, and then Cocoon
reads all property files from a directory with this name inside the
WEB-INF/properties directory.

The default value is currently dev, so all files in
WEB-INF/properties/dev are read on startup.

Carsten

-- 
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/


Re: Lazy mode (was Re: [RT] Is Cocoon Obsolete?)

2005-10-03 Thread Carsten Ziegeler
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.

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.
The lazy loading is a property, too. And properties can be used inside
xconf and I think sitemaps as well to replace tokens.

Carsten

-- 
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/


Re: Lazy mode (was Re: [RT] Is Cocoon Obsolete?)

2005-10-03 Thread Sylvain Wallez

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 WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research  Technology Director



Re: Lazy mode (was Re: [RT] Is Cocoon Obsolete?)

2005-10-03 Thread Carsten Ziegeler
Sylvain Wallez wrote:
 
 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.
 
Exactly :(

 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.
 
+1

 
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?
 
I thought so, but I was wrong :( - but it's not hard coded and adding a
variant here that chooses the directory based on something is very
easy to do. I think we should discuss this at the hackathon and then
simply implement.

Carsten

-- 
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/


Re: Lazy mode (was Re: [RT] Is Cocoon Obsolete?)

2005-10-03 Thread Sylvain Wallez

Carsten Ziegeler wrote:


Sylvain Wallez wrote:
 

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.


   


Exactly :(

 

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.


   


+1

 


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?
   


I thought so, but I was wrong :( - but it's not hard coded and adding a
variant here that chooses the directory based on something is very
easy to do. I think we should discuss this at the hackathon and then
simply implement.
 



Ok! Man, this hackaton should last a week!

Sylvain

--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research  Technology Director



Re: Lazy mode (was Re: [RT] Is Cocoon Obsolete?)

2005-10-03 Thread Berin Loritsch

Sylvain Wallez wrote:



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.


The Ruby on Rails solution is to use an environment variable that 
defaulted to Development.  In production the environment variable 
would be set on the server to Production.  For the unit tests, the 
generators automatically run in Test mode.  Now, I know that Java 5 
has the re-introduction of environment variables, and we still need Java 
1.4 support--so some sort of equivalent would be decent.


The solution works amazingly well.