[development] rich text editor

[Oleg Terenchuk]

here are some of my thoughts, they may be dupliate of what has already been
said, i just wanted to do a brain dump.

Why is there a need for a special input format to be in CORE? why not have
the RTE define it's own input filter which just happens tobe flexible enough
for user to configure for "extra security".

on top of that, if we use a 'predictable' filter, then we can pull it's
settings, and at the same time we can examine which of the current TRE
enabled features (TRE profiles) can work with current filter settings, and
disable accordingly.

all this is rather complex if we are depending on other filters, but is
marginaly easier if we use our own filter.

also a major issue to consider is the following:
HTML code produced by the TRE. i can imagine two solutions, please add your
own as you come up with them.
1) operate on raw HTML, which leads to very complex and ugly html code,
which is often unoptimized (nested font tags anyone?). to avoid this we'll
need a very very very complex regex to fix our markup.
2) operate on a DOM-LIKE data structure in real time, which gets saved to
HTML on submit. this is much more complex in terms of initial design and
coding, but in the end result we can guarantee to produce much beter HTML
markup and overall result will be better because we are working with a data
type which lives within predictable restrictions imposed by us. imagine FAPI
data structure for this, each element has properties and all of them can be
nested to define a larger entity. on save (or in case of fapi, on form
display) it gets converted into HTML !

i am quite confident that no RTE will make it into core if it produces ugly
HTML markup, but i am also confident that no TRE will get into the core if
it allows the user to see the markup.

(for the following, i use button and TRE feature interchangeably. in both
cases i am referring to the button you see on the user end that performs
some kind of function on/to the text in the TRE)
going back to the input filter issue, i believe the RTE should not have to
handle the filtering. i think we have much better chance of success if we
think of the TRE itself as a 'plugin engine', or think of it in terms of
drupal. i think we can design some TRE which is flexible enough to be
extended /easily/, then we can turn our focus away from TRE and onto button
features.

each button feature will exist on the front end as some JQuery code
operating on the live data, but also it's module will sit in the background
defining it's own filter (filter per button or filter per feature relating
to the RTE).

that way we again avoid having to predict what filters the site has enabled,
we just have one filter which is the TRE defined filter, and in the admin
filter settings we attach filter engines or parsers which are defined by
each TRE button. we may however define our own filter admin screen to avoid
the end user having to run through many different admin screens connecting
all those dots. which is rather trivial for us to do.


summary of my thoughts, complexities:
input formats/ filters : trivial
admin screens for end user: trivial
build in jquery + lightweight: trivial to medium
expandable through plugins: trivial to medium
produce clean HTML or design and build custom TRE data structure: very
difficult


this is all i have for now, i hope i was able to bring some fresh thought
for discussion.

~LiTWoL

On 2/5/08, Shai Gluskin <shai at content2zero.com> wrote:
>
> The hardest part for me is sorting out the relationships between the
> following three components:
>
>
>    1. The RTE
>    2. Input Filters
>    3. Input Formats
>
> Each of these components have their own, sometimes quite complex,
> settings. The success can depend on the precise selection of settings. And
> even then, the successful implementation can be broken by adding further
> functionality or changing seemingly unrelated settings.
>
> In the realm of RTE, Drupal's power and flexibility lead to nightmarish
> results.
>
> How about a dedicated input format, built into core, called DrupalRTE? The
> hard code would decide, which, if any, input filters would be supported in
> this input format. The Wysyiwyg interface would be totally tied to the
> selection of the DrupalRTE input format. Example: If I'm in node/add/story
> and I change the input format from DrupalRTE to Filtered HTML, the Wysiwyg
> will go away.
>
> I think by closely wrapping the RTE into an Input Format which does not
> allow the user to select which input filters its supports -- we'd be
> significantly lowering the number of variables that contribute to really
> fussy RTE implementations.
>
> Shai Gluskin
> content2zero <http://content2zero.com>
>



-- 
Oleg Terenchuk
Web Manager / Developer
Phone: 917 - 306 - 5653
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080205/db0d5343/attachment-0001.htm