[Zope-CMF] Compound elements status

03 Apr 2002 19:39:39 +0100

On Fri, 2002-03-29 at 17:07, Chris Withers wrote:
> seb bacon wrote:
> > 
> > When you display a page with its 'view' action, you want to display each
> > of its components according to their 'view' action.  How about if you
> > have a 'view comments' action for a page, which puts some copy at the
> > top regarding comment threads, and then displays each component with its
> > thread beneath.  Then you need a way to map between the container's
> > action and those of its components.  This can only be done in a 'slot'
> > type definition.
> 
> Huh? Ya lost me... take it slow... I suspect it may not be necessary ;-)
> 

OK, so you have a page with some components on it, say two images and a
text box.  You want to display them diffently according to the action
that the current page templates is being viewed with.  For example, in
the page actions menu you might have "View page in Quiet Mode" and "View
page in Noisy Mode".  Quiet mode dispays just the component, and noisy
mode displays it with all its metadata, for the use of site managers. 
Of course you could do this by embedding the different views in the
template, but it is nicer to ask the components to know how to view
themselves.  You thus have a single template definition:

<html>
 <image tal:replace="here/image_1" src="placeholder.gif" />
 <div tal:replace="here/text_1">Some text</div>
 <image tal:replace="here/image_2" src="placeholder.gif" />
</html>

And you have the image / text components themselves own the two views
('quiet' and 'noisy').

Now you need a way of telling image_1, for example, which view to
display.  I think the correct place to do this is in the Types tool.

> > Also, if you have slots with named components, you get to define the
> > layout of the page accurately ('image_1 goes here, text_3 goes there'),
> > which it is hard to do when the components are looped over in a repeat
> > clause.  Of course you could extend the interface with CMFArticle to
> > allow you to name elements; however, the user would then need access to
> > the page layout source too.
> 
> Urm, ZPT is a pretty good templating language. I don't see why whoever needs to
> lay out a page can't do it with a simple ZPT:

Right, that's exactly what I mean.  But ZPT can't do it if you're
looping over unspecified components.  You need to know *in advance* what
components you are going to get in your page, in order to refer to them
by name.

> 
> > A separate design consideration is that it would be nice to be able to
> > recursively compose components.  What I mean by this is the following:
> > suppose you have a type which has two fixed slots, "image" and "text".
> > These are displayed in the default action with the text on the left and
> > image on the right.  Wouldn't it be nice to be able to add these two
> > elements as a single "textandimage" component to another template?
> 
> Yup, but I don't really see why you need slots for this?
> 

Quite, that's why I said "A separate design consideration" :-P

> > Another consideration is that it would be nice to be able to use any
> > existing Types as components without having to tinker with their source
> > code: it should be possible to create new 'articles' (I call them
> > 'templates') through the web.
> 
> ...indeed. But I don't see how you're gonna lay out a page properly without
> writing some HTML, and if ya gonna do that, why not use a ZPT?

That's what I'm suggesting - slots only solve the problem of having
known, named components, you still need ZPT (or DTML if you like) to lay
them out.

cheers,

seb