[Community] PrimaGISDatalayer: trouble withdatastores thatarenotinthe DL folder
kai.hanninen at mbconcert.fi
Tue Jun 20 16:10:23 EEST 2006
Ludwig M Brinckmann wrote:
> I personally think you can be more audacious in removing legacy stuff:
> it creates vast amounts of work that is difficult to test and something
> along the line might break existing systems anyway. While a clean
> upgrade is nice, sometimes being forced to do things again is a good
> chance of throwing out clutter and things that were (on my side) a bit
> hacked together...
I'd love to raise the bar to Zope >= 2.8 and Plone >= 2.1 :) I had hoped
to get 0.6 out of the way fast, but it has not turned out that way.
Leaving Zope2.7/Plone2.0 behind would make things a lot easier and
ensure a faster 0.6 release too.
I'm not sure if anyone besides our company is even using PrimaGIS on
Plone 2.0 anymore. I did a poll some time ago and nobody came forward
requesting plone 2.0 support at time, iirc.
Does anyone have any comments on this issue? Ditching Zope 2.7 / Plone
2.0 support for the next (0.6) release for PrimaGIS at this stage of the
I'm willing to keep my word for supporting the Zope2.7/Plone 2.0
platform, but if nobody needs it, then I'd be happy to go forward
>> From: Kai Hänninen <kai.hanninen at mbconcert.fi>
>> Reply-To: "gispython.org community projects"
>> <community at lists.gispython.org>
>> To: "gispython.org community projects" <community at lists.gispython.org>
>> Subject: Re: [Community] PrimaGISDatalayer: trouble withdatastores
>> thatarenotinthe DL folder
>> Date: Tue, 20 Jun 2006 15:36:52 +0300
>> Ludwig M Brinckmann wrote:
>>>> I agree that the instruction could be improved. I've been thinking
>>>> about deprecating the use of "." in favor of leaving the field just
>>>> blank it the data is stored within the layer. (I'll leave the "."
>>>> support there for backward compatibility of course).
>>> I would not worry too much about this: as long as the instruction is
>>> clear. Most people will have had some exposure to scripting and are
>>> familiar with the .
>>>> I'll look into this part and write some unit tests for it. I think
>>>> that the most intuitive way is to have it relative to the datalayer
>>>> instead of the map. You agree?
>>> I agree ...
>>> ... in principle.
>>> I think there are two use cases:
>>> 1) one group of users will want to keep the data within the data
>>> layer - just to have everything in one place. This should be done
>>> easily, with or without .
>>> 2) the other group will want to separate the data out. I cannot think
>>> of a real situation where an absolute path (provided that is
>>> consistent with common sense: relative to Plone root) will not do,
>>> and actually something is gained by a relative path unless you
>>> consider the situation where people move parts of folder trees around)
>>> In that sense the relative path is syntactic sugar, it does not
>>> increase what you can do with the map. Implementing a good solution
>>> will make you happy, but will not make much difference to a user.
>>> (But since you implemented it, you will need it for backwards
>> I forgot to say that the whole "manually written path" thingy is only
>> for backward compliance with Plone 2.0.x.
>> With Plone >= 2.1 we have ATContentTypes as the default portal types
>> and the whole thing can be replaced with a reference to a folder and
>> users get to use the nice ATReferenceBrowserWidget. This gives the
>> additional benefit that the folder containing the data can be moved
>> freely within the site without breaking PrimaGIS.
>> Now that I think of it, I could do this already for 0.6 and simply
>> degrade to the "manual path" model that we have now for Plone 2.0 users.
>> In the long term I'm planning on deprecating PrimaGISDataLayers
>> alltogether since they sort of sidestep ZCO. ZCO should provide all
>> the ZODB based data stores and PrimaGIS should just use those and
>> concentrate more on the mapping interface.
>> Kai Hänninen +358-50-558-7935
>> Software engineer www.mbconcert.fi
>> MB Concert Ky kai.hanninen at mbconcert.fi
>> Community mailing list
>> Community at lists.gispython.org
> Community mailing list
> Community at lists.gispython.org
Kai Hänninen +358-50-558-7935
Software engineer www.mbconcert.fi
MB Concert Ky kai.hanninen at mbconcert.fi
More information about the Community