Announcement

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

    Dynamic form creation

    Hello,

    I am trying to do the following:

    I need to dynamically create different forms.
    For example:
    Form A has three fields: name, first_name, last_name
    Form B has four fields: name, last_name, date

    So each form has some unique fields and some other fields that are common for other forms too.
    So my initial idea was to store in a table the different metadata for each field, the positions, the field names, etc.
    Then create the form fields depending on that metadata on-the-fly.
    But then I will have problems with the handlers: some form items must have handlers, some others not, etc.

    Another idea was to serialize each field to disk with all its methods and characteristics (so the handlers would be also serialized with the fields), and to load them on-the-fly to create a the form.
    But it's that feasible? Would smartGWT permit that serialization?

    Or do you have another idea with the help of smartGWT that can help me in this scenario?


    I am using I am using SmartGWT 2.4 EE.

    Thank you
    Last edited by edulid; 21 May 2011, 15:08.

    #2
    Any ideas? is that possible ?

    Comment


      #3
      It depends what your overall goal is here, but you seem to be headed in the direction of Visual Builder OEM. Visual Builder OEM means that you include Visual Builder with your shipped application, to allow your customers to extend and customize your application.

      To do this, Visual Builder stores screen definitions in XML (which can be in a database or just on disk), including certain event handlers (called Event->Action bindings).

      If you want to explore Visual Builder OEM, contact us here about Visual Builder OEM and our JumpStart program.

      Otherwise, you'll need to come up with your own serialization format for event handlers. Be sure to also consider the server-side API DataSource.addDynamicDSGenerator() as a means of providing dynamic DataSources, which can be better than storing form definitions since dynamic DataSources retain all server-side behaviors (validation, etc).

      Comment


        #4
        Hello,

        thanks for your reply. I am not very sure Visual Builder OEM is what I need, because I don't want to allow my customers to customize the application as you said.

        I just want to create different forms depending on the form "type". For example:
        form types: school, nursery
        Each form shows a record (a record is a "student" who is inscribed in that institute). Both forms will have common fields, like student_name, student_birthday, but the school form will have "final_exam_grade", while the nursery won't. The nursery will have "eating_time", while the school won't. Each field may have different event handlers. Each field may have different positions in the form (in the school form: left:14, top:15, while in the nursery form: left:26, top:26).

        Normally, I would create two different forms, one for each type. But I must create a lot of different forms with different field arrangements (the positions, etc) so I need a more "generic" solution.

        Is there a way to save all fields in one form, maybe an xml form file?, but with all fields invisible? So in the table I will save which fields must get visible for which type, and with which positions?
        I must be able to save the handlers with the form fields.
        So in the case of the same field but with 2 different handlers, I will just save the field two times with different names, and let the right field become visible.

        Is there a way to do what I am trying to do?
        Maybe the Visual Builder is the right choice for what I am trying to do, but I only misunderstood you?

        Thanks in advance

        Comment


          #5
          Why "save" this information? If you don't need dynamic modification of the application at runtime (the Visual Builder OEM use case), it should be sufficient to just have the different form definitions as Java code.

          The Data Binding system (see QuickStart Guide, Data Binding chapter) already gives you a way to minimize the amount of redundancy in the form definitions. If you don try to "save" these form definitions and just leave them as Java code, you don't have to worry about how to serialize and de-serialize event handler code.

          Comment

          Working...
          X