[Zope3-dev] Status of reST
Stephan Richter
stephan.richter@tufts.edu
Sun, 13 Apr 2003 13:57:45 -0400
On Friday 11 April 2003 19:44, Jeffrey P Shell wrote:
> I don't think it's over-engineered. It's still a work in progress,
> much like Zope 3 is - with more obvious rules (I'm still spinning over
> the differences between @@foo and @@/foo. How long until $_?).
>
> But it is very flexible, powerful, and adaptable. And, given its
> internal complexity, it's a LOT easier to follow than Zope 3 currently
> is. :\.
Well, I would hope so, since it id "just" a documentation tool.
> I did that trick in my initial reST work too, but it never sat
> comfortably with me. There is this expressive framework available, and
> sidestepping it just feels wrong. To me it always felt like "if I'm
> not using it properly, then why am I using it?"
I do not want to use it; I am forced to use it. I would prefer to just say
HTML.format(rest, full_page=0). All the rest is boilerplate to me right now.
I really like how simple it was to get Structured Text working.
> It turns out that Andreas Jung's code in Zope 2.7, particularly the
> 'html4zope' writer object, may return that body part anyways as the
> core return document, without the general pre/post body items even (the
> "generated by docutils" footer, etc). That could probably be reused.
Actually, Zope 2 is where I got the current minimal code working. I will look
into that further...
> However, there have been some significant improvements to docutils in
> recent months that are probably not incorporated into the code in the
> Zope branch, particularly in the "interpreted text roles" department.
> Some of these improvements could be very advantageous to pick back up.
What are "interpreted text roles"?
> >> - Maintaining our own copies could be time consuming, but
> >> too many dependencies are annoying for end users.
> >
> > We do not need to "maintain" a copy, just provide one; in fact, I
> > would not
> > change anything in our copy of docutils ever.
>
> By 'not change anything in our copy', do you mean never upgrading it
> once we start using it?
No, just never make a change in it that is not made is the main docutils CVS;
basically make no patches. Of course, careful upgrades should be done
regularly.
> Or do you mean not changing any of its code,
> so that it can be upgraded with no maintenance?
Right.
> Docutils is flexible
> enough to allow custom components (readers, writers, whatever) outside
> of the docutils tree (I don't know why Andreas put 'html4zope' in the
> Zope 2.7 'lib/python/docutils/writers' directory - that does make
> updates hard).
Right, I would move it out.
> By 'maintaining our own copy', I did not mean that we make any
> modifications inside the docutils/ tree and then maintain them. My
> concern was just updating it in timely fashion from the primary source,
> at least until the docutils release management system changes and there
> are solid release points to run on.
Right.
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training