[Community] PrimaGISDatalayer: trouble withdatastores thatarenotinthe DL folder

[Kai Hänninen]

Ludwig M Brinckmann wrote:
> Right.
> 
> 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 
development cycle?

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 
without it.

cheers,
Kai


> 
> L.
> 
> 
>> 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 
>>> compatibility)...
>>
>>
>> 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.
>>
>> cheers,
>> Kai
>>
>>
>> -- 
>> 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
>> http://lists.gispython.org/mailman/listinfo/community
> 
> 
> _______________________________________________
> Community mailing list
> Community at lists.gispython.org
> http://lists.gispython.org/mailman/listinfo/community


-- 
Kai Hänninen                  +358-50-558-7935
Software engineer             www.mbconcert.fi
MB Concert Ky                 kai.hanninen at mbconcert.fi