• Subscribe to this RSS Feed
  • Another Javascript RIch User Interface library to watch - ExtJS
    10/05/2009 3:31PM

    An article over at slashdot.org referred to a commercial/open source rich user interface library called ExtJS available at: http://www.extjs.com/.

    As of this writing it is dual licensed under the GPL and a Commercial License, similar to the way formVista is licensed.

    After a cursory glance it seems like a fairly complete toolkit, but at this point I'm committed to continuing on with jQuery for formVista.

  • Xinha WYSIWYG HTMLEditor in jQuery.UI tabs
    10/03/2009 3:17PM

    More complex AJAX/AJSON applications such as Google Maps and the Xinha WYSIWYG HTML Editor do not render correctly when placed into hidden divs, presumably because they cannot correctly get the size of the div. 

    According to the Xinha ticket list, the editor must be visible before it is created otherwise it will be displayed in a broken and frozen state.

    Problem #1: MSIE 6 Xinha in hidden div when size is set to auto

    This can be reproduced by placing the Xinha editor into an unselected tab in a jQuery.UI tab control:

    addsku_xinha2.jpg

    The editor does not size itself correctly to the surrounding div. In addition the editor is frozen.

    Problem #2: MSIE 6.0 Form Element Rendering glitch

    The jQuery.UI documentation offers a solution/workaround described as the oft-left technique which involves moving divs off the visible page instead of setting it to display: none;. Unfortunately under MSIE 6 this approach seems to break when used with something that contains form elements:

    addsku_xinha.jpg

    This occurs after the Description tab containing Xinha has been selected and unselected. The other downside to the off-left technique is that it can confuse screen readers.

    A Work-Around

    Given that it was clearly a sizing problem, I discovered that if you create the Xinha editor using fixed sizing the first problem is solved.This is done by setting the width and height properties of the XinhaConfig object before creating the editor:

    var xinha_config = new Xinha.Config();
    xinha_config.width = "700px";
    xinha_config.height = "300px";

    This solves the first problem.

    The second problem, namely that the editor is frozen, can be solved by noticing that the Xinha method sizeEditor() can called without any arguments. Called in this fasion it recalculates its size based on how it was originally configured. This only seems to work if the editor has fixed sizing.

    So whenever the tab is shown, just call resize. This can be easily accomplished by binding a callback to the tabshow event:

    $('#tabs').bind('tabsshow',
       function( event, ui )
          {
          if ( ui.index == 1 )
             {
             editor.sizeEditor();
             }
          } );

    Assuming you have a global editor object avialable. I like to avoid globals whenever possible so, in formVista, when I process the <htmleditor> FVML tag, I add the editor object to the textarea using the jQuery core data() method as in:

    $('form[name=someform] textarea[name=somefield]').data( "xinha_editors", Xinha.makeEditors(xinha_editors, xinha_config, xinha_plugins));

    And then in my callback I just get the editor using:

    var editor = $('form[name=someform] textarea[name=somefield]').data( "xinha_editors" )['somefield'];

    Note that the value stored in the xinha_editors entry is an array of editors per instructions in the Xinha newbie guide. You can certainly do it differently.

    Right now, the FVML <htmleditor> tag is not yet smart enough to know that it's inside a <tabbedcontainer> tag, so I just embed the callback into the FVML using a plain <js> tag. More on doing development in FVML another time.

    Conclusion

    This workaround seems to work in FireFox, MSIE 6, and MSIE 8. I have not yet had a chance to try it in other browsers.

    So in summary, to get the Xinha WYSIWYG HTML Editor to work with the jQuery UI tab control in an unselected tab:

    1. configure Xinha using a fixed size
    2. call sizeEditor() when the tab containing the htmleditor is selected.

    If you find any problems with this workaround or have any questions, please leave comments here or in the forum. (Unfortunately, I don't have anonymous posting built yet, so you'll need to register for an account. See the Register link in the upper right corner.)

  • From a follower on twitter - net-tuts
    09/29/2009 11:25AM
    What appears to be a compelling resource for javascript, jQuery, HTML, PHP and CSS info: http://net.tutsplus.com/
  • HTML5 <canvas> tag
    09/29/2009 11:13AM

    Yesterday I came across a few demonstrations of what's possible using the HTML5 <canvas> tag which opens up some very interesting possibilities.

    According to Wikipedia - http://en.wikipedia.org/wiki/Canvas_(HTML_element)

    Some examples of what can be done with the canvas tag:

    Blob Salad

    http://hyper-metrix.com/#Burst

    http://balldroppings.com/js/

  • The Xinha WYSIWYG Editor, HTMLPurifier and the non-validating br tags.
    09/23/2009 1:41PM

    So I just spent some time tracking down a little bug which turned out to be my own stupid fault. 

    formVista uses HTMLPurifier to sanitize HTML that's submitted by end users. HTMLPurifier rocks. 

    However, Ryan over at Nuts and Bolts Interactive discovered <br /> tags submitted using the WYSIWYG html editor are changed to <br>. This is not correct for the XHTML 1.0 Transitional doctype that we're using on the front end.

    After some digging, I realized that I had set the doctype correctly on the frontend but had set it to HTML 4.01 Transitional on the backend. (We still have a lot of work to do bringing the backend out of the stone-age).

    Since HTMLPurifier was being loaded on the backend it was getting the backend's doctype and doing exactly what it was supposed to do.

    So the takeway is, if HTMLPurifier is not doing what you expect it to be doing, make sure to check that you are in fact passing it the correct doctype.
  • << 1 2 3 4