El vie, 16-03-2007 a las 13:18 -0500, Justizin escribió: > On 3/16/07, Manuel Saelices <[EMAIL PROTECTED]> wrote: > > Simply I think Zope 3 is not the best way to pythonize Plone... > > Plone was always Python, so I'm not sure this makes sense, but I see > the direction your concern is headed.
First, sorry in advance for my english... it's very bad :_( Zope 2 is not "pythonic". Zope 3 I think neither. > > > Ok Plone it's based in a complex Zope 2 with its hierarchy and so, but > > Zope 3 it's not "agile" for development. I developed both in Plone and > > Django [1] frameworks (three years and one year respectly), and I > > several times have to choice a solution for a web development. I usually > > do that: > > > > * If customer want a fully collaborating CMS with many features (chat, > > forum, versioning, etc, etc, etc.) I choose Plone for that, because > > there are many products developed. > > > > * If is a specific web application (or CMS) like a stock manager or so, > > I choose Django, of course, because: > > - It's more agil and productive > > - It's transparent to the developer (It doesnt do too "magic") > > - It's lighter, more flexible and speedier [2] > > - Plone is more complex for beginner. It need several month and a > > special capacity for that. > > > > Of course, Django It's a framework and Plone it's a CMS, but the fact > > it's not agile, and it's becoming less and less agile with Z3 > > integration. Z3 is overcomplex with adapters, ZCML, and things so. > > adapters are actually quite simple, they solve problems of > over-reliance upon multiple inheritance. if you aren't having trouble > with multiple inheritance in django, you make it sound very > non-object-oriented, which some people thing is a good thing, though I > don't. I think interfaces are a good thing for make a component based application... adapters are good in idea, but it usually ends in a too complex application (ok, depends of programmer). > > I don't know that you could develop something like Plone with Django, > or that Django approaches many of the use cases. Of course Plone can be developed in Django, as in RoR... but Django is different like RoR: cleaner, modular, easy templates, etc. But I don't mean to develop Plone with Django... I only want to express my opinions about simplicity of software. > > > Agile mean: > > Many of us are familiar with: > > http://agilemanifesto.org I know agilemanifesto.org... ok: * Individuals and interactions over processes and tools: simplicity made better interactions. * Working software over comprehensive documentation: i think comprehensive code it's more important that comprehensive doc. I don't think to have many places to define a funtionality (ZCML, .py) are good. You have to write in four or five places to define a view, event or interface (grok eliminate this). * Customer collaboration over contract negotiation: it's depend about metodology, for example we open project (Trac, SVN, etc.) for our customers. This is not talk about tecnology. * Responding to change over following a plan: if customers changes requirements and said you "ZODB off... all news on postgresql (even ReferenceFields)" ¿What do you do? Ok, I think Plone That is only a manifest about "agile metodology" (to be prepare about changes, instead of make a perfect planning, that is not posible), but I talk about "agile development". I invite you to see this video for my idea about agile development http://podcasts.plonetv.de/ep02/cltv02-mpeg.mov Plone is agile but in another senses: * hundreds of products easyly instalables * easy products (that tryes to hide complexity about Zope) * very flexible thanks to ZODB (schema evolution with AT, etc.) * XML configurations with GS But the problem is GS, CMFCore and Zope internals (I think in both 2 and 3 versions). > > > * rapid development: Plone has rapid development (many product, easy > > integration, flexible ZODB, Archetypes schemas, UML, etc.), but core > > errors can be fatal. Ok, its ocurs in Z2 and Z3. > > > > * rapid turnaround: time between detect an error, changing a line, and > > seeing error solved. > > - Product refreshing (maybe refreshng [3])? > > - Rapid or no restarting. What about better-web-app Sean Kelly > > video? > > > > * simplicity: ZCML and adapters are not the way to simplify Z2. Z3 > > tends to J2EE and I dont like J2EE. I love beauty and simplicity. > > Actually, z3 and J2EE both follow ideas like those promoted by the GOF: > > http://en.wikipedia.org/wiki/GOF > > I suggest purchasing a copy of "Design Patterns". It's freshman level > CS since the 90s. I like software patterns, like MVC, singletons, etc. But i'm pragmatical too, pattern is a pattern, you can use it or not. But I'm speaking about simplicity... ¿why is develop grok product? For this reason: DRY (Don't Repeat Yourself). And in many Zope 3 products there are repetitions. > > > For example, if you see this line: > > > > importer = queryMultiAdapter((obj, context), IBody) > > > > ¿What is the object class for importer (you maybe need to debug this)? > > You don't need to know the object class, you only need to know what > interface you are talking to. This is a widely accepted pattern for > solving dynamic typing problems, and is established, again, in > freshman-level CS literature. You anytime has needed to put a logging.info('I am here') on class that implements the interface ???? I think you have needed this. > > If you don't like dynamic languages, you might consider writing web > applications as Apache modules in C. ;) I love dynamic languages... I love python... and for this reason I love Django. I love Plone too, but the final result, not the foundation (zope): * publishing database objects in web ( http://server/obj/Title ) * complex ZPT (compared like django templates) * not pythonic (even in Zope 3) Ok, I don't said to change this... I'm confortable with Zope, Plone, ZPT and it's very productive if you has a very huge skill... but It's not simple. > > > ¿Is it intuitive that you have to search all ZCML for find next fragment > > for example in CMFCore/exportimport/configure.zcml? > > > > <adapter > > factory=".actions.ActionsToolXMLAdapter" > > provides="Products.GenericSetup.interfaces.IBody" > > for="Products.CMFCore.interfaces.IActionsTool > > Products.GenericSetup.interfaces.ISetupEnviron" > > /> > > > > ¿And previous fragment is intuitive for find > > actions.ActionsToolXMLAdapter class? > > > > More questions... Z3 is for "pythonize" Zope, but most of Plone 3.0 > > "python modules" has lines like that: > > Z3 is not for "pythonizing" Zope. Zope is Python, and Plone3 is not > written in pure z3. It has a goal of maintaining compatibility with > existing Zope2 addons, e.g. most Plone products. Ok I know that. I refer "pythonic" :_( > > > from Products.CMFCore.utils import getToolByName > > > > def __init__(self, request, base_url, view_url, items, ...): > > self.request = request > > self.context = None > > This specific usage is > > > You cannot use this from a separated python module, because request, > > context, tools, and things so. In general it's true that code is > > WSGI should make the request more generic in time. I challenge you to > write even a CGI script in Perl which doesn't have a request. You are > familiar with the basics of multi-tiered application architecture, no? Ok request and context is necessary, normally in View and part of Controller of a MVC paradigm. I only said in most cases It can do not use Plone 3 modules outside Zope. In other systems the percentage of "valid" python modules are better. For example, a model in django defined with django ORM like that: class Person(models.Model): name = models.CharField() age = models.IntegerField() def __str__(self): return self.name Can be used so: >>> from myapp.models import Person >>> p = Person(name='John') >>> p.age = 23 >>> p.save() --> does the SQL UPDATE >>> print p John This is simplicity: * convention over configuration (no XML, as Hibernate one) * simple API Ok zope 3 API its simpler that Zope 2, but I don't like adapters and ZCML, because In my opinion such kinds of things at the end complicate the system. > > > cleaner, but some Z3 ideas like ZCML and adapters are very ugly and > > complex your system. Remember: Java XML-mania for all its the worst > > option for beauty and productivity for programmer (specially if you > > don't have a wonderful wizard). > > Personally, I like doing XML sit-ups. All programmers can use a few > sit-ups now and again. My opinion it's like Sean Kelly in http://oodt.jpl.nasa.gov/better-web-app.mov . Zope 3 development with constant ZCML manipulation is like de screencast of "hello world" application developed in J2EE in previous video (about minute seven). > > XML-mania is not about Java at all, it's about XML, which is a human > and computer readable format based on standards. I've heard people > suggest S-expressions as an alternative, but Zope is primarily a > system designed for pushing out XML content. It's assumed that anyone > working with Zope would know a bit about XML. Ok I think XML knowledge it's important, but XML for human manipulation (or human development with XML) it's not as good as computer manipulation. That is for JSON exists: avoid needed to programming XML parsers (when you don't have needed of talk with externals applications). > > Honestly, the Apache config file format is about as nebulous and is > designed based on the same reasons. > > > I think django way [4] to make an agile development is a better way to > > go. With Django you can develop faster than RoR and resulting in a > > simple, beauty and pythonic system. Z3 architecture seems a J2EE > > system :_(. > > What don't you like about J2EE that you see in Zope? * XML overuse: python is a clean languague, Java is a "verbose" one... I think java people programming in XML cos is simpler than Java, but I think python is simpler than XML ;-) For example, this is the way of setup a django project: http://code.djangoproject.com/browser/django/trunk/django/conf/project_template/settings.py * ZCML complexity. For example, several days ago I want to compare forms in django and formlib in Z3. I try compare unit functional tests for this. - Look django form testing (based on doctests): http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/forms/tests.py (simple, readable, etc.) - Ok, I want to take a look in Z3 ones. First I went to this file: http://svn.zope.org/Zope3/trunk/src/zope/formlib/ftests.py?rev=72217&view=auto A fragment of this: from zope.app.testing import functional FormlibLayer = functional.ZCMLLayer( os.path.join(os.path.split(__file__)[0], 'ftesting.zcml'), __name__, 'FormlibLayer', allow_teardown=True) def test_suite(): errors = functional.FunctionalDocFileSuite("errors.txt") errors.layer = FormlibLayer return unittest.TestSuite((errors,)) First ZCML file... ftesting.zcml. Ok I look this file: http://svn.zope.org/Zope3/trunk/src/zope/formlib/ftesting.zcml?rev=72115&view=auto Fragment: <include package="zope.app.zcmlfiles" /> <include package="zope.formlib" /> Ohh... seconds and thirds ZCMLs... :-S ok I look at the others: http://svn.zope.org/Zope3/trunk/src/zope/app/zcmlfiles/configure.zcml?view=auto http://svn.zope.org/Zope3/trunk/src/zope/formlib/configure.zcml?view=auto More ZCMLs! After several minutes, I found that the secret was not follow ZCML because it's only for setup tests (ok it's not DRY). Then we follow ftests.py and see that: def test_suite(): errors = functional.FunctionalDocFileSuite("errors.txt") errors.layer = FormlibLayer return unittest.TestSuite((errors,)) With some "grep" and "ls -l" I found there be more tests on tests.py that on errors.txt: http://svn.zope.org/Zope3/trunk/src/zope/formlib/tests.py?view=auto Ok I found it :-) Now I see testing code... my impression was there was more and more complex that django ones, for example with formSetup function and component.provideAdapters. I can give you many other examples of Zope 3 complexity. I think the way is simplify if you can, and DRY in 90% cases. In the others 10 of system that requires a over using of adapters, ZCML etc. you can use that, but not for normal case. > > > Maybe grok [5] way can be the best option for Plone in this moment... or > > a Plone like CMS built over Django ;-) > > Again, I don't think you could build something like Plone based on > Django. Plone and Zope use a complex application architecture in > order to be accessible to users at various levels, and to avoid > requiring them to understand the details of each others' territory. I think this requirement can be done in a simpler way. I think you can build Plone perfectly with frameworks like django, but ok it's a hard work because Plone has many functionalities. We have a django project that bit-a-bit is becaming in a light CMS (workflow, versioning, etc.) > > If you always develop alone, maybe that separation of roles is complex > for you, but it can deliver a lot of value to your customers, esp if, > say, you are hit by a bus. I don't develop alone, and find people with a skill for Plone and Zope 3 development is not easy. It is for complexity about systems. > > Having played a significant part in the development of some python > frameworks / environments for web development before working with Zope > or Plone, I see Django and similar frameworks making a lot of mistakes > I am happy to have left in my past. For example? > > I do think there is a strong movement in the Plone and Zope > communities to move toward standard Python packages, but I think > Plone-the-application is always going to contain some code which is > only for Plone. > > That's what applications are. ;) > > $0.02 > > Ciao > -- Manuel Saelices [EMAIL PROTECTED] ICS Yaco S.L. http://www.yaco.es/ C/ Sierpes 48, 41004 Sevilla Teléfono +34 954 50 00 57 Fax +34 954 50 09 29 _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
