Re: [ZMapServer-Developers] Fwd: Archetype wrapper products for ZCO

[Sean G. <sgi...@fr...>]

Yves, this didn't seem to make it to the list.

On May 3, 2005, at 12:32 PM, Moisan Yves wrote:

> Hi Sean,
>
> Thanx for your comments and see mine interspersed.  If you realize this
> message doesn't make it to the list, please forward it for me.  The 
> only
> way I have found to bypass our new (improved ?!!?) email environment is
> to post on lists using a web interface, e.g. on gmane.  As I don't 
> think
> IT is willing to understand why the hell I can't post to newsgroups, is
> there such an interface for ZMapServer-developers ?
>
> Cheers,
>
> Yves
>
>>> Yves, I am liking this approach very much, and think that we could
> get
>>> an AT product going quickly if we focus first not on map and layer
> and
>>> symbol archetypes, but on archetypes for the actual content.
> Features
>>> and their attributes.
>
> Well I thought this was precisely what I tried to do in the
> pseudo-typology of tentative AT geoenabled content types I wrote in my
> last email : GeoDataContainer and GeoDataObject.  In my email, I am
> precisely trying to come up with some general geoenabled objects people
> could derive from to create their particular geoenabled content types.
> In my view, a GeoDataContainer could hold other containers and
> GeoDataObjects (points, polygons ...).
>
> I also mention in my email that "I don't think there should be a "map"
> AT
> product to wrap a MapRenderer ...".  In my view, we need products to
> build viewing areas and edit maps (probably a task given to a site
> admin) that may or may not be AT.  It depends how we view those
> utilities : do we see an AT "map" product, in which case this "map
> content type" could be viewed as a kind of factory product content type
> to build maps?  For me, this is not *content* per se : it is rather a
> utility product and as such not necessarily in the realm of AT.
>
> So I concur with your objectives.  IMO, we need to find appropriate
> common attributes/properties and behaviour to come up with a few 
> general
> geoenabled content types that people can use and this is where I hoped
> people on this list would kick in.
>
> The WebMapContext product is just to allow people to save their
> profile/session/preference info an dit could be tackled at a later 
> time.
> I do believe such a WebMapContext would be relatively easy to make in
> the context of a CMS and that would really add value to Plone as a web
> mapping development platform.
>
>
>>> My first need for such an AT product won't require any user
>>> manipulation of layers at all: all that is needed is for portal
> members
>>> to create new points and regions, and have these features show up
>>> immediately in a pre-defined map.
>
> +1.  That's exactly what I am calling for in the short term.  OTOH,
> without allowing full control on layer selection and drawing order, it
> should be easy to add a tick box to layers instead of explicitly
> choosing them in the index_html list for example.  Once you have drawn 
> a
> map with the selected layers, no layer is selected anymore and the user
> has no clue what is on the map (let's make the assumption the user just
> forgot what layers he asked for : happens to me !).  Having just tick
> boxes could at least give a trace of what's on the map.  Ticking layers
> on/off after rendering could make a "refresh" button" to appear or turn
> red, signalling that what you see is probably not in synch with the
> ticked layers anymore.  But of course that can wait for implementation
> and that is JS/AJAX stuff to a large extent.
>
>>> My demo application was intended to be as simple as possible and
>>> javascript free.  the shiftMap and zoomMap Python Scripts are
>>> completely arbitrary and not necessarily what we want to use with a
>>> richer UI.
>
>>> A rich UI is essential for the success of a Plone ZCO product.
>>> Something that is in harmony with other Plone products like Kupu.
>
> I would say the UI front is probably more urgent in terms of attracting
> people to the PCL/ZCO bandwagon.  When my boss looks at the maps I make
> using ZCO, he wonders why there is no built-in legend (I tried the
> legend_html ZPT, but ended up with some recurssion error), or no easy
> way to tick layers on/off, or no easy zoom within a bounding box that
> you draw on screen and no easy way to just click on a point and get 
> some
> info.  I know this is the whole point of our efforts, but there are 
> ways
> out there to allow one to provide a feature rich and relatively
> responsive UI (e.g. Chameleon).  I know everything is pretty much there
> in terms of scripts to do that in ZCO and that's why I think a little
> JS/AJAX into the mix could suddenly make PCL/ZCO a compelling web
> mapping development environment.  People would go nuts (my boss 
> would!).
>
>
> I am not too worried about AT content types (we should wait for Plone
> 2.1 anyhow; see below).  I think it would be a matter of setting up a
> BaseGeoContent schema which would derive from the Base schema and add
> whatever attributes we need to turn a plain content type into a
> geoenabled content type (e.g. a "geometry" property coupled with a SRS;
> a bbox ??) or turn a plain directory into a geoenabled container by
> defining a BaseGeoFolder schema deriving from a BaseFolder.  I think
> ideas should fall into place readily (I hope).
>
> I am more worried at things like Google maps that will spoil people for
> its zooming/panning capabilities.  Of course, you can't draw a specific
> zoom level and you can't compose the map with a choice of layers, but I
> think Google Maps sets the bar for UI responsiveness irrespective of 
> the
> fact it is hitting image caches all the time to simulate dynamic map
> generation.
>
>>> It seems to me that what we may be lacking is a site on which to
>>> collaborate.  I could set up a Plone instance on my zcologia.org site
>
>>> for this purpose.  Yves, which version are you using at work?  Should
> I
>>> wait until the 2.1 release?
>
> I think it is a neat idea to have a common demo Plone web application.
> IMO, we should indeed wait the 3-4 weeks left for plone 2.1 to come 
> out,
> as the current version of AT in Plone 2.0.5 is useless.  I believe the
> power of Sarissa (used by Kupu, which will become the default editor in
> Plone as of 2.1) for AJAX and other neat stuff like the default content
> types in Plone being AT will make Plone 2.1 a much better platform to
> develop a Plone mapping product on top of.  I am relying also a lot on
> better group integration, as my needs and I believe the needs of a 
> great
> many people revolve around group memberships and permissions.
>
> As you know, I am conducting AJAX experiments at the moment.  I meant 
> to
> start working on AT content types, as I said in my previous email, but
> really users want a nice and slick UI first !  Nothing I can do about
> it.  So, if only seasoned JS/AJAX programmers out there could take a
> look at the code I am playing with and enhance it (e.g. include it in
> Plone template macros for example), I believe we could have a basic 
> AJAX
> implementation of what I referred to in my previous mail as "Data 
> Access
> Utilities", that is click on a point in a map and get some attribute
> info, a plot of measurements, etc.  Heck redrawing the map could be 
> done
> with an XmlHttpRequest object altogether I believe!
>
> I will point you and other people to my AJAX demo site when I have
> something  somewhat presentable.  I hope people better at JS and ZPT
> plumbing than I will want to look at the code and enhance it so we can
> form a responsive web mapping application.  IMO, the work on content
> types will be facilitated by progress on the UI side.
>
> Thanx again for stimulating this community !
>
> Yves
>
>