Claude Schneegans wrote: > What for instance would you like to have?
You pretty much listed our requirements :) > - a good CMS should NOT allow users to use HTML to fulfill all their > fantasies. > So, users should not be able to define any color, font size and what > ever, instead, they > should be able to select a style (or a class) the site designers have > designed for them. That's why the toolbar configurability and (with our database-driven style selector hack) style control in fckeditor works for us. > - a good HTML editor should be callable from several places in a form, > each instance > having it's own set of tools and styles available to the user. For > instance when editing > a News Release, I ask the user to fill a summary and the main content. I > don't want him > to have access to all the tools for the summary, not even to bold, since > this is handled > by the News Release template any way. and again. We allow for user-created forms like this too, in a limited way: the form tag and submit/reset buttons are generated by the CMS; users can insert whatever form controls they like in between (and flag fields as mandatory). The only processing option we offer ATM is to email the form results to a pre-configured address, but that actually covers most people's requirements. FWIW, the form processor itself is one I wrote in mod_perl and is *very* paranoid for all the obvious reasons. > - a good HTML Editor should not be embeded in a textarea, instead, it > should open a new window > which can be resized any sized to resemble the final page the text is > intended, > otherwise it is not really WYSIWYG. Here I disagree - the web isn't WYSIWYG anyhow, so giving users the illusion that it is does no good at all. We do use the target stylesheet in the fckeditor (or soeditor) iframe, though, so fonts, sizes and colours are as they should be. > - a good HTML editor should not allow pasting from MS Word with no basic > cleaning. I wrote a co-processor for soeditor to sanitise such crap when switching from source to html mode and when exiting; fckeditor has a "paste from word" function, though I haven't (yet) thrown much horror at it. > Finally, the HTML editor should not allow users to upload any image anytime. > The problem with HTML Editors is that they are completely independant > from the CMS system. > Images should be managed by some tool in the CMS admin module, and > registered in the database, > including image sizes, some title, description etc. > Then, the CMS provides some tool to select and display images from the > database, not the editor. We have the option of allowing image uploads into any directory, configurable by directory. If the directory is managed by the CMS, the upload actually goes to that directory's raw image store and the CMS will autogenerate the appropriately sized, framed, annotated or otherwise mangled result into the directory the user *thinks* they're uploading to. At present, images newly uploaded this way are actually registered in the image table when an administrator next enters the image manager - I do a scan of the raw image directories and add any new images as uncategorised, flagging duplicates. -- Pete Jordan Horus Web Engineering Ltd http://www.webhorus.net/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:214517 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
