[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