here are some of my thoughts, they may be dupliate of what has already been said, i just wanted to do a brain dump.<br><br>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".<br>
<br>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.<br>
<br>all this is rather complex if we are depending on other filters, but is marginaly easier if we use our own filter.<br><br>also a major issue to consider is the following:<br>HTML code produced by the TRE. i can imagine two solutions, please add your own as you come up with them.<br>
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.<br>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 !<br>
<br>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.<br><br>(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)<br>
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. <br>
<br>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).<br>
<br>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.<br>
<br><br>summary of my thoughts, complexities:<br>input formats/ filters : trivial<br>admin screens for end user: trivial<br>build in jquery + lightweight: trivial to medium<br>expandable through plugins: trivial to medium<br>
produce clean HTML or design and build custom TRE data structure: very difficult<br><br><br>this is all i have for now, i hope i was able to bring some fresh thought for discussion.<br><br>~LiTWoL<br><br><div><span class="gmail_quote">On 2/5/08, <b class="gmail_sendername">Shai Gluskin</b> <<a href="mailto:shai@content2zero.com">shai@content2zero.com</a>> wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
The hardest part for me is sorting out the relationships between the following three components:<br><br><ol><li>The RTE</li><li>Input Filters</li><li>Input Formats</li></ol>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.<br>
<br>In the realm of RTE, Drupal's power and flexibility lead to nightmarish results.<br><br>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.<br>
<br>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.<br>
<span class="sg"><br>Shai Gluskin<br><a href="http://content2zero.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">content2zero</a><br></span></blockquote></div><br><br clear="all"><br>-- <br>Oleg Terenchuk <br>
Web Manager / Developer<br>Phone: 917 - 306 - 5653