Single toolbar (performance) vs. expand function

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

With FCKeditor 2.3 and higher, it's possible to share toolbars across multiple textareas on a page. While this can result in faster loading, it does so at the expense of functionality - the toolbar fit to window (expand) function doesn't work because it isn't sure which textarea to expand when multiple textareas are sharing the same toolbar.

For RavenNuke, that affects pages like the Content maintenance / add page. This page has 5 textareas. Loading the editor 5 times can be slow. But if you don't maintain content pages frequently, the inability to expand a textarea (some of the content pages can be quite long) might be more of an inconvenience.

In the interest of time (i.e. faster delivery of an updated nukeWYSIWYG for RavenNuke), I'm leaning towards leaving the multiple textarea pages alone (after all, FCKeditor 2.3+ loads 3 times faster than the 2.2 version we are currently using). That will give me more time to perform more detailed performance tests to see how significant the difference is.

Thoughts?

Posted: Sun Dec 24, 2006 5:05 am

I wouldn't think that a slower load time were all that important in admin functions my only concern would be slower load times for user functions like submit news.

Posted: Sun Dec 24, 2006 6:52 am

Good point. To me it seems more a function of frequency of use. If your submit news function is used constantly and people don't need to expand the editor, it might be worth loading one toolbar to share across the 2 textareas.

Another option would be to allow submit news to switch between a single toolbar and separate toolbars (this might be more trouble than it's worth).

For now, let's just leave it as separate toolbars and enjoy the performance improvements it already has. I'll continue to test and if the numbers support it, I'll look into making changes.

The content maintenance function is the slowest since it loads 6 tools bar (one to add a category, and 5 to add a content page). Even with no WYSIWYG editor, this design leads to confusion and poor performance. There are so many opportunities for improving this basic CMS function to make it more efficient (there are many requests for improving the ability to work with content when there are more than a few pages).

It's probably worth considering this in 2007, but for now, let's get the new version of FCKeditor because it resolves several nagging issues (e.g. better browser compatibility, improved compliance, image preview consistency, and more).

Posted: Sun Dec 24, 2006 6:57 am

Agreed

registered · Posted: Sun Dec 24, 2006 9:52 am

I agree as well. I still have on my "to do" list to have more of a "Wiki" concept for content management. But, as we all know and experience ourselves, no time! I need to get a 1.4 version out for HTML Newsletter, but the "wiki" would be next on my list (unless I get derailed with something I've been thinking about for ShortLinks - a "suggested re-write rules" feature for links that are not yet re-written).