Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    DynamicForm, XSD, and nested collections

    After seeing the showcase demonstration of building forms directly from an XSD, I was excited. My requirement is to make my UI as flexible as possible without any knowledge of the Java classes that might be used under the hood, and now as long as an XSD is provided by my developers, I can do that.

    Where I am stumbling is for elements defined in the XSD where maxOccurs is greater than 1. Is there any support for ListGrid or DynamicForm to display a form item that allows the user to add more than one occurence of that element?

    I have done a lot of searching related to this issue. I have found several examples of doing this manually on these forums, using two separate DataSources, but I don't think that is an option for me. I will have no prior knowledge of the structure of the XSD provided to me, and so this form needs to be truly dynamic.

    #2
    Hello habelson,

    There is support for automatic nested editing of XSD-described structures - note dynamicForm.showComplexFields, nestedEditorType and nestedListEditorType. There's also the ability to override this by, for example, overriding setDataSource() and selectively generating your own fields where you don't like the default (via setting useAllDataSourceFields, you'll still be allowing default binding to take place for other fields).

    In XSD, there's a SOAP Array encoding that SmartGWT assumes means that a list interface should be shown by default. maxOccurs > 1 does not trigger this by default, but dataSourceField.getAttribute("xmlMaxOccurs") will allow you to discover the maxOccurs value from the XSD if you want to default to using a list editing interface in this case.

    Note that starting from XSD may not be the best choice - SmartGWT understands other sources of schema including SQL tables and Java Beans. In the case of Java Beans, there's no need for SmartGWT to know anything about "under the hood" classes (eg a DAO), just the business objects, which is the information that needs to make it to the client anyway, since forms and grids reflect the structure of the business objects. The advantage of using Java Beans as the source of schema is that the information is richer than in XSD, and can be extended by annotations.

    Regardless of the source of schema, if you're looking to build something like a generic nested editor completely driven by XSD or other schema, one that is maybe also capable of navigating across relations (eg knowing which entity should be shown in a nested grid), consider the Jump Start program as a way of getting started. Isomorphic could build the generic editor to spec, then your team gets training and takes over.

    Comment


      #3
      Thanks for the reply,

      In the time between my post and your response I managed to discover the technique you describe in your second paragraph. I am able to discover the fields that need to be treated as multiples. I then call setMultiple(true) on the field and that seems to cause the DynamicForm to show an appropriate editor for those fields. Interestingly enough, it also seems to cause a floating ListGrid to appear elsewhere in my app (maybe attached to RootPanel?). Trying to figure out how to get rid of that.

      As far as what I am trying to accomplish, in the case of what I am working on, it is the business objects themselves that are unknown. It would be hard to explain the scope of my project in a forum post. Putting it simply, I am building the front end for a framework, where any developer would be able to extend or create objects within that framework. The GUI needs to allow the users to configure attributes and paramters of those objects without knowing about what those objects are ahead of time. Using Beans would probably be a better implementation of this rather than XSD, but the design decision in that case isn't up to me, and there is already a requirement for the developers of those objects to provide an XSD for other reasons.

      Comment


        #4
        Your problem with a ListGrid appearing in a random spot is almost certainly due to mixing GWT and SmartGWT widgets, which we don't recommend.

        Generating a generic interface for objects that are created and modified on the fly is a familiar use case that Isomorphic has executed multiple times. Let us know if we can help.

        Comment

        Working...
        X