[scoop] FW: Sitescooper improvements for isiloXC support
Chris Werner chriswerner at mail.telepac.pt
Thu Mar 4 20:18:49 GMT 2004


Hi All,
I sent this fix in to J, but he's a bit busy at the moment to check out out
thoroughly and check it in.
He suggested I post it to the group so someone else with CVS priveleges can
take a look.

Cheers
Chris



Hi J,
A while ago I started using -misilox instead of -misilo to take advantage of
isiloXC when generating my pdbs. However, I found the ixl tags hard coded
into Main.pm to be wanting, so I experimented with things like adding new
config params for isilo Category and Site params for image options (for
example the image_width arg is totally ignored and is hard coded in there.)

Recently I decided to move these into the latest version (I wasn't using the
cvs version when I did this) and clean it up for submission. In the process
I decided to give up on adding new params and hacking them in to the ixl
file, and just let the user specify the ixl themselves.  (ixl as you
probably know is the file-type/xml format for the files isilox uses for
storing the eqivalent of a .site file).

New Functionality
=================

So I have made the following functional changes and attached the code in a
zip:

1. Importantly: If you don't change any .site files or the .cf file, then
none of the changes I made comes into play - the same old hard-coded ixl is
used.

2. I've added a new param to sitescooper.cf "ISiloDefaultIxlFile" that
points to an .ixl file in the file system.
This means that users can change the iSiloX options by using the iSiloX GUI
tool to create a new document, change all the options, then save as a .ixl
file. The <Source> and <Destination> tags of the document are stripped and
replaced by sitescooper but the rest is used for generating the isilox pdb.

More details are given in the comments in sitescooper.cf.

The most common likely use for this is to allow the users of -isilox to
speficy global settings for things like image depth, color, inclusion,
dithering etc, and perhaps for category too.

3. So that these settings can be overridden on a per-site basis, I added a
new site param called "ExtraISiloIxlTags". This is a little different in
that the user has to specify a set of top-level tags for the .ixl file.
These get appended to the generated file thus overriding the defaults (or
overriding the global options if the new config param is used as in 2,
above). This takes advantage of the fact that isilox tolerates the tags
appearing more than once by simply taking the last tag and ignoring earlier
copies (or at least its xml parser does). 

So you can set general options in your .ixl file and override specific
options in the .site files. 
The fact that you have to override the whole tag such as <ImageOptions>
means that you can't override, say bitdepth separately from dithering, but
its still pretty powerful. And simpler and more durable (ie resitant to
changes in isilox) than adding a bunch of new site params.

You'll find the following files in the attached zip file:
(Note that I did a cvs update just before zipping so they should be ready to
check in and also that the zip file has the right dir structure to unzip
into sitescooper)

lib/Sitescooper/SCF.pm
- Added support for the ExtraISiloIxlTags param.
  This works like the other postproc... params in that it is usually
surrounded in { ... }

lib/Sitescooper/Main.pm 
- added support for the ISiloDefaultIxlFile config param
- extensively changed the setup_isilox_argfile subroutine to support all of
this.

sitescooper.cf
- added a commented out section (with comments) for the ISiloDefaultIxlFile
parameter

default_isilox.ixl
- a new file as an example .ixl file - not used unless the param in
sitescooper.cf is uncommented

doc/site_params.html
- updated to describe the new ExtraISiloIxlTags param

sites/dilbert.site
- an example of how I'm using the ExtraISiloIxlTags site param to change the
image options for my dilbert scoop.

So what do you think? Is this check-in-worthy? Do you have any issues or
questions?

Cheers
Chris

PS I just realized that the attached .cf file is my own variation for
testing and not the same as the version in CVS, so the last part of it would
have to be copied into the proper clean cvs version rather than just
checking mine in.