Hi Bart, we're always willing to look at incorporating user contributed
enhancements to Chameleon, it's always a question of time.  If you want to send
me the code, I'll take a look at it and see if it could be added when time
permits.  

I agree that option 1 is the better way to go and would be just as easy to
program as option 2.

Set Target Milestone to 1.99 Final

Hi Bill,

I have a few questions about this one:

-now there is an option in the widget to get a tar or to get a tar.gz file 
(compress checkbox). If you compare this to WinZip, the .zip format 
is "equivalent" to the tar.gz format (there is not just archive option with 
WinZip). Is it possible that we remove the optional compress checkbox and give 
the user the choice between zip or tar.gz? Anyways, we should be encouraging 
people to download compressed content, especially with shapefiles or GML, they 
compress well.

-the Zip will introduce dependency on the PEAR Zip.php file. Would you want to 
add this one to the common directory? Or what are your policies with shared 
libraries?

If we get consensus on the way to do this, I am willing to take this one on me.

Bart,

Is the PEAR Zip.php file the only file required?  i.e.  Does this file require
other PEAR modules to be installed?  I ask this because we ran into a similar
thing with the PEAR tar file.  It had interdependancies on other PEAR modules.

Hi Bill,

the only dependency I see in the file is:

require_once 'PEAR.php';

I was afraid that there would be a dependency like that.  The widget would
require PEAR to be installed in order to work.  To the best of my knowledge,
Chameleon does not have any widgets that depend on PEAR.  That being said, there
are discussions going on that might require PEAR dependencies in Chameleon in
the future.

I'd like to get Paul's input on where he sees Chameleon going in the future
before commiting these changes to CVS.

Bill, I tried the same approach as you guys did in the tar.php file, just
comment out the require_once and it still works. So maybe it could work like this.

//require_once 'PEAR.php';

Perfect, if it works that way then I don't see a problem with it.  Move it to
the common folder then.  I'll give it a try when I get a chance.

The changes are in CVS, took me some revisions though because of some apparent 
conflict. I have tested and it still works. Anyway, I hope I am used to the CVS
stuff now ...

Needs to be done: put zip.php in common/zip/

For docs in future:
Added attribute compressformats, possible options ZIP and TGZ.

<cwc2 type="ExtractWFSData" styleresource="NavButton" visible="true"
image="/ms4w_20/apps/chameleon/htdocs/images/tool_extract_off.png"
imagetip="Download shapefile of GML" imagewidth="24" imageheight="24"
popupwidth="450" popupheight="300" toolbar="false" status="false"
menubar="false" outputformats="Shape,GML" compressformats="ZIP,TGZ" >
    <image state="normal"/>
    <image state="hover"/>
</cwc2>

Let me know if there is any problem with tabs or line feeds ...

Copying my comment from bug 429:

Why is compressformats a required attribute?  It seems to me that it would be
better to simply assume no compression if the attribute is not set?

Daniel, this was an oversight in the design.  The original requirements for the
widget were to download a compressed verion, the decision was made at design
time to allow the user to download the uncompressed format if they wanted.

As Bart said, it would require a number of changes.  This is because the
compression format is firmly tied to the GUI.

I do agree that it could be made an optional component.

My opinion is that any parameter should be made optional unless it's not
possible to set a proper default value and behavior for it. If you don't do that
then you end up with widgets that are a pain to configure because they carry
lots of useless required parameters that always have the same value.  

However Paul is the main architect so I'll let him make the final call.

There is some confusion in the last couple of comments.  compressformats does
not control compression or no compression, it controls the list of available
compression formats available to the user.

The Chameleon solution to this problem is to make compressformats optional with
the default being all available compression formats.  For instance, in the code
for the widget we would declare a member variable mszCompressFormats with a
default value of "zip,tgz,tar" so that if the template designer did not provide
the compressformats attribute in the widget, a legal and useful value will be
used (which is to provide all available compression formats).  Then in the case
of building an application for a specific client such as Bart's, the template
designer could include compressformats="zip" so that only ZIP is listed as a
valid compression format.

The real solution is to remove compressformats and add subtags to list the
compression formats.  Specifically, the compression checkbox would be removed
and the list would be formed from subtags like:

<format name="zip" type="zip" default="true"/>
<format name="compressed tar" type="tgz" default="false"/>
<format name="no compression" type="none" default="false"/>
...

with no formats listed, the default list would appear (none, zip, tgz, tar). 
When formats are listed, then they would be used instead.  This would allow
complete control over the presentation and setting of the default option etc.

Paul, I agree with your comments. But the same would apply to outputformats I
guess.

In your comments you one time opt for a list of 3 options, and another time for
4 options. As the outputformat (GML, shape) determines the number of files, I
would opt for just 3 formats (tar, zip and tgz), just tar even if there is one
file (for consistency). What do you think? Otherwise, what would the
application
do if somebody selects compress format "none" and outputformat "shapefile"?

1. none
2. zip
3. tgz
4. tar

Let me know if you want me to fix this and when.

good catch, you are correct that we should add tags for output formats as well.

so the new proposal is:

<outputformat .../>
<compressionformat .../>

available output formats are dependent on OGR-supported formats, but for now are
limited to shapefile and GML

available compression formats are TAR, TGZ, and ZIP.

I agree that it makes sense to enforce compression, so how about we drop TAR and
use either TGZ or ZIP as compression formats?

As a note, the use of subtags allows us more flexibility in defining future
compression (bzip, bzip2, lzw, ...) formats and OGR output formats.

Bart, you can implement this if you have the time, since it is important for
your clients.

All changes are in CVS now. Files changed:
-ExtractWFSData.php
-ExtractWFSData.phtml
-ExtractWFSData.widget.php

Done:
-Compressformat renamed to compressionformat.
-Made value comparison case-insensitive.
-Implemented outputformat and compressionformat as arrays instead of
comma-separated string attributes
-provided default values in the code (Shape and GML for output, TGZ and ZIP for
compression).
-if only one format is provided in the template, the value is not read from a
select list but from a hidden form field.
-options now use css class inputList
											<cwc2 type="ExtractWFSData" ...>
  <outputformat value="Shape" />
  <outputformat value="GML" />
  <compressionformat value="ZIP" />
</cwc2>

TODO: update widget documentation when format is defined.

Changed Target to FUTURE.

This has been fixed a while ago.