[Chameleon] [Fwd: Re: Chameleon]

[Dave McIlhagga]

I think a lot of this discussion would be interesting for all chameleon 
users ... at least I learned a lot. ;)

I've editted this discussion to remove anything that would be too 
specific to given clients etc...


-------- Original Message --------
Subject: Re: Chameleon
Date: Tue, 16 Sep 2003 12:38:46 -0400
From: Paul Spencer <pagameba@magma.ca>
Reply-To: spencer@dmsolutions.ca
Organization: DM Solutions Group Inc
To: bart.van.den.eijnden@geodan.nl
CC: Daniel Morissette <morissette@dmsolutions.ca>,   Dave McIlhagga 
<mcilhagga@dmsolutions.ca>
References: <oprvlilpwxfecm84@localhost> <3F672D18.30301@magma.ca> 
<oprvln17rgfecm84@localhost>

Bart van den Eijnden wrote:

> Hi Paul,
>
> thanks for the quick reply.
>
> With regard to the Chameleon version. I think we will be conforming as 
> much as we can to OGC interfaces, because our client thinks this is 
> very important. But if I understand correctly from the maptools 
> website the best option is to use Chameleon 1.1 anyway? 

interesting observation.  There is a significant difference between the
two versions.

Chameleon version 1.0 is an OGC-only version.  It was built to satisfy
the requirements of a contract with GeoConnections, and was responsible
for adding Context support to mapserver as well as creating a Service
Instance called CWC2.  This service instance is an application that
ingests a template file and a context file and spits out a web
application.  The template file contains all the tags for widgets
required in the application.  The core technology that processes the
template file and widgets is what we took out of CWC2 and turned into
Chameleon for version 1.1.

So version 1.1 has no specific integration into OGC-specific stuff.  It
works with a template, some widgets, and a php-mapscript map object (not
necessarily a map file, just a map object, and even this is optional in
some circumstances).  Many of the widgets created for version 1.0 relied
on some very specific OGC functionality provided by the CWC2 service
instance.  In the new version, the CWC2 service instance needs to be
re-written as a chameleon application.  In the old version, the two were
the same thing.

The de-coupling of the underlying technology from the service instance
is taking some time.  The core of Chameleon 1.1 is pretty much stable
now.  The work is mostly in converting and testing the widgets, and this
is driven by our contract priorities.  These priorities currently do not
include converting the CWC2 service instance and related OGC-specific
widgets that may have relied on the service instance.

This does not mean that you cannot use Chameleon 1.1 for OGC-centric
applications, just that the existing widgets that may have helped cannot
be used without some redesign.

The future of Chameleon is definitely with the 1.1 version.  While the
web-site says alpha, it is really quite stable but some of the widgets
are definitely broken.   I will be repackaging the widgets into groups
and distributing each group of widgets as separate downloads, which will
allow us to distribute a stable Chameleon and stable widgets, while
keeping some unstable use-at-your-own-risk widgets available for future
work.

If you are willing, it is probably worthwhile to work with Chameleon
1.1.  The core is more stable, and probably faster.  It can still work
with all the OGC stuff that mapserver supports, this is not a problem.
Plus we are more likely to fix bugs and improve Chameleon 1.1.

> With regard to the query builder widget, why would you choose not to 
> conform to the OGC specification? Because at the mapserver side, 
> DmSolutions is already working on implementing SLD in combination with 
> Filter. Is it possible for us to join efforts on this widget? 

This is a client-specific requirement.  They have a custom metadata
database they want to build queries for in quite a specific way.

We do have a couple of other projects ongoing that will be working with
WFS.  If you share your requirements/design for this widget with me, I
may be able to push some of our efforts along the same path in these
other projects, or at least identify if there will be any overlap.

> With regard to the stateless catalog widget, how can there already be 
> one in Chameleon when the OGC only comes with a prelimenary 
> specification at the TC meeting in October this year? I.e. to which 
> specification does it comply? 

um.  Perhaps I am talking out of the top of my hat!  However, the widget
queries the following location:

http://ceomap2.ccrs.nrcan.gc.ca/cslt/wes/stateless-search.html

which, if you load this in a browser, you will see that they call it a
OGC Stateless Catalog Query Interface.  :)

> With regard to the extract shapefile option, it would be a small 
> enhancement I guess to send the URL to the user to get a "download" 
> option. By when do you know whether or not DmSolutions will build this 
> kind of functionality in the near future? 

This is still considered to be a potential project to be followed up at 
this point, I would expect to know more in a couple of weeks.

Cheers,

Paul

>
> Best regards,
> Bart
>
> On Tue, 16 Sep 2003 11:32:40 -0400, Paul Spencer <pagameba@magma.ca> 
> wrote:
>
>> Bart,
>>
>> I'll take the liberty of replying in line ...
>>
>> Bart van den Eijnden wrote:
>>
>>> Hi Daniel, Paul,
>>>
>>> Geodan, the company I work for, is going to do a project using 
>>> Chameleon. This means we will internationalize Chameleon to a 
 >>> Dutch version (all we need to do is
>>> adapt the dbf files or not?).
>>
>>
>> More or less.  The main mechanism for translation is to provide 
>> separate templates in each language, and the main application then 
>> switches templates based on some application-specific logic.  For 
>> CWC2 (Chameleon 1.0) there is a language widget that was provided for 
>> this purpose, it has no interface and just provides a javascript 
>> function called setlanguage() that can be called from your own code.  
>> In Chameleon 1.1, there widget will no longer work (it hasn't been 
>> modified to work with 1.1), and may actually be redundant (I have to 
>> think about it).  But in 1.1 you can easily provide the functionality 
>> to choose between templates in your Chameleon subclass.
>>
>> The widgets themselves try to get user-interface-specific text out of 
>> dbf files, so for these, it is a matter of adding a new column to the 
>> dbf files and providing the translations.  Be careful with extended 
>> characters and use HTML encoded versions if you can.
>>
>>> With regard to this project we want to add some functionality 
>>> (widgets) to Chameleon, but perhaps it is useful to outline the 
>>> functionality we want to add, so there won't be any things done 
>>> which are not useful or which DmSolutions is already doing or 
>>> planning to do.
>>>
>>> Basically, we want to add the following functionality:
>>>
>>> * a query builder widget (communicating through the OGC WMS 
>>> interface, SLD + Filter), also combining the alphanumeric part with 
>>> a box selection in the map
>>
>>
>> this sounds useful.  We may be working on a query building widget, 
>> but it would not be in the OGC world.
>>
>>> * a treeview widget (analog to the one in Maplab), the treeview 
>>> would need to combine meta information with layermanager 
>>> functionality (add layer to map etc.)
>>
>>
>> We will probably build something like this to replace the one in 
>> MapLab since we are currently converting MapLab into a Chameleon 
>> application.  However, this replacement is low on our list.  If you 
>> do implement something like this, we would be happy to help with the 
>> design in case it can be made to serve both projects.
>>
>>> * a widget which can communicate to a OGC stateless web catalog (and 
>>> web registry server)
>>
>>
>> One exists already that uses the GeoConnections catalog service, the 
>> CatalogSearch widget.  I have not checked this widget against 
>> Chameleon 1.1, it may need some work (although probably not a lot).  
>> You could use this widget as is, if it does the right thing, or base 
>> a new widget on it.
>>
>>> * a download widget to download a shapefile of the (vector) data
>>
>>
>> We have a lead on a project to do something similiar (extract 
>> shapefile from selected region), but without the download component 
>> (zip and put in web-accessible directory).
>>
>>> Does DmSolutions have PHP coding standards which we could follow? 
>>> And is there a way we could integrate our efforts, using CVS for 
>>> example?
>>
>>
>> Nothing very formal, we try to include a standard comment block at 
>> the top of each page that includes some identifying info and a 
>> license.  You can see from the existing code the formatting style we 
>> (try) to conform to.
>>
>> Integration would have to be manual for the moment, although we will 
>> have a public cvs on www.maptools.org soon.  I am currently 
>> developing a strategy for packaging and distributing widgets 
>> separately from the core of Chameleon.  I would envision these 
>> widgets as being either distributed in your own package, or 
>> integrated into the other packages that are being created.  More on 
>> the website in a week or two on this, I hope.
>>
>>> What also is very important for our project is layout functionality 
>>> in PDF (map, legend, north arrow etc.), in several paper sizes, but 
>>> for this I don't know what is the best path to follow, PHP or the 
>>> CGI PDF output option?
>>
>>
>> We have a PrintWidget (Print in Chameleon 1.1) that supports output 
>> to PDF (actually to all formats supported by the mapserver 
>> installation).  It lacks a north arrow, but this would be an easy 
>> addition to the existing widget.
>>
>>>
>>>
>>> Hope to get some input from you on this.
>>>
>>> Best regards,
>>> Bart
>>>
>> HTH.  Please keep me in the loop on this project, it sounds very 
>> interesting.
>>
>> I hope to be putting together a public roadmap for Chameleon and to 
>> encourage contributions to it.
>>
>> Can you let me know which version of Chameleon you are using for your 
>> development?  This would be very helpful to me in answering some of 
>> your questions :)
>>
>> Cheers,
>>
>> Paul
>>
>
>
>

-- 
--
Paul Spencer
Applications and Software Development
DM Solutions Group Inc.
http://www.dmsolutions.ca






-- 
Dave McIlhagga
President, DM Solutions Group

http://www.dmsolutions.ca
EMail : mcilhagga@dmsolutions.ca
Phone : 613-565-5056 x15
Fax : 613-565-0925