[ZMapServer-Developers] Fwd: Beginning of a quick hack for ZCO properties

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

Begin forwarded message:

> From: "Moisan Yves" <ym...@gr...>
> Date: March 10, 2005 7:46:54 AM MST
> To: "Sean Gillies" <sgi...@fr...>
> Subject: RE: Beginning of a quick hack for ZCO properties
>
>> And my preference would be that this would be displayed within its =
own
>> tab, maybe named "Cartography"?  This tab would be the 1st and =
default
>> view within the ZMI.
>
> +1
>
>> Extra goodies to consider would be a layer preview (ala
>> layer/viewLayer) right in the tab or a depiction of symbolizers.
>
> Let me verbalize how that would work.  If I understand, clicking=20
> "View" simulates a browser request, which boils down to calling the=20
> index_html method or else an index_html object if one is defined.  For=20=

> example, I have this hierarchy :
>
> test/layers/ZCOLayerObj/ZCOStyleObj
>
> If I press the "View" tab when I am at the ZCOStyleObj level in the=20
> ZMI, I get the index_html object that is defined up in the test folder=20=

> but the objectWithProperty script that lives in index_html gets=20
> executed in the context of ZCOStyleObj.  Since there is no object that=20=

> has a Datastore property at that level, I get an empty table.
>
> If I hit the View tab in the layers folder, I get to see all the=20
> objects in that folder that have a property "Datastore" (that's where=20=

> all my layers are so for sure a lot of objects show up in the table)=20=

> so indeed the index_html template acquired by the test object executes=20=

> the objectWithProperty script in the context of the layers folder. =20
> Exact same thing as layer/viewLayer.  Only this would be the default=20=

> view and not the "View" tab.
>
> Now, I think an advantage of having things in a ZPT is that we can=20
> define macros or assign the output to a portlet (e.g. fill-slot could=20=

> be other than "main", e.g. "preview_slot") because one day or another=20=

> we'll have to get out of the ZMI and go to the "User" UI.
>
> When at that level, what I would really crave for is some elegant way=20=

> of defining "profiles" where we could store default values for layers,=20=

> styles ... that could be tied to users or better yet to groups of=20
> users (I think the next version of Plone will have yet better support=20=

> for groups).  For example, department X wants its users to see some=20
> default map (in a specific layer order, styles, default bbox ...). =20
> Users could acquire such a profile by virtue of being group members=20
> but could potentially override the default group values and make their=20=

> own profiles and eventually share them amongst other users in the same=20=

> group (or even with users in other groups, but that would probably=20
> require some sort of "deep copy" to get all the acquired properties of=20=

> the group to be transferred over to the other group).
>

Perhaps we should look at using the OGC's web map context spec for use=20=

in such profiles.

> Heck, it could even be possible to put together a Plone CMF UI similar=20=

> to uDIG : map in the center and a bunch of surrounding portlets!  That=20=

> contradicts a bit my previous email to Ka=EF where I argued the map=20
> should be displayed in a "side portlet" and not in the main one, but=20=

> I'm slowly making up my mind that mapping, even though it really is=20
> another way to represent data and as such should be displayed in a=20
> "satellite portlet", is complex enough to warrant its own environment.=20=

>  I am more and more thinking of implementing mapping in Plone as a=20
> separate Plone site instance altogether, the idea being that a "map"=20=

> portlet in my main (content) site would spawn another browser window=20=

> altogether.
>
> For the preview tab, I think it would not make sense to duplicate the=20=

> "view" tab, that is have a "Preview" tab that calls the exact same=20
> machinery called in by the "View" tab.  I wonder if some sort of=20
> cached image could be used instead?  Since we are not in a general map=20=

> context (IMO, you would press the "View" tab in the right location for=20=

> that) and it's just a matter of showing a line style for example, the=20=

> preview could just focus on presenting a "thick red dotted line".  My=20=

> point is to avoid the overhead of calling in the whole map generation=20=

> machinery, but I don't know how useful that would be.
>
> Cheers,
>
>
> Yves
>

Yves, I agree that we should not override the normal behavior of the=20
"view" tab.

cheers,
Sean