Announcement Announcement Module
No announcement yet.
Be part of the wizards' creation process Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Be part of the wizards' creation process

    SpringIDE will soon provide some wizards.

    You can see some details by following the link bellow :

    Please give us your feedback on the layout or suggest new ideas for wizards!

    BTW tell us if you'd like to have wizards for productivity or to help first users.



  • #2
    I added my take on a "New Spring project" wizard to the wiki page.



    • #3
      I think wizards for adding aspects to the application would be very useful. For ex a wizard for adding a transactional aspect to the application would be useful. The wizard could give the user different approaches possible (using TPFB or BeanNameAutoProxy etc) and guide the user through the basic and most used configurable properties.

      Here's a simple scenario that allows the user to add transactional aspect in a graphical modelling editor. Not sure if a modelling editor is a good option. Wizard seems more practical.

      1. User opens the graphical editor.
      2. User right clicks and chooses add transactional aspect -> autoproxy approach.
      3. Editor adds a autoproxy component to the diagram showing its socket/extension point.
      4. User right clicks on the transactionInterceptor socket.
      5. Editor shows determinable options, for ex all implementations of the interceptor interface
      6. User chooses an interceptor.
      7. Editor adds it to the diagram linking the interceptor to the socket for the same in the autoproxy component.
      8. User assigns the interceptor a bean name of his own liking.
      9. User then right clicks the "attribute source" socket of the interceptor and selects a attribute source type.
      10. Editor adds it to the diagram linking it with the interceptor
      11. User right clicks the attribute source's nameMap socket and goes through a process to select application bean methods for beans that are already tied to the autoproxy beanNames socket.
      12. Similarly user right clicks the autoproxy component's beanNames socket and selects the beans that are already defined in the spring file.
      13. User right clicks the diagram and selects option to (re)generate spring configuration file for this graphical model.


      • #4
        Comments on BeansWizard

        Thanks for the nice wizard. Some comments:
        1. When the user selects 'Declare Spring Bean' on a Spring project which has got only one configuration file, then that configuration file should already be selected in 'Select configuration file:' combobox.
        2. When the user selects 'Declare Spring Bean' on a Java class (be it a class in the source folder or somewhere in the classpath), then that Java class should be selected in the wizard's first page's 'Select the Java class' input.
        3. The three sections on the first page ('Where the the Spring Bean...','Which java bean...','How this java class...') should be opened, maybe the plus signs should be even dropped. I don't want to click on too much things just to create a bean, it should be as short as possible to create a simple bean:
          • Click Declare Spring Bean (set project name, config file name and Java class if possible)
          • Fill the bean id
          • Click finish.
        4. The lifecycle page should be the second one, then comes the properties page.
        5. Regarding the 'properties' page, I am not sure if it is really needed here, I think when creating the bean I am not totally aware how then bean will be wired with other beans, though it can be left as an option. Please take a look at Ticket 245 (, I have posted similar ideas, though for the BeansGraph editor.


        • #5
          Thanx for your feedback

          I guess you'll be positively surprised by the finished wizard.

          It does promote the simplest path.

          Though I think properties should definitly be on the second page, as people often tweak them and tweak the lifecycle info a lot less.


          • #6
            Thanx and some new comments

            Thanx for the nice work, I'll check the new wizard as soon as I can. Until then, I have some comments.
            Please check this article about Spring configuration on Twelve Best Practices For Spring XML Configurations.
            It contains some info about Spring configuration I wasn't aware of and I think some might be useful for the wizard.
            1. In section 5, it says that a bean can be abstract (and the wizard has already got a checkbox for making a bean abstract, that's fine), but a bean can have a parent, too. Maybe it would be nice to have a combobox to select the id or an alias of another bean as parent.
            2. We can add a 'description' tag under bean tag. It would be also nice to be able to add a description in the wizard. It seems less important, so it can be the last page.

            Personally I don't see these things very crucial, so just consider it.



            • #7
              One more thing

              According to the article I mentioned in my previous reply, it is possible to define a bean without a class, though I have never tried this. The bean would be then implicitly abstract.
              I am not sure how the wizard works right now, but it should allow the user to create a bean without class definition.



              • #8
                Abstract beans are indeed very useful

                It will indeed be a possibility to define an abstract bean, and to set a parent bean.

                So once again you will be very pleased.

                But this concept of abstract bean must not be mistaken with an abstract class.
                As you already stated it, an abstract bean is just an abstract way of defining injections.

                For example you could define an abstractDao with a datasource injection, and make all your DAOs use this abstract bean as a parent.
                This doesn't inply that your application contains any abstractDao class, it just abstracts the fact that Dao beans should be injected a datasource!

                Then when you want to change your datasource, you only have to do it in one place.

                This is most useful to properly define your application's type of beans (for example an abstract bean for DAOs, another for Services, yet another one for say... Struts actions or Spring MVC controllers...etc)

                This way you can pull up some of the most common injections and even put them in a separate config file, therefore reuseable accross projects .

                Soooo, to conclude, this will indeed be possible, but as I think of it, I still have to turn off the "missing class" error when the bean is chosen to be abstract.

                Thanx a lot for your feedback and keep on


                • #9
                  Not ot revive an old thread or anything, but considering now that I am more comfortable with Spring and I have Spring IDE installed on Eclipse 3.2, I was more curious about getting to know the plugin better. It seems as these bean wizards are a part of the plugin, no? And that means there is a way to activate the wizard? I looked at the screenshots but nowhere in my IDE install did I find the Delcare Beans context menu link. Am I doing something wrong? If so please advise.