Announcement Announcement Module
Collapse
No announcement yet.
Form designer - Abeille or JFormDesigner? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Form designer - Abeille or JFormDesigner?

    I've been using straight TableFormBuilder code so far in my forms, and while it works well for me, I'm interested in setting up a form designer for the sake of my colleagues. I've found both Abeille and JFormDesigner to be interesting, and am interested in others' experience with either of these. Which would you recommend? What are the strengths and weaknesses of each? Is there something better than either of these?
    At this point, I'm more interested in a solution that writes out a "form" file (binary, XML, or whatever) that I can load at runtime and then tie in with a spring-rich form rather than something that generates Java code.

    Thanks,
    Andy

  • #2
    abeille is open source, jformdesigner no
    both generate .form file

    I don't know who is better, I see only base features and try only first cut forms with abelle

    Comment


    • #3
      Some time ago I posted an entry on using Abeille with Spring-Rich. I hope it's still valid:

      http://forum.springframework.org/showthread.php?t=16117
      Last edited by robyn; May 14th, 2006, 08:05 PM.

      Comment


      • #4
        Hi Andy - ive been using JFormDesigner on evaluation for last three weeks, im literally about to purchase just after i post this.

        - I am very impressed indeed byy the quality of this product. Its very slick, i starting looking all over its installation directory looking for dll's for SWt or something else, its really hard to believe its swing. It looks *great* and performs the job I wish perfectly.

        _ Im quite proficient with LayoutManagers, tableLayout, Jgoodies, standard layouts etc, and was always reluctant to use code generation, GUI builders etc. However, I have a very nice mode of operation now, from which I am 100% sure my purchase of JFormdesigner has already paid for it and my laouts have improved. (im sure youve already read it, but this blog pushed me towards actually doing something about this...http://weblogs.java.net/blog/javaben.../08/index.html)

        - I use the JFormdesigner to create my JGoodies formlayouts on screen, all my goupings, spacings etc etc. Its *very* slick, and anyone who cant appreciate the productivity gain has their head right up their proverbial!!

        - The geberated forms register in eclipse with icons and ou can launch the tool from eclipse - tho full integration is meant to be on its way i read. So - i layout the form and tweak it, save it, refresh in eclipse and run - its a very fast, pleasing work cycle....

        - I do *not* use the code generation facilites. Instead I save the forms and load them using the free distributable that cmes with JFormdesigner and pull the widgets out by name, its a complete no brainer. The formloader is small enough not to worry about, about 80k i think.

        - The interface to JFormdesigner is very nice to use, looks absolutely great. Ive also noticed my laouts improving in terms of behaviour when stretched etc. This is probably because im more prepared to experiment and try out by testing the form in the designer. Also - because of the quick response time its has *improved* my knowledge of the JGoodies laout as i simply fart about trying stuff out to see what it does and how it behaves - perfect!

        - Also the properties sheets to the right have me trying stuff out on my widgets tha i probably wouldnt hav experimented with otherwise. Another bonus - if indirect.

        - Im not worried about this purchase at all, its paid for itself already. Im using it to generate layouts for a manager i already am familiar with and i can generate code from it if I was *really* worried about some form of lock in.

        - Ive added custom beans to the tool as well and its working fine, eg l2fprod and JDateChooser etc....

        - Also - the "binary" forms generated from the tool, ive opened in eclipse and strike me as being nothing more than XMLEncoded versions of the swing hierarchy. Nothing too scarey...

        - I still havent wrapped my head round the squint test on JFormdesigner tho, it makes me ill and cant look at it too long ;-) The idea I think is that designers used to squint to see if a layout was undertsnadable, or had good contrast or something...I need some more time with that feature...;-)

        BTW i have nothing to do with JFormdesigner! its just been a great productivity tool for me, even as a proficient swing layout person, one doesnt half get *hacked* off having to do it over and over by hand, and its easy to get lazy.....and it *is* a visual process!! ;-)

        Good luck, apologies for spelling, i rushed this and i need food!

        Alan

        Comment


        • #5
          I also only use TableFormBuilder so I've got no idea about which of the various form designers are better than any other but I have been thinking a lot about integrating SpringRich's binding system with GUI's built using builders. With all the buzz about builders Matisse has stirred up I think we need to support this.

          What did you have in mind Andy? How would we go about supporting this?

          My first though is that we would have a class that iterates through the containment hierarchy of a provided panel (generated by the GUI builder) and for each component it finds then attempts to bind that component using the components name as a hint about which form property the component should bound to. You could also then find any labels that are for that component and apply our i18zed labels etc..

          Sound feasible? I guess it gets complicated when you have comboboxs and lists as you'd need a way to tell the binder what are the selectable items etc...

          Ollie

          Comment


          • #6
            Peter's approch with Abeille is also nice though we'd need to have a custom binder for each supported GUI builder.

            Comment


            • #7
              I really like Peter's approach with Abeille.
              I have a bad taste in my mouth from past experience with code generating GUI designers (maybe I should reevaluate them now?)... so, my original thought was to have the form output in some sort of file that could be loaded at runtime to produce a panel. I've looked into both products and they both support this. My other thought was to then query these loaded forms for the "fields" by name and ask Spring-rich to bind that control. For example (using fictional code with a fictional API):
              Code:
              final JComponent control = loadedForm.getFieldComponent("name");
              bindingFactory.createBinding(control, "property");
              You get the idea. Finally, if the developer was consistent in their naming of form components, then this entire process could be automated, as Peter demonstrated with Abeille.
              Now, if Spring-rich wanted to offer a helping hand, then it could provide a strategy interface. Such a strategy interface might offer methods to load a form UI into a panel, methods to access field components by name, and even methods to automatically bind all known fields in a loaded form UI. Spring-rich could then provide some default impelmentations out of the box: one for Abeille, one for JFormDesigner, etc. This would allow me to switch from, say, Abeille to JFormDesigner in the future and not have to touch my code. I just plug in the JFormDesigner implementation of the strategy and go. It would also allow developers to use their own preferred UI designer: some developers could use Abeille and some JFormDesigner, but the code would remain the same, only the strategy implementation would differ.
              The ultimate goal is to make it easier to integrate with these designers, and the strategy would make it so that newcomers to Spring-rich wouldn't have to figure out how to bind controls from one of these designers to a Spring-rich form. They could just do something like:
              Code:
              protected JComponent createFormControl() {
                FormLoadingStrategy fls = ...;
                FormUI fui = fls.loadFormUI("newEmployee");
                fui.bindFormUI(getBindingFactory());
                return fui.getFormPanel();
              }
              We could even create a Form implementation based on the code above so that it configurable via Spring:
              Code:
              <bean id="newEmployeeForm" class="org.springframework.richclient.form.LoadedForm">
                <property name="formId" value="newEmployee"/>
                <property name="formLoadingStrategy" ref="abeilleFormLoader"/>
              </bean>
              Note: I know these class names are really bad, and would hope we could come up with something better in the end.

              - Andy

              Comment


              • #8
                I think we can get away with two extra classes:
                a FormUIProvider interface:

                Code:
                public interface FormUIProvider extends ControlFactory &#123;
                  void bind&#40;BindingFactory factory&#41;;
                &#125;
                and a GeneratedForm (or LoadedForm) class:

                Code:
                public class GeneratedForm extends AbstractForm implements InitializingBean&#123;
                    private FormUIProvider formUIProvider;
                
                    public FormUIProvider getFormUIProvider&#40;&#41; &#123;
                        return formUIProvider;
                    &#125;
                
                    public void setFormUIProvider&#40;FormUIProvider formProvider&#41; &#123;
                        this.formUIProvider = formProvider;
                    &#125;
                
                    protected JComponent createFormControl&#40;&#41; &#123;
                        formUIProvider.bind&#40;getBindingFactory&#40;&#41;&#41;;
                        return formUIProvider.getControl&#40;&#41;;
                    &#125;
                
                    public void afterPropertiesSet&#40;&#41; throws Exception &#123;
                        Assert.notNull&#40;formUIProvider, "FormProvider must be set"&#41;;
                    &#125;
                &#125;
                Possible implementations:
                1. AbeilleFormUIProvider: Abeille
                2. JFormDesignerFormUIProvider: JFormDesigner
                3. GenericJavaClassFormUIProvider: arbitrary java class, generated by oldschool gui generators (ala JBuilder, Eclipse VE, ...), which works by locating input components (recursively) by their name.

                The only problem I see is where we could put the different FormUIProvider implementations. I don't know if it's possible to add the abeille runtime and jformdesigner runtime to the spring-rich distribution. Perhaps we could create a new "integration" project, which contains the necessary sources/classes.

                - Peter

                Comment


                • #9
                  cool...thanks for sharing.




                  We are product designers with offices in Sydney and Melbourne providing Industrial Design Services, Product Design and Engineering like CAD Design.

                  Comment


                  • #10
                    Originally posted by adepue View Post
                    I've been using straight TableFormBuilder code so far in my forms, and while it works well for me, I'm interested in setting up a form designer for the sake of my colleagues. I've found both Abeille and JFormDesigner to be interesting, and am interested in others' experience with either of these. Which would you recommend? What are the strengths and weaknesses of each? Is there something better than either of these?
                    At this point, I'm more interested in a solution that writes out a "form" file (binary, XML, or whatever) that I can load at runtime and then tie in with a spring-rich form rather than something that generates Java code.

                    Thanks,
                    Andy
                    hi, adepue.
                    i have a problem when using the tableformbuilder.

                    i dont know how to bind a Set type attribute to a gui component, what is your solution, if have.thank you.

                    Comment


                    • #11
                      My client are about to buy this Tableformbuilder and good to know there someone expert here on this forum.

                      Comment

                      Working...
                      X