Adding rendermode inside a single-form

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

    Vasanth Kamatgi - 2011-11-23

    If there is a need to add custom html content inside a form, only the
    following choices are available:

    1. Without using the single-form feature build the whole content using direct html text (render-mode/text)
    2. Use single-form widget to build the form. Use javascript jQuery(document).ready to override / insert the parts of html that needs to be built.
      Both these options are convoluted and do not employ the power of widgets
      completely. Instead, if we are able to insert render-mode/text within a form,
      it would be a good enhancement.

    Is there any other solution that I am unable to see, that can be employed?

    -Thanks

     
  • David E. Jones

    David E. Jones - 2011-11-23

    There is another solution: have two single-form elements, the first with skip-
    end, and the second with skip-start and the HTML included or inlined between
    them.

     
  • Vasanth Kamatgi

    Vasanth Kamatgi - 2011-11-23

    Thanks for explaining the skip-start and skip-end attributes. I overlooked
    them completely. I think it certainly solves the problem.

    But, wouldnt allowing render-mode/text inside a form be a simpler solution (to
    the developer) than having 2 form definitions. This solution also makes the
    form definition more readable. Do you foresee any downside of allowing this?

     
  • David E. Jones

    David E. Jones - 2011-12-04

    This is a good idea Vasanth.

    In commit 3761087 I made some small changes to allow this. As I mentioned
    elsewhere, because of the way the FTL transformation of the XML screens and
    forms work, you can put these widgets anywhere, even if not supported in the
    XSD which is a little more constrained. You can even add a macro to the FTL
    file (or an extended one configured in the moqui-conf XML file) and not add it
    to the XSD and it will work fine. The XML validation will complain, but it
    will still work fine.

    There was also a small fix needed for this in a utility method that does a
    deep copy of Groovy Node objects so that it supports text under a node (which
    was breaking before).

     

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

Sign up for the SourceForge newsletter:





No, thanks