cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: [RT] Implementing Cocoon Blocks
Date Wed, 10 Sep 2003 09:13:47 GMT
On Tue, 2003-09-09 at 17:14, Geoff Howard wrote:
> Bruno Dumon wrote:
> > On Sat, 2003-08-30 at 04:57, Geoff Howard wrote:
> > <snip/>
> > 
> >>But this brings up another point - what to do if the wiring.xml and 
> >>others is deleted?  Presumably, all blocks are "uninstalled" in this 
> >>state, but what does this do to persistence requirements.
> >>
> >>Also, how to recreate the deploy step efficiently?  For example:
> >>
> >>You deploy a block with some dependencies and configuration.  The block 
> >>deploy process walks you through setting configs and resolving 
> >>dependencies.  You then have no record of these deployment choices 
> >>except in wiring.xml which is not meant for human consumption.  Perhaps 
> >>it would be good to record these human-step deployment time 
> >>configurations in a conf file which could be easily reprocessed to 
> >>easily re-deploy all blocks to their last configuration.
> > 
> > 
> > I think the conf file you're speaking of here is simply the wiring.xml
> > file itself? Remember, the block deployer has read-write access to this
> > file, so it can first read the existing information, then let the
> > administrator modify it, and then write it back. It's not like each time
> > you want to modify the configuration of one block you'll have to
> > re-enter all the parameters for other blocks as well.
> 
> Ugh, I see now that I didn't explain well the scenario I was thinking of 
> and now can't remember!  IIRC I was trying to think through the process 
> of replication and/or staging.  In this case, would I copy over 
> wiring.xml and all blocks directories? (presumably)  But, what if some 
> of the deploy-time configurations need to change on the way?  For 
> instance, on a staging server, you use a different database.  So, I was 
> just trying to get a picture in my head of how that would work and what 
> the pitfalls were.

Aha, I understand the issue now. And next to staging and live servers
there are of course also the development servers or workstations. So
there are parameters which will be common for all installations and
parameters which can be different, and it would indeed be useful if we
can feed those common parameters to the block deployer, so that only
system-dependent parameters need to be completed.

Hmm, now that I think of it, it would also be useful to feed the
system-dependent parameters to the block deployer, because I don't want
to re-enter those either when I do a "clean" block deploy.

Basically what I'm arriving at is that the block deployer should be able
to run in an interaction-less mode by providing it with input files
giving it all the information.

Or then maybe it becomes more useful to write the wiring.xml by hand and
place a few @token@'s here and there which are replaced by an ant script
based on the values in a local.properties file.

Need to think more about this...

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message