Re: DO NOT REPLY [Bug 42230] - define contract for images and assets in backend store, move to XHTML2 strict.

[Andreas Hartmann <an...@apache.org>]

Joern, maybe we should add these comments to the bug report?

-- Andreas

Joern Nettingsmeier schrieb:
> Andreas Hartmann wrote:
>> Joern Nettingsmeier schrieb:
>>> bugzilla@apache.org wrote:
>>>> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
>>>> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
>>>> <http://issues.apache.org/bugzilla/show_bug.cgi?id=42230>.
>>>> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
>>>> INSERTED IN THE BUG DATABASE.
>>>>
>>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=42230
>>>>
>>>>
>>>> nettings@apache.org changed:
>>>>
>>>>            What    |Removed                     |Added
>>>> ----------------------------------------------------------------------------
>>>>
>>>>
>>>>    Target Milestone|1.4                         |1.4.1
>>> obviously, the move to XHTML2 is something for lenya 2.0,
>>
>> Isn't it just another resource type?
> 
> true. what i'm after is a really well-defined, really picky backend
> format that everybody could rely on, especially the editor maintainers.
> currently we don't have a clear notion of what's stored in a document.
> we have doctype-based validation, but there are editor hacks in there.
> editors in turn have validation hacks in them, and the result is not so
> nice.
> 
> the reason why i consider it 2.0 stuff is that we would have to throw
> away the old xhtml doctype, to get rid of all those hacks in the editors
> and to have a decent editor abstraction layer at last.
> 
> like so:
> 
> XHTML2 with metadata and lenya-specific link and image elements (uuid
> based, supporting on-the-fly resizing etc..)
>   |
>   V
> generic pre-processing: replace link and image tags.
>   |
>   V
> editor-specific pre-processing: hack the living shit out of the xhtml2
> format, to cater to every conceivable editor quirk
>   |
>   V
> edit      -> editor-specific glue -> truly generic asset,
> + submit                             link and image dialogues
>   |
>   V
> editor-specific post-processing
>   |
>   V
> generic post-processing
>   |
>   V
> validate [1]
>   |
>   V
> store
> 
> [1] the problem with validation (at least in tinymce) is that currently
> users lose data when validation errors occur: the validator barfs, the
> editor is re-displayed, but the document can't be saved again for
> locking reasons.
> plus the validation errors need not correspond to what the user actually
> enters, due to post-processing. so we would need to provide a
> step-by-step overview of the post-processing pipeline similar to what
> the profiler does, to help the user figure out the real problem.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org