[Zope3-dev] Re: ZCML

Jeffrey P Shell jeffrey at cuemedia.com
Wed Aug 20 14:02:29 EDT 2003


On Monday, August 18, 2003, at 02:49  PM, Stephan Richter wrote:

> On Monday 18 August 2003 16:29, Shane Hathaway wrote:
>> I understand, though I think it's unfortunate.  I find it quite
>> difficult to read or write ZCML, and as a result, I haven't worked on
>> Zope 3 for a long time.
>
> I find ZCML really easy to read and write. I have usually no troubles 
> finding
> anything or adding something.
>
>> Rather than complain about it, I did some experiments with 
>> configuration
>> syntax in the Ape project, and I'm quite happy with the results.  I
>> think Zope 3 could benefit from the things I learned.  But maybe the
>> group isn't ready to listen now.
>
> From your previous comments I gathered that you simply take a different
> approach and I agree with some others that I do not like it that much. 
> I
> prefer attributes instead of tag elements.

Attributes are well and good and brief if you're always going to be 
maintaining ZCML by hand.  But if you were to introduce XML tools into 
the mix, I imagine that they would produce XML elements that are all on 
a single line and, as such, could be very difficult to tweak when a 
site is deployed on a bare bones server where 'vi' will support your 
cursor keys if you're lucky.  I think that ZCML will not work well with 
XML tools if we intend to keep it readable when viewed in 80 columns 
(which is a very worthy goal).

This especially applies to ZCML attributes whose values are whitespace 
delimited words that can end up spread out over multiple lines.

I'm very unfamiliar with the Java systems, but I can often read example 
'web.xml' code (used to configure servlets, taglibs, pages, etc) much 
more easily than I can read even well formatted ZCML.  Well formatted 
ZCML isn't bad.  But I still find these other systems easier to deal 
with.

I just hope to hell there's excellent reference material.

> Note also that ZCML is extremly modular at this stage. You simply 
> define a
> schema that describes your directive and then make a meta directive
> implementing the directive. It is super easy and really nice.

I think that 'simply' needs to be simply removed from the vocabulary of 
all developers.  Beyond that - the modularity is nice.  I'm looking 
forward to it for some of our projects.

Speaking of ZCML.  A few months ago, I had an issue with using ZCML to 
extend another product.  (Oooo.  And I should take advantage of this 
opportunity to state - again - that I hate 'zopeproducts').  I was 
defining some new views and components that augmented the behavior of 
the other.  But I needed to refer to resources (it might have been an 
icon reference) in the original, and I didn't want this to be path 
based since one never knows where components are installed (unless 
they're all foolishly locked inside of 'zopeproducts').  Was there a 
final concensus on how to deal with that?

Like if I was extending bug tracker and had "RelativeBugTracker", but 
needed to refer to a file in the original, how would I do it?  I think 
the concensus was something based on package_path:file_path, ala:

   <icon
       name="zmi_icon"
       for=".interfaces.IRelativeBugTracker"
       file="zopeproducts.bugtracker.browser:tracker_icon.png" />

(it may not be the best example, as IRelativeBugTracker would extend 
the IBugTracker interface, and I assume that if I didn't define an icon 
that the IBugTracker default would take its place...right?)

Jeffrey P Shell, jeffrey at cuemedia.com




More information about the Zope3-dev mailing list