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

[hazmat]

On Friday 25 October 2002 04:34 am, Tres Seaver wrote:
> 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
> > > > too 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": to appear like a link. Way too much magic. Also underline is
> > > > rarely used, stars don't delimit text well enough, etc.
> > >
> > > There's no such thing as a plain user.  That's too broad of a term, but
> > > I do understand what you're talking about.  I've decided to punt on the
> > > issue altogether, use 'newline to br' type formatting, and let the
> > > structure of headers and such come out of a compound document (the
> > > still-not-public FDoc framework), which has special Part editors for
> > > lists of links, images, and so on.
> >
> > newline to br is probably a good choice, yes. It alleviates a lot of
> > problem.
> >
> > 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**).
> >
> > Things are never good enough for users unless we give them rich text
> > editors or (structured) WYSYWIG à la Xopus or Bitflux.
> >
> > 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.

To me this isn't a portal text tool your describing, its a 
portal_transformation tool. to me, on a minimalist level, portal_text is 
dealing with source block/body to rendered transformations, using a plugin 
rendering mechanisms. what your describing seems something entirely 
different, dealing with entire object representation, which is a more 
fundamental concept imo... 

>
>     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.

why do they need this? how is a representation object related to a portal_text 
component? what is a representation object?, it seems your describing the 
needs of object data that a portal_text component needs, but why does it need 
all of this 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.

where/why did PUTs come into play? are you saying the content is coming in, in 
rendered form? and your translating back to source?

>     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'.
>

/me smells xslt publishing framework 

basically it seems like your describing a two-way pipeline transformation 
system... for portal_text.

what does this all this complexity buy, what use cases are you trying to 
solve? 

<snip>

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

well then perhaps it should be called portal_transformation or 
portal_synchronization instead.

although from a pragmatist pov the output side of multiple formats is handled 
quiet nicely via multiple skins and explicit render methods (which is what i 
ended up doing for cmfdeployment).

i'm gonna send out an rfc on portal_synchronization after i wake up ;-)

curiously,

-haz