cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: [RT] Implementing Cocoon Blocks
Date Wed, 10 Sep 2003 11:47:03 GMT
Bruno Dumon wrote:
> 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.

Exactly.

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

Although the stated intention was that wiring.xml was not meant to be 
edited by hand (except by "experts" suppose).  So, wild thinking of 
options:

- ant filtering tokens as you propose
- good old xml xpath-based manipulation between servers (xsl or xpatch tool)
- option to deploy with variables/propertynames instead of literal 
values?  For instance, if for servername you can either provide a 
literal value or $property.name and have a .properties file which 
defines property.name=mydevserver.com.  That way, you manage only which 
properties file exists on each server?

> Need to think more about this...

Yup, and there are probably a number of solutions which could work 
without modifying the wiring.xml structure at all so it could probably 
be revisited at implementation time.

Geoff


Mime
View raw message