[Zope-CMF] Making a CMF Document render DTML

Jean-Francois.Doyon@CCRS.NRCan.gc.ca Jean-Francois.Doyon@CCRS.NRCan.gc.ca
Fri, 20 Sep 2002 12:18:47 -0400


Jeffrey,

Agreed on all counts!

I'm just hoping someone has done this before, or can help me figure out how
to :)  I'm not a big product developper and don't know the Zope code all
that well.

So I'm perfectly willing to do this work and share it, but I don't know
enough to get it done right now :)

So I've tracked down the HTML module form the Globals package, that seems
should do what i want.  But not knowing the inner workings, I wonder, would
I be better off using DocumentTemplate instead? Then there's these "client"
objects I'm not too sure about ... and so on ...

I suppose I could simply wrap a DTML Method into a CMF type, but
unfortunately it's too late for me (My content allready exists in CMF
Documents), and I'd rather simply change the Document type (CookedBody) to
do what I want. (I know, there's a million reasons I shouldn't do that!).

I suppose I'll eventually figure it out, but I'm going to suffer terribly in
the mean time, so I'm hoping someone out there can give me some pointers (Or
has done this allready).

Cheers,
J.F.

-----Original Message-----
From: Jeffrey P Shell [mailto:jeffrey@cuemedia.com]
Sent: Friday, September 20, 2002 12:02 PM
To: Jean-Francois.Doyon@CCRS.NRCan.gc.ca
Cc: chrisw@nipltd.com; zope-cmf@zope.org
Subject: Re: [Zope-CMF] Making a CMF Document render DTML


I think it's a valid need, one that could be solved a myriad of ways.  
I don't think DTML (especially since this purpose of DTML is on its way 
out) based "CMF Documents" should be part of the core product, but it 
shouldn't be too difficult for you or someone to write a third party 
product that defines a 'CMF DTML Document' content type, and have that 
get integrated into the CMF.  The Default Document type is pretty bone 
simple (and similarly - needlessly complex) - but the key word is 
'Default'.  It's meant to be replaceable by something that better suits 
your needs should you or someone else write the code to do it.


On Friday, September 20, 2002, at 09:03  AM, 
Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote:

> Because having a single template applicable to all documents is too
> restrictive.  I want people to be able to contribute documents, and 
> take
> advantage of the workflows, but not all documents will have the exact 
> same
> layout.  In fact there's now way for me to predict what document 
> authors
> might want. BUT I do have a template that does some stuff, like the
> consistent look of the site, BUT, I do no want to dictate every detail 
> of
> the layout.  Authors have to be able to decide whether they want an 
> image
> justified left, or right, and so on. Currently this is all done by 
> putting
> HTML inside the CMF Document, which is fine.
>
> The problem is that, in this particular case, we have tables that 
> appear all
> over the site in various documents (And featured items, and news 
> items, etc
> ...).  Right now these are done as HTML inside a CMF Document.  BUT it 
> would
> make a whole lot more sense to make these tables as re-usable 
> components
> (lists, formatted search results, whatever).  The problem is that I 
> cannot,
> should not, and will not dictate where document authors can/should put 
> these
> tables/lists in their documents.

Another solution here would be to make different content types to 
handle tables, or other items, that present a nice editing interface 
for what they represent.  Or to use something like CMFArticle (or FDoc, 
if I can ever make time to put together a release) which are composite 
document based solutions - where a document is more than just a big 
block of text and is instead built out of smaller units representing 
text, images, etc.  But, to get the sort of results you're wanting, you 
may still need to write a fair amount of custom code to fit into the 
framework.  But that is the point of a framework - to enable developers 
to build custom solutions that fit into a larger picture and have many 
elements of that larger picture taken care of for them (ie - Workflow, 
etc).

> So, the best bet would be to be able to put a DTML tag inside the body,
> where ever the author chooses. I could tell the authors to simply use
> <dtml-var "tablegenerator(item2,item5,item22)"> in their HTML code. 
> (Said
> tables are just lists of other Zope objects)

"Simply use"???  I think geeks need to strike this phrase from their 
vocabulary :).  It's like 'simply lo-fi the sampling rate using 
Latch.ar() with Impulse as a clock.'

> Am I really the only one who would find this usefull?  Seems to me I 
> would
> have the best of both worlds, a fully templated DTML aware object.  I 
> am
> fully aware of the theory of seperating content from style and all 
> that, but
> in my world, that's just not practical enough.  Telling authors (we 
> have
> many) that ALL their documents should look the EXACT same (or at least 
> have
> the exact same layout) isn't acceptable. Creating various templates 
> isn't
> practical enough either, I'd have a different template for every 
> document!
>
> I can think of a million uses of CMF Documents containing DTML, not the
> least of which is having workflows applicable to DTML rendered 
> (renderable?)
> content.
>
> Help ? Please ? :)