Support for HTML events

2011-11-22
2012-09-09
  • Vasanth Kamatgi

    Vasanth Kamatgi - 2011-11-22

    This is w.r.t. the feature request Support for HTML events.

    Provide for a way to configure onclick, onchange etc., javascript events on
    the generated screen widgets like drop-down, link, image, label etc.

    I wanted to understand the rationale behind this design decision of achieving
    it only through jQuery etc. Though its not very difficult to hook on to any
    event in the html page (using jquery etc.), it results into avoidable
    javascript code blocks within html. When moqui is so beautifully able to
    reduce the lines of code, isnt it regressing to do the opposite. In fact,
    instead of achieving something via configuration, we are ending up writing
    code to achieve it. Even from a best practices point of view as well, I follow
    \"no-inline javascripts unless absolutely necessary\" mantra (User
    experience and Performance pov). A bit more of narration on this design
    decision will certainly be helpful.

     
  • David E. Jones

    David E. Jones - 2011-11-23

    Moqui follows the HTML/JS pattern that has been evolving in recent years with
    multiple JS frameworks (jQuery, Prototype, etc) where events and dynamic code
    are kept separate from the HTML and registered at runtime, which is more
    similar to the desktop app MVC approach and generally results in cleaner code.

    From a tool design perspective, this also helps us avoid duplicated dozens of
    attributes from HTML in the Moqui Screen and Form elements.

     
  • Vasanth Kamatgi

    Vasanth Kamatgi - 2011-11-23

    That argument certainly has a lot of weight. However I see a heavy
    performance penalty with this approach. Let me explain.

    To bind the events to elements, either we can use inline scripts right after
    the element or on $(document).ready at the end. If we use inline scripts it
    will impact the page load time and the user experience - Positioning Inline
    Scripts

    ...Inline scripts block rendering, just like external scripts, but are
    worse. External scripts only block the rendering of elements below them in the
    page. Inline scripts block the rendering of everything in the page...

    If we move everything to the end, managing it becomes more difficult - also
    the code is dispersed rather than nicely compartmentalized. Additionally, if
    document takes more time to load, these elements become dysfunctional even
    though they are rendered.

    In a recent audit of performance of an application, this was identified and a
    lot of refactoring had to be done in order to increase the performance of the
    page.

    I do not think, this would be as much of a concern for pages with little
    content, but is certainly going to be a worry for more complex pages.

    I must admit that I have not done desktop apps for a long time. But I still
    remember facilities like self closing frames etc., where, while construction
    of the component, we can specify "common" behaviour" - which is what I believe
    is the feature request that I raised. In other words, I would say, a multiple
    argument constructor is probably better than invoking a no-arg constructor and
    then sequentially calling setXXX methods on the object.

     
  • David E. Jones

    David E. Jones - 2011-11-24

    One magical thing about Moqui is that you don't have to use the OOTB
    FreeMarker templates that transform screens and forms into HTML, you can
    override them as desired to make your own. Doing this you don't need to use
    any of the OOTB HTML, and you don't even need to use jQuery... you can use
    whatever style of HTML and such that you want.

    As part of this, you can even add attributes and elements to the screen and
    form files by just handling them in the FTL file.

    There is an example of overriding the DefaultScreenMacros.html.ftl file using
    the moqui/runtime/template/ScreenHtmlMacros.ftl file. This is configured in
    the moqui-conf file, for this example in the MoquiDevConf.xml file on lines
    50-51.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks