oship-dev team mailing list archive

[Diego Manhães Pinheiro <me@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Em 24/10/10 09:55, Tim Cook escreveu:
> Hi All,
> This question is primarily for Diego but there may be others with
> experience in this area.
> 
> Django is a VERY popular python web framework.  However, it is
> completely tied to a SQL database centric approach.  Which of course we
> all know just will not work well with our hierarchical model.  
> 
> There is an adapter for Django called django-zodb (oddly enough <s>)
> http://triveos.github.com/django-zodb/ 
> 
> There are also efforts to use NoSQL databases (CouchDB, Riak, Hadoop,
> etc.) which I applaud and would like to look at for future versions of
> OSHIP.
> http://www.allbuttonspressed.com/blog/django/2010/02/4-things-to-know-for-NoSQL-Django-coders 
> 
> So my questions are; 
> 
> 1) what would need to be adapted, just in the reference model, to make
> it work with django?  
The answer is: Make the code framework agnostic as possible. In python,
business objects are entangled with framework technology on most of the
cases, which is bad. In the python environment, this is almost
impossible create business objects without compositioned objects that
made part of a framework. Perhaps the ZODB is unique the persistent
mechanism that allow use a simple python object to store data. Now being
specific to the OSHIP situation, If we use the persistent class on the
top of the inheritance tree of the OSHIP classes, I'm confident that the
code will work on any ZODB integration effort.
To tell the truth, hardly any part of RM define zope components using
the grok framework directly, so at the moment I don't see any problem
on RM to use with django. Of course I have to see carefully to make a
perfect conclusion.

As a second step, would be separate the presentation layer from the
business layer on different packages. At the moment, presentation is not
our goal, so this discussion can be postponed.
> 
> 2) would we need to have a separate copy of the RM to work with django
> or could some kind of adaptation be put in place?
I hope not. If the presentation logic is separated from the business
logic, I believe just a few integration details will be necessary.
> 
> I want to say that I am in no way supportive of abandoning the Grok
> approach.  There are many many robust tools we have with Grok (and the
> ZTK) that do not even exist for Django. Much less have the stress
> testing that the ZTK world has on those modules. 
> 
> My idea is to just tease those Django developers enough to start using
> the RM so they see the benefits.  Then they can switch. :-)
Using the ZODB, I don't expect any problem to use diferent frameworks. :)
After finish the RM, this will be on my TODO list. :)
> 
> Cheers,
> Tim
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~oship-dev
> Post to     : oship-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~oship-dev
> More help   : https://help.launchpad.net/ListHelp

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iQEcBAEBAgAGBQJMybFYAAoJEEfarWn4YOc8WsQH/iz80cxOZYH3nABgiyqH8qGn
FmB9vT+qqzGI2PkSny6s1j8cOVO5cZjobX0kcQqUDBjNq6niVEl4OqbGgn7T9rRt
ekZj2jPBA0+AeAMPFQfaOn9WkVowzRbbF0kuGIvX3Zpsqjuqzz1mHvsmZ1Ms0Gvc
aBO+oge2l01UekMCd4v3KYpp2+sIoPEpBHVv3SVutPKSRzQx6wv5vvRgx2CHuaVh
Ao0XbKW6RkhdozDTt6N3UKFWxruRUA32ngn43amaerIQDFzjaGQFNCe1xyY5z/VK
e8BvBkqinpT0Bnj8sjt4xK+tOI4MkCu3zRfGx03w1h4qeUNr5H2zS1Ohgm6mMRo=
=fvI2
-----END PGP SIGNATURE-----