[Zope3-dev] Re: questions about ZConfig and ZCML

[Philipp von Weitershausen]

Kent Tenney wrote:
>> Define what? Routines?
> 
> Define parameters of a fancy frame for photos, images or text block.
> 
> <ImageFrame>
>   width 50
>   outsidecolor #ccffff
>   insidecolor #660000
>   cornerstyle miter
>   size (700, 550)
>   style gradient
>   content c:\temp\test.png
> </ImageFrame>
> 
> this generates 4 side images and 4 corner images
> which form a frame which blends from outsidecolor
> to insidecolor. The html snippet puts the images
> into a table, the content is placed in the center cell.
> 
> Currently I just create them manually,
> Eventually I'd like to be able to generate them dynamically,
> based on context.

I see. I guess whether to use ZCML or ZConfig for this problem is just a 
matter of taste. In Zope3, we'd use ZCML. You would simply write your 
own directive schema and a handler for the directive. This is documented 
for example in Stephan's Zope3 cookbook which is available online at 
http://dev.zope.org/Zope3/Zope3Book.

>>> At some point I'd like to port this code to Zope3, which seems
>>> all about ZCML.
>>
>> and about ZConfig too. The server components, as you already dug up 
>> using google, are configured through ZConfig, much like in Zope 2.
>>
>> However, the wiring of components which by themselves are only loose 
>> objects floating around is done through ZCML.
> 
> I've heard that Zope3 will make it easier to use
> code which was not written specifically for it.
> 
> Is that what you mean by 'loose objects floating around'?

The idea is what you divide responsibilities into different objects 
which we call components. Doing so you don't depend on a certain 
implementation of components. Instead, you look up components by 
functionality. If you want a component that resizes images, you look it 
up by the functionality it provides (resizing), not by importing a 
certain class from a certain module. That is the loose part.

Of course, the lookup has to happen somewhere. The Zope3 component 
architecture provides a few essential services for this (in the 
zope.component package): utilities, adapters, views. In order for the 
lookup to work, you have to register the components. That's where ZCML 
comes in.

Now, for interfaces. These are not to confused with "user interfaces". 
Interfaces are meant more like Java interfaces. They are pieces of code, 
like classes or functions. They describe what kind of functionality a 
component provides. That is why they are so essential because, as 
mentioned above, components don't depend on certain implementations, but 
on functionality, meaning interfaces.

>> A very Zope3ish interpretion of your problem would have the following 
>> solution:
>>
>> You have several content objects
> 
> Is a *content object* Zope3 terminology for code which
> returns page content?

A content object holds data. All it knows about is how to store and 
retrieve data. It does not know about pages or any other form of 
presentation.

>> that provide image data, for example described in the interface IPhoto.
> 
> Is an *interface* code which is called from the page (ZPT?) and
> in turn calls the content object?

See above.

>> You need to provide HTML snippets for the images, so you have a 
>> browser view
> 
> Is *browser view* Zope3 terminology?

Yes. A browser view is a component that presents content objects; they 
turn the raw data provided by them into something that a browser can 
understand. Similar, an FTP view does the same for FTP clients...

>> for IPhoto objects 
> 
> I understand IPhoto, as an Interface, to be sort of
> a wrapper around the content object, which I understand
> to be what I'm currently working on (ImageFrame).

No, you're again understanding interfaces as in 'user interfaces' or 
'management interfaces'. They do not mean presentation. Interfaces are 
contracts about functionality.

The wrapper you're talking about is a view. Views provide presentation 
of objects.

>> You also have a browser view that actually gets called when an IPhoto 
>> object is supposed to be presented.
> 
> I would expect 'browser view' to be ZPT, the presentation
> component of the Zope technologies.

ZPTs provide one way to make browser views.

>> a request variable, that view might also want to resize the image 
>> first. For that, it uses a utility of the kind IImageResizeUtility.
> 
> I want to implement PDF version of framed images, which
> would be IPDFPhoto ... ?
> called by a 'click here for a PDF version of this image' button ... ?

You would want a browser view for IPhoto (components rely on interfaces, 
not the implementation!) that converts the photo to a PDF and sends that 
to the browser.  The PDF conversion can be done through an adapter, for 
example.

>> Something like this has already been implemented in Zope3, a port of 
>> the CMFPhoto product. It has not been kept up-to-date, unfortunately, 
>> but you can look at the source code in the old CVS repository: 
>> http://cvs.zope.org/zopeproducts/photo >
>> Most of that code is still valid and especially the ZCML part 
>> (configure.zcml)
> 
> http://tinyurl.com/4m9zb
> OK, this is in the thick of it. It looks like a pretty solid
> understanding of the Zope3 architecture is required to make
> sense of this.

The recommended reading is the Zope3 cookbook, or, if you're looking for 
a step-by-step introduction the work I'm currently putting together.

>> might be useful for you to look at. Note that this interpretation 
>> makes this problem not so much a question of whether to use ZCML but 
>> whether to use the Zope3 Component Architecture or not.
> 
> I'm hoping to keep working on my code with an eye to
> at some point incorporating it into the Zope3 Component Architecture.
> 
> I'm fairly convinced that the smart money is on Zope3.

I'm glad that you see it that way.

Philipp