[Zope3-dev] Axe DTML Document

[Casey Duncan]

--- Paul Everitt <paul@zope.com> wrote:
> Casey Duncan wrote:
> Here's one: a Document has its contents full-text
> indexed, a File 
> doesn't.  Whether that's correct behavior or not, I
> won't assert. :^)

Well, I've got a product devoted to full-text indexing
of mostly non-textual files...Granted those files are
mostly textual content that just happens to be stored
in unfortunate file formats 8^)

> I've gone through the responses and I'll summarize
> here some of my views.
> 
> 1) There is a tension between making Document smart
> or dumb.  This 
> corresponds to putting a lot or a little programming
> into Document.

Well I say we start dumb and get smart. Unless of
course we don't and just stay dumb forever, in which
case we may not even realize how dumb we are, negating
the entire exercise 8^)

> 2) I'm concerned about making the data in the ZODB
> future-proof.  If the 
> class that the pickle is an instance of is overly
> rich, then you might 
> find yourself always writing converters for every
> Zope upgrade.  Also, 
> the data may be less usable outside of Zope.

I think the key to this is making any complex
"Document" serializable to an externally readable
format (such as XML). So when you look at a DOMish
document through FTP you see XML. This could also take
care of the indexing issue...

> 3) I'm someone that uses CMF Documents quite
> aggressively.  I'm 
> constantly trying to find some damn tool on some
> operating system that 
> can replace a TEXTAREA w/o disappointing me.  Thus,
> in some ways I have 
> expectations of my Zope3 folder appearing to be a
> fileserver, albeit one 
> that can give me a bunch of extras when I look at it
> through a web 
> browser.  This is an important usage.  It covers the
> majority of content 
> currently being authored by the majority of average
> users.

If we come up with a clever interface (or even just a
standardized, simple if not-so-clever one), I think
that could allow us to develop client/server tools
specific to this problem with much greater success.
 
> 4) In some ways, the smarts of CMF Document leads to
> unexpected behavior 
> for (3).  For instance, say I'm using WebDrive/DavFS
> to edit a text 
> document.  I save it.  It's immediately out-of-date,
> because the CMF 
> sticks Dublin Core headers into it.  If you pick
> some neutral DOM 
> representation, you're by definition changing the
> original in a perhaps 
> lossy way.  Users might not expect that and give up
> when things don't 
> work as expected.

Right, we need to try as much as possible to make what
goes in, what comes out. Nobody wants to save
something only to have something even subtly different
be there the next time they open it.

The challenge will be effectively overcoming the
pinhole syndrome of looking at rich objects through
FTP or DAV. They'll always be tradeoffs, we just need
to make the right ones.
 
> 5) OTOH, most of the value an organization gets is
> in turning raw data 
> into repeatable, standardized content with rich
> services.  Pulling this 
> off without alienating users (see (4)) is the trick.

I think of any trick we can pull off, this one stands
to be the one poised to make Zope stand by itself as a
CMS. This one might be 9 of the 10x by itself.

> I think this project should start with a proposal
> that captures all the 
> questions first.  Then five or six of you go off and
> haggle about the 
> answers.

Damn, I hate it when he's right.
 
> Jeffrey, Herveline just told me to say hi to you.
> 
> --Paul

Right back at ya 8^)

-Casey


__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com