[Product Developers] Re: [Plone-developers] The damned ZCML, adapters and Z3... some thoughts

Manuel Saelices msaelices at yaco.es
Sat Mar 17 17:46:47 UTC 2007


El vie, 16-03-2007 a las 13:18 -0500, Justizin escribió:
> On 3/16/07, Manuel Saelices <msaelices at yaco.es> 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
msaelices at yaco.es

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







More information about the Product-Developers mailing list