'portal_text' tool noodling (was Re: [Zope-CMF] Re: reStructuredText)

[Tres Seaver]

On Fri, 2002-10-25 at 06:45, Florent Guillaume wrote:
> Jeffrey P Shell  <jeffrey@cuemedia.com> wrote:
> > > Actually if this is a tool to give to users, both of those are much t=
oo
> > > complicated, and there is too much magic in them. A plain user doesn'=
t
> > > want things 'like that' to appear in <code>, or things "like that": t=
o
> > > appear like a link. Way too much magic. Also underline is rarely used=
,
> > > stars don't delimit text well enough, etc.
> >=20
> > There's no such thing as a plain user.  That's too broad of a term, but=
=20
> > I do understand what you're talking about.  I've decided to punt on the=
=20
> > issue altogether, use 'newline_to_br' type formatting, and let the=20
> > structure of headers and such come out of a compound document (the=20
> > still-not-public FDoc framework), which has special Part editors for=20
> > lists of links, images, and so on.
>=20
> newline_to_br is probably a good choice, yes. It alleviates a lot of
> problem.
>=20
> As for the rest of your message, you're right, no feature set will ever
> be enough for all users, and those markups are just reinventing bits of
> HTML. But that doesn't mean it's not simpler for the users (there is a
> lot of redundant typing in writing <b>foo</b> instead of **foo**).
>=20
> Things are never good enough for users unless we give them rich text
> editors or (structured) WYSYWIG =E0 la Xopus or Bitflux.
>=20
> Anyway what's needed is flexibility in that department, and a
> portal_text would be nice indeed. I'm thinking about it.

I think 'portal_text' would need to offer several services:

  - The tool would hold (or register) components which could do
    transformations of the content representation.

    o I am afraid that these "representation" objects need to
      be more elaborate than I would like:  each one needs to have
      both a "body" and a dictionary (or a dictionary-of-dictionaries)
      to hold metadata.

    o On a PUT, the representation starts out with the 'name' and
      'content_type' values in the dictionary, and the 'body' as
      the body.

    o On a POST, the representation starts out with the form variables
      in the dictionary, and an empty body.

    o Output transformations start with the representation from the
      content object itself.

  - The tool would compose thees transformer components into "chains".

  - The tool would bind these chains to content objects based on
    their 'portal_type'.

We would then write skin methods / templates for conformant content
objects against the tool, using the tool to process input, or create
output, for the file.

E.g. for form input::

  ## Script (Python) "foo_edit"
  ##title=3DProcess the edit form for Foo-type objects
  ##parameters=3DREQUEST
  from Products.CMFCore.utils import getToolByName
  text_tool =3D getToolByName( context, 'portal_text' )
  repr =3D text_tool.getFormRepresentation( context, REQUEST.form )
  context.update( repr )
  # ...

For PUT handling::

  ## Script (Python) "foo_put"
  ##title=3DProcess the edit form for Foo-type objects
  ##parameters=3Dname, content_type, body
  from Products.CMFCore.utils import getToolByName
  text_tool =3D getToolByName( context, 'portal_text' )
  repr =3D text_tool.getPUTRepresentation( context
                                       , name, content_type, body )
  context.updateFromRepresentation( repr )
  ...

On output::

  ...
  <div metal:fill-slot=3D"main"
       tal:define=3D"text_tool here/portal_text;
                   raw_repr  here/getRepresentation;
                   repr python: text_tool.getOutputRepresentation(
                                  here, raw_repr, 'html' );
                   body repr/getBody;
                  "
       tal:content=3D"body/asHTML"
  >
  BODY GOES HERE
  </div>
  ...

As a bonus, this same "representation-oriented" approach tailors pretty
well with various filesystem-synchronization schemes.

Tres.
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com