manipulators and model inheritance refactor

[GoogleCodeExporter]

Seeing if this fits into the milestone. Sorry, more info coming soon.

Original issue reported on code.google.com by underbluewaters on 8 Apr 2010 at 3:32

[GoogleCodeExporter]

Original comment by underbluewaters on 8 Apr 2010 at 3:33

[GoogleCodeExporter]

not an issue if this bleeds into 1.4

Original comment by underbluewaters on 8 Apr 2010 at 3:39

[GoogleCodeExporter]

The point of this ticket was to make time for addressing the shortcomings of 
model inheritance, possibly avoiding the 
problem by just making it very easy to make the functionality that needed to be 
reused (integration with client side forms, 
manipulators, etc) easy to apply to arbitrary models. I consider my early 
decision to handle MPAs and Arrays with model 
inheritance a mistake, even though it works okay, it causes aggravation. If 
there is a better way, I'd rather address the 
shortcoming sooner rather than later.

There was no time in 1.3, and it doesn't makes sense to just dive into this 
without more consideration. In the dev meeting I 
set aside some time to talk about this issue. I was hoping we could revise this 
ticket so that you(Matt) could do some 
examination of how easy it is to handle user shapes with a different model when 
working on the Cumulative Impact App. Is 
it easy to hook into the REST framework? Easy to apply manipulators to limit 
drawn shapes to the extent of the California 
Current dataset? What bugs you about the process?

Then Scott I was thinking you could spend part of the time walking through how 
to create new manipulators and then apply 
them to new models.

I could then describe how the REST framework works with it's generic urls, kml 
documents with behavior describing links, 
and the kmlEditor component.

I'm hoping by the end of this meeting we would have a good idea of whether or 
not these components add up to an easy to 
apply "Spatial CMS". If not, we'll know how to get there. I'm hoping it's just 
a matter of better documenting what we have, 
simplifying a couple APIs, then ditching the base MPA/Array classes in favor of 
just quickly creating new models in projects.

Original comment by underbluewaters on 17 May 2010 at 10:38

• Added labels: Milestone-1.4, EstimatedTime-40
• Removed labels: Milestone-1.3, EstimatedTime-120

[GoogleCodeExporter]

Original comment by underbluewaters on 17 May 2010 at 10:39

[GoogleCodeExporter]

I think we should close this as the "Spatial CMS" concept really has little to 
do with model inheritance refactoring and manipulators. The manipulator 
framework was shown to be flexible enough to work with other spatial models as 
is. In terms of implementing the spatial CMS idea, Chad's example of using a 
special decorator and class Meta to define the behavior of spatial models seems 
the way to go.  

Chad - will you open up a bug report with some more details on your spatial CMS 
idea?

Original comment by perrygeo...@gmail.com on 16 Aug 2010 at 10:19

• Changed state: Invalid

[GoogleCodeExporter]

I'll work on creating that new ticket for the Spatial CMS/Multiple Feature 
Classes idea.

Original comment by underbluewaters on 23 Aug 2010 at 5:13