6 Replies Latest reply on Oct 29, 2014 1:02 PM by

    [forge-dev]  Getting lost in UICommands class hierarchy

      Hi all,

       

      I'm trying to add more commands in Forge... but I have to say, I'm a bit

      lost. So, I've made a quick UML class diagram.

       

      As you can see in the attached diagram (UIForge.png), most of the Java EE

      commands extend AbstractJavaEECommand, which makes sense. But not all of

      them (NewBeanCommand (CDI), ValidationNewAnnotationCommandImpl,

      NewQualifierCommand....). And some times you have an extra level of

      abstraction (AbstractFacesCommand). Same for the Java commands.

      JavaClassCommandImpl extend AbstractJavaSourceCommand but

      JavaAddAnnotationCommand and JavaFieldCommand inherit from

      AbstractProjectCommand.

       

       

      Then, when you dive into a command (UIForgeStructure.pgn), some commands

      use interface and implementation (see in the second

      diagram JavaAddAnnotationCommandImpl

      implementing JavaAddAnnotationCommand), some don't

      (e.g. NewQualifierCommand). Is there a reason ?

       

       

      Correct me if I'm wrong, but the way I see it would be (HowIseeIt.png) :

      under AbstractJavaEECommand you have a set

      of AbstractValidationCommand, AbstractCDICommand, AbstractJPACommand....

      each implementing PrerequisiteCommandsProvider (this way, each command sets

      up its own pre-requisite). And then, under AbstractCDICommand you have all

      the NewQualifierCommand, NewBeanCommand....

       

       

      What do you think ? Am I the only one getting a little bit lost ;o)

       

      What do you think of re-structuring the class hierarchy ?

       

      --

      Antonio Goncalves

      Software architect and Java Champion

       

      Web site <http://www.antoniogoncalves.org/> | Twitter

      <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>

      | Paris JUG <http://www.parisjug.org/> | Devoxx France

      <http://www.devoxx.fr/>

       

        • 1. Re: [forge-dev] Getting lost in UICommands class hierarchy
          gastaldi

          Hi Antonio,

           

          Yeah, I think that's fine. The idea of having an interface is to

          reference the next command in the next() method (or as a prerequisite),

          but that is optional.

          I think that would be a good idea, if these specializations had enough

          code to justify their existence.

           

           

          On 10/27/2014 02:58 AM, Antonio Goncalves wrote:

          Hi all,

           

          I'm trying to add more commands in Forge... but I have to say, I'm a

          bit lost. So, I've made a quick UML class diagram.

           

          As you can see in the attached diagram (UIForge.png), most of the Java

          EE commands extend AbstractJavaEECommand, which makes sense. But not

          all of them (NewBeanCommand (CDI), ValidationNewAnnotationCommandImpl,

          NewQualifierCommand....). And some times you have an extra level of

          abstraction (AbstractFacesCommand). Same for the Java commands.

          JavaClassCommandImpl extend AbstractJavaSourceCommand but

          JavaAddAnnotationCommand and JavaFieldCommand inherit from

          AbstractProjectCommand.

           

          >

          Then, when you dive into a command (UIForgeStructure.pgn), some

          commands use interface and implementation (see in the second

          diagram JavaAddAnnotationCommandImpl

          implementing JavaAddAnnotationCommand), some don't

          (e.g. NewQualifierCommand). Is there a reason ?

           

          >

          Correct me if I'm wrong, but the way I see it would be (HowIseeIt.png)

          : under AbstractJavaEECommand you have a set

          of AbstractValidationCommand, AbstractCDICommand, AbstractJPACommand....

          each implementing PrerequisiteCommandsProvider (this way, each command

          sets up its own pre-requisite). And then, under AbstractCDICommand you

          have all the NewQualifierCommand, NewBeanCommand....

           

          >

          What do you think ? Am I the only one getting a little bit lost ;o)

           

          What do you think of re-structuring the class hierarchy ?

           

          --

          Antonio Goncalves

          Software architect and Java Champion

           

          Web site <http://www.antoniogoncalves.org/> | Twitter

          <http://twitter.com/agoncal> | LinkedIn

          <http://www.linkedin.com/in/agoncal> | Paris JUG

          <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>

           

          >

          _______________________________________________

          forge-dev mailing list

          forge-dev@lists.jboss.org

          https://lists.jboss.org/mailman/listinfo/forge-dev

           

           

          • 2. Re: [forge-dev] Getting lost in UICommands class hierarchy

            The extra layer of AbstractValidationCommand, AbstractCDICommand,

            AbstractJPACommand (notice that this layer already exists for JSF) is

            justified by overriding isProjectRequired and getPrerequisiteCommands (all

            the Java EE commands need a project and need to be setup, see the code

            below).

             

            Then, if you say that the interface is optional, I would get rid of it.

             

            All in all, I think that homogenize the code is very important for new

            comers (like me). Creating a new command is, mostly, copy/paste + adding

            some specific logic. And depending which class you copy/paste, you end up

            with very different code.

             

            Antonio

             

             

            @Override

            *protected boolean *isProjectRequired()

            {

               return true;

            }

               @Override

               public NavigationResult getPrerequisiteCommands(UIContext context)

               {

                  NavigationResultBuilder builder = NavigationResultBuilder.create();

                  Project project = getSelectedProject(context);

                  if (project != null)

                  {

                     if (!project.hasFacet(CDIFacet.class))

                     {

                        builder.add(CDISetupCommand.class);

                     }

                  }

                  return builder.build();

               }

             

             

            2014-10-27 13:35 GMT+01:00 George Gastaldi <ggastald@redhat.com>:

             

            Hi Antonio,

             

            Yeah, I think that's fine. The idea of having an interface is to reference

            the next command in the next() method (or as a prerequisite), but that is

            optional.

            I think that would be a good idea, if these specializations had enough

            code to justify their existence.

             

            >

             

            On 10/27/2014 02:58 AM, Antonio Goncalves wrote:

             

            Hi all,

             

            I'm trying to add more commands in Forge... but I have to say, I'm a bit

            lost. So, I've made a quick UML class diagram.

             

            As you can see in the attached diagram (UIForge.png), most of the Java

            EE commands extend AbstractJavaEECommand, which makes sense. But not all of

            them (NewBeanCommand (CDI), ValidationNewAnnotationCommandImpl,

            NewQualifierCommand....). And some times you have an extra level of

            abstraction (AbstractFacesCommand). Same for the Java commands.

            JavaClassCommandImpl extend AbstractJavaSourceCommand but

            JavaAddAnnotationCommand and JavaFieldCommand inherit from

            AbstractProjectCommand.

             

            >

            Then, when you dive into a command (UIForgeStructure.pgn), some commands

            use interface and implementation (see in the second

            diagram JavaAddAnnotationCommandImpl

            implementing JavaAddAnnotationCommand), some don't

            (e.g. NewQualifierCommand). Is there a reason ?

             

            >

            Correct me if I'm wrong, but the way I see it would be (HowIseeIt.png) :

            under AbstractJavaEECommand you have a set

            of AbstractValidationCommand, AbstractCDICommand, AbstractJPACommand....

            each implementing PrerequisiteCommandsProvider (this way, each command sets

            up its own pre-requisite). And then, under AbstractCDICommand you have all

            the NewQualifierCommand, NewBeanCommand....

             

            >

            What do you think ? Am I the only one getting a little bit lost ;o)

             

            What do you think of re-structuring the class hierarchy ?

             

            --

            Antonio Goncalves

            Software architect and Java Champion

             

            Web site <http://www.antoniogoncalves.org/> | Twitter

            <http://twitter.com/agoncal> | LinkedIn

            <http://www.linkedin.com/in/agoncal> | Paris JUG

            <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>

             

            >

            _______________________________________________

            forge-dev mailing listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev

             

            >

             

            _______________________________________________

            forge-dev mailing list

            forge-dev@lists.jboss.org

            https://lists.jboss.org/mailman/listinfo/forge-dev

             

             

             

             

            --

            Antonio Goncalves

            Software architect and Java Champion

             

            Web site <http://www.antoniogoncalves.org/> | Twitter

            <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>

            | Paris JUG <http://www.parisjug.org/> | Devoxx France

            <http://www.devoxx.fr/>

             

            • 3. Re: [forge-dev] Getting lost in UICommands class hierarchy
              gastaldi

              Great, so +1 to that.

               

              On 10/27/2014 10:41 AM, Antonio Goncalves wrote:

              The extra layer of AbstractValidationCommand, AbstractCDICommand,

              AbstractJPACommand (notice that this layer already exists for JSF) is

              justified by overriding isProjectRequired and getPrerequisiteCommands

              (all the Java EE commands need a project and need to be setup, see the

              code below).

               

              Then, if you say that the interface is optional, I would get rid of it.

               

              All in all, I think that homogenize the code is very important for new

              comers (like me). Creating a new command is, mostly, copy/paste +

              adding some specific logic. And depending which class you copy/paste,

              you end up with very different code.

               

              Antonio

               

              >

              @Override

              *protected boolean *isProjectRequired()

              {

              return true;

              }

               

                 @Override

                 public NavigationResult getPrerequisiteCommands(UIContext context)

                 {

                    NavigationResultBuilder builder = NavigationResultBuilder.create();

                    Project project = getSelectedProject(context);

                    if (project != null)

                    {

                       if (!project.hasFacet(CDIFacet.class))

                       {

                          builder.add(CDISetupCommand.class);

                       }

                    }

                    return builder.build();

                 }

               

              >

              2014-10-27 13:35 GMT+01:00 George Gastaldi <ggastald@redhat.com

              <mailto:ggastald@redhat.com>>:

               

                  Hi Antonio,

               

                  Yeah, I think that's fine. The idea of having an interface is to

                  reference the next command in the next() method (or as a

                  prerequisite), but that is optional.

                  I think that would be a good idea, if these specializations had

                  enough code to justify their existence.

               

              >

               

                  On 10/27/2014 02:58 AM, Antonio Goncalves wrote:

              >>     Hi all,

              >>

              >>     I'm trying to add more commands in Forge... but I have to say,

              >>     I'm a bit lost. So, I've made a quick UML class diagram.

              >>

              >>     As you can see in the attached diagram (UIForge.png), most of the

              >>     Java EE commands extend AbstractJavaEECommand, which makes sense.

              >>     But not all of them (NewBeanCommand (CDI),

              >>     ValidationNewAnnotationCommandImpl, NewQualifierCommand....). And

              >>     some times you have an extra level of abstraction

              >>     (AbstractFacesCommand). Same for the Java commands.

              >>     JavaClassCommandImpl extend AbstractJavaSourceCommand but

              >>     JavaAddAnnotationCommand and JavaFieldCommand inherit from

              >>     AbstractProjectCommand.

              >>

              >>

              >>     Then, when you dive into a command (UIForgeStructure.pgn), some

              >>     commands use interface and implementation (see in the second

              >>     diagram JavaAddAnnotationCommandImpl

              >>     implementing JavaAddAnnotationCommand), some don't

              >>     (e.g. NewQualifierCommand). Is there a reason ?

              >>

              >>

              >>     Correct me if I'm wrong, but the way I see it would be

              >>     (HowIseeIt.png) : under AbstractJavaEECommand you have a set

              >>     of AbstractValidationCommand, AbstractCDICommand, AbstractJPACommand....

              >>     each implementing PrerequisiteCommandsProvider (this way, each

              >>     command sets up its own pre-requisite). And then,

              >>     under AbstractCDICommand you have all

              >>     the NewQualifierCommand, NewBeanCommand....

              >>

              >>

              >>     What do you think ? Am I the only one getting a little bit lost ;o)

              >>

              >>     What do you think of re-structuring the class hierarchy ?

              >>

              >>     --

              >>     Antonio Goncalves

              >>     Software architect and Java Champion

              >>

              >>     Web site <http://www.antoniogoncalves.org/> | Twitter

              >>     <http://twitter.com/agoncal> | LinkedIn

              >>     <http://www.linkedin.com/in/agoncal> | Paris JUG

              >>     <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>

              >>

              >>

              >>     _______________________________________________

              >>     forge-dev mailing list

              >>     forge-dev@lists.jboss.org  <mailto:forge-dev@lists.jboss.org>

              >>     https://lists.jboss.org/mailman/listinfo/forge-dev

              >

                  _______________________________________________

                  forge-dev mailing list

                  forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>

                  https://lists.jboss.org/mailman/listinfo/forge-dev

               

              >

              >

              --

              Antonio Goncalves

              Software architect and Java Champion

               

              Web site <http://www.antoniogoncalves.org/> | Twitter

              <http://twitter.com/agoncal> | LinkedIn

              <http://www.linkedin.com/in/agoncal> | Paris JUG

              <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>

               

              >

              _______________________________________________

              forge-dev mailing list

              forge-dev@lists.jboss.org

              https://lists.jboss.org/mailman/listinfo/forge-dev

               

               

              • 4. Re: [forge-dev] Getting lost in UICommands class hierarchy

                This refactoring is quite important, we should talk about this during the

                next meeting. I would be more than happy to try to do it, but I fear to

                break any tests or backward compatibility issue...

                 

                2014-10-27 13:43 GMT+01:00 George Gastaldi <ggastald@redhat.com>:

                 

                Great, so +1 to that.

                 

                >

                On 10/27/2014 10:41 AM, Antonio Goncalves wrote:

                 

                The extra layer of AbstractValidationCommand, AbstractCDICommand,

                AbstractJPACommand (notice that this layer already exists for JSF) is

                justified by overriding isProjectRequired and getPrerequisiteCommands (all

                the Java EE commands need a project and need to be setup, see the code

                below).

                 

                Then, if you say that the interface is optional, I would get rid of it.

                 

                All in all, I think that homogenize the code is very important for new

                comers (like me). Creating a new command is, mostly, copy/paste + adding

                some specific logic. And depending which class you copy/paste, you end up

                with very different code.

                 

                Antonio

                 

                >

                @Override

                *protected boolean *isProjectRequired()

                {

                   return true;

                }

                    @Override

                   public NavigationResult getPrerequisiteCommands(UIContext context)

                   {

                      NavigationResultBuilder builder = NavigationResultBuilder.create();

                      Project project = getSelectedProject(context);

                      if (project != null)

                      {

                         if (!project.hasFacet(CDIFacet.class))

                         {

                            builder.add(CDISetupCommand.class);

                         }

                      }

                      return builder.build();

                   }

                 

                >

                2014-10-27 13:35 GMT+01:00 George Gastaldi <ggastald@redhat.com>:

                 

                >>  Hi Antonio,

                >>

                >> Yeah, I think that's fine. The idea of having an interface is to

                >> reference the next command in the next() method (or as a prerequisite), but

                >> that is optional.

                >> I think that would be a good idea, if these specializations had enough

                >> code to justify their existence.

                >>

                >>

                >>

                >> On 10/27/2014 02:58 AM, Antonio Goncalves wrote:

                >>

                >>   Hi all,

                >>

                >>  I'm trying to add more commands in Forge... but I have to say, I'm a

                >> bit lost. So, I've made a quick UML class diagram.

                >>

                >>  As you can see in the attached diagram (UIForge.png), most of the Java

                >> EE commands extend AbstractJavaEECommand, which makes sense. But not all of

                >> them (NewBeanCommand (CDI), ValidationNewAnnotationCommandImpl,

                >> NewQualifierCommand....). And some times you have an extra level of

                >> abstraction (AbstractFacesCommand). Same for the Java commands.

                >> JavaClassCommandImpl extend AbstractJavaSourceCommand but

                >> JavaAddAnnotationCommand and JavaFieldCommand inherit from

                >> AbstractProjectCommand.

                >>

                >>

                >>  Then, when you dive into a command (UIForgeStructure.pgn), some

                >> commands use interface and implementation (see in the second

                >> diagram JavaAddAnnotationCommandImpl

                >> implementing JavaAddAnnotationCommand), some don't

                >> (e.g. NewQualifierCommand). Is there a reason ?

                >>

                >>

                >>  Correct me if I'm wrong, but the way I see it would be (HowIseeIt.png)

                >> : under AbstractJavaEECommand you have a set

                >> of AbstractValidationCommand, AbstractCDICommand, AbstractJPACommand....

                >> each implementing PrerequisiteCommandsProvider (this way, each command sets

                >> up its own pre-requisite). And then, under AbstractCDICommand you have all

                >> the NewQualifierCommand, NewBeanCommand....

                >>

                >>

                >>  What do you think ? Am I the only one getting a little bit lost ;o)

                >>

                >>  What do you think of re-structuring the class hierarchy ?

                >>

                >>  --

                >> Antonio Goncalves

                >> Software architect and Java Champion

                >>

                >> Web site <http://www.antoniogoncalves.org/> | Twitter

                >> <http://twitter.com/agoncal> | LinkedIn

                >> <http://www.linkedin.com/in/agoncal> | Paris JUG

                >> <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>

                >>

                >>

                >>  _______________________________________________

                >> forge-dev mailing listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev

                >>

                >>

                >>

                >> _______________________________________________

                >> forge-dev mailing list

                >> forge-dev@lists.jboss.org

                >> https://lists.jboss.org/mailman/listinfo/forge-dev

                >>

                >

                >

                --

                Antonio Goncalves

                Software architect and Java Champion

                 

                Web site <http://www.antoniogoncalves.org/> | Twitter

                <http://twitter.com/agoncal> | LinkedIn

                <http://www.linkedin.com/in/agoncal> | Paris JUG

                <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>

                 

                >

                _______________________________________________

                forge-dev mailing listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev

                 

                >

                 

                _______________________________________________

                forge-dev mailing list

                forge-dev@lists.jboss.org

                https://lists.jboss.org/mailman/listinfo/forge-dev

                 

                 

                 

                 

                --

                Antonio Goncalves

                Software architect and Java Champion

                 

                Web site <http://www.antoniogoncalves.org/> | Twitter

                <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>

                | Paris JUG <http://www.parisjug.org/> | Devoxx France

                <http://www.devoxx.fr/>

                 

                • 5. Re: [forge-dev] Getting lost in UICommands class hierarchy
                  gastaldi

                  Agreed. Let's discuss about this in the next meeting.

                   

                  On 10/27/2014 10:49 AM, Antonio Goncalves wrote:

                  This refactoring is quite important, we should talk about this during

                  the next meeting. I would be more than happy to try to do it, but I

                  fear to break any tests or backward compatibility issue...

                   

                  2014-10-27 13:43 GMT+01:00 George Gastaldi <ggastald@redhat.com

                  <mailto:ggastald@redhat.com>>:

                   

                      Great, so +1 to that.

                   

                  >

                      On 10/27/2014 10:41 AM, Antonio Goncalves wrote:

                  >>     The extra layer of AbstractValidationCommand, AbstractCDICommand,

                  >>     AbstractJPACommand (notice that this layer already exists for

                  >>     JSF) is justified by overriding isProjectRequired

                  >>     and getPrerequisiteCommands (all the Java EE commands need a

                  >>     project and need to be setup, see the code below).

                  >>

                  >>     Then, if you say that the interface is optional, I would get rid

                  >>     of it.

                  >>

                  >>     All in all, I think that homogenize the code is very important

                  >>     for new comers (like me). Creating a new command is, mostly,

                  >>     copy/paste + adding some specific logic. And depending which

                  >>     class you copy/paste, you end up with very different code.

                  >>

                  >>     Antonio

                  >>

                  >>

                  >>     @Override

                  >>     *protected boolean *isProjectRequired()

                  >>     {

                  >>     return true;

                  >>     }

                  >>

                  >>        @Override

                  >>        public NavigationResult getPrerequisiteCommands(UIContext context)

                  >>        {

                  >>           NavigationResultBuilder builder =

                  >>     NavigationResultBuilder.create();

                  >>           Project project = getSelectedProject(context);

                  >>           if (project != null)

                  >>           {

                  >>              if (!project.hasFacet(CDIFacet.class))

                  >>              {

                  >>     builder.add(CDISetupCommand.class);

                  >>              }

                  >>           }

                  >>           return builder.build();

                  >>        }

                  >>

                  >>

                  >>     2014-10-27 13:35 GMT+01:00 George Gastaldi <ggastald@redhat.com

                  >>     <mailto:ggastald@redhat.com>>:

                  >>

                  >>         Hi Antonio,

                  >>

                  >>         Yeah, I think that's fine. The idea of having an interface is

                  >>         to reference the next command in the next() method (or as a

                  >>         prerequisite), but that is optional.

                  >>         I think that would be a good idea, if these specializations

                  >>         had enough code to justify their existence.

                  >>

                  >>

                  >>

                  >>         On 10/27/2014 02:58 AM, Antonio Goncalves wrote:

                  >>>         Hi all,

                  >>>

                  >>>         I'm trying to add more commands in Forge... but I have to

                  >>>         say, I'm a bit lost. So, I've made a quick UML class diagram.

                  >>>

                  >>>         As you can see in the attached diagram (UIForge.png), most

                  >>>         of the Java EE commands extend AbstractJavaEECommand, which

                  >>>         makes sense. But not all of them (NewBeanCommand (CDI),

                  >>>         ValidationNewAnnotationCommandImpl,

                  >>>         NewQualifierCommand....). And some times you have an extra

                  >>>         level of abstraction (AbstractFacesCommand). Same for the

                  >>>         Java commands. JavaClassCommandImpl extend

                  >>>         AbstractJavaSourceCommand but JavaAddAnnotationCommand and

                  >>>         JavaFieldCommand inherit from AbstractProjectCommand.

                  >>>

                  >>>

                  >>>         Then, when you dive into a command (UIForgeStructure.pgn),

                  >>>         some commands use interface and implementation (see in the

                  >>>         second diagram JavaAddAnnotationCommandImpl

                  >>>         implementing JavaAddAnnotationCommand), some don't

                  >>>         (e.g. NewQualifierCommand). Is there a reason ?

                  >>>

                  >>>

                  >>>         Correct me if I'm wrong, but the way I see it would be

                  >>>         (HowIseeIt.png) : under AbstractJavaEECommand you have a set

                  >>>         of AbstractValidationCommand, AbstractCDICommand, AbstractJPACommand....

                  >>>         each implementing PrerequisiteCommandsProvider (this way,

                  >>>         each command sets up its own pre-requisite). And then,

                  >>>         under AbstractCDICommand you have all

                  >>>         the NewQualifierCommand, NewBeanCommand....

                  >>>

                  >>>

                  >>>         What do you think ? Am I the only one getting a little bit

                  >>>         lost ;o)

                  >>>

                  >>>         What do you think of re-structuring the class hierarchy ?

                  >>>

                  >>>         --

                  >>>         Antonio Goncalves

                  >>>         Software architect and Java Champion

                  >>>

                  >>>         Web site <http://www.antoniogoncalves.org/> | Twitter

                  >>>         <http://twitter.com/agoncal> | LinkedIn

                  >>>         <http://www.linkedin.com/in/agoncal> | Paris JUG

                  >>>         <http://www.parisjug.org/> | Devoxx France

                  >>>         <http://www.devoxx.fr/>

                  >>>

                  >>>

                  >>>         _______________________________________________

                  >>>         forge-dev mailing list

                  >>>         forge-dev@lists.jboss.org  <mailto:forge-dev@lists.jboss.org>

                  >>>         https://lists.jboss.org/mailman/listinfo/forge-dev

                  >>

                  >>

                  >>         _______________________________________________

                  >>         forge-dev mailing list

                  >>         forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>

                  >>         https://lists.jboss.org/mailman/listinfo/forge-dev

                  >>

                  >>

                  >>

                  >>

                  >>     --

                  >>     Antonio Goncalves

                  >>     Software architect and Java Champion

                  >>

                  >>     Web site <http://www.antoniogoncalves.org/> | Twitter

                  >>     <http://twitter.com/agoncal> | LinkedIn

                  >>     <http://www.linkedin.com/in/agoncal> | Paris JUG

                  >>     <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>

                  >>

                  >>

                  >>     _______________________________________________

                  >>     forge-dev mailing list

                  >>     forge-dev@lists.jboss.org  <mailto:forge-dev@lists.jboss.org>

                  >>     https://lists.jboss.org/mailman/listinfo/forge-dev

                  >

                      _______________________________________________

                      forge-dev mailing list

                      forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>

                      https://lists.jboss.org/mailman/listinfo/forge-dev

                   

                  >

                  >

                  --

                  Antonio Goncalves

                  Software architect and Java Champion

                   

                  Web site <http://www.antoniogoncalves.org/> | Twitter

                  <http://twitter.com/agoncal> | LinkedIn

                  <http://www.linkedin.com/in/agoncal> | Paris JUG

                  <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>

                   

                  >

                  _______________________________________________

                  forge-dev mailing list

                  forge-dev@lists.jboss.org

                  https://lists.jboss.org/mailman/listinfo/forge-dev

                   

                   

                  • 6. Re: [forge-dev] Getting lost in UICommands class hierarchy

                    Everybody is welcome to contribute to the JIRA :

                    https://issues.jboss.org/browse/FORGE-2109

                     

                    Antonio

                     

                    2014-10-27 14:00 GMT+01:00 George Gastaldi <ggastald@redhat.com>:

                     

                    Agreed. Let's discuss about this in the next meeting.

                     

                    >

                    On 10/27/2014 10:49 AM, Antonio Goncalves wrote:

                     

                    This refactoring is quite important, we should talk about this during the

                    next meeting. I would be more than happy to try to do it, but I fear to

                    break any tests or backward compatibility issue...

                     

                    2014-10-27 13:43 GMT+01:00 George Gastaldi <ggastald@redhat.com>:

                     

                    >>  Great, so +1 to that.

                    >>

                    >>

                    >> On 10/27/2014 10:41 AM, Antonio Goncalves wrote:

                    >>

                    >> The extra layer of AbstractValidationCommand, AbstractCDICommand,

                    >> AbstractJPACommand (notice that this layer already exists for JSF) is

                    >> justified by overriding isProjectRequired and getPrerequisiteCommands (all

                    >> the Java EE commands need a project and need to be setup, see the code

                    >> below).

                    >>

                    >>  Then, if you say that the interface is optional, I would get rid of it.

                    >>

                    >>  All in all, I think that homogenize the code is very important for new

                    >> comers (like me). Creating a new command is, mostly, copy/paste + adding

                    >> some specific logic. And depending which class you copy/paste, you end up

                    >> with very different code.

                    >>

                    >>  Antonio

                    >>

                    >>

                    >>  @Override

                    >> *protected boolean *isProjectRequired()

                    >> {

                    >>    return true;

                    >> }

                    >>     @Override

                    >>    public NavigationResult getPrerequisiteCommands(UIContext context)

                    >>    {

                    >>       NavigationResultBuilder builder = NavigationResultBuilder.create();

                    >>       Project project = getSelectedProject(context);

                    >>       if (project != null)

                    >>       {

                    >>          if (!project.hasFacet(CDIFacet.class))

                    >>          {

                    >>             builder.add(CDISetupCommand.class);

                    >>          }

                    >>       }

                    >>       return builder.build();

                    >>    }

                    >>

                    >>

                    >> 2014-10-27 13:35 GMT+01:00 George Gastaldi <ggastald@redhat.com>:

                    >>

                    >>>  Hi Antonio,

                    >>>

                    >>> Yeah, I think that's fine. The idea of having an interface is to

                    >>> reference the next command in the next() method (or as a prerequisite), but

                    >>> that is optional.

                    >>> I think that would be a good idea, if these specializations had enough

                    >>> code to justify their existence.

                    >>>

                    >>>

                    >>>

                    >>> On 10/27/2014 02:58 AM, Antonio Goncalves wrote:

                    >>>

                    >>>   Hi all,

                    >>>

                    >>>  I'm trying to add more commands in Forge... but I have to say, I'm a

                    >>> bit lost. So, I've made a quick UML class diagram.

                    >>>

                    >>>  As you can see in the attached diagram (UIForge.png), most of the Java

                    >>> EE commands extend AbstractJavaEECommand, which makes sense. But not all of

                    >>> them (NewBeanCommand (CDI), ValidationNewAnnotationCommandImpl,

                    >>> NewQualifierCommand....). And some times you have an extra level of

                    >>> abstraction (AbstractFacesCommand). Same for the Java commands.

                    >>> JavaClassCommandImpl extend AbstractJavaSourceCommand but

                    >>> JavaAddAnnotationCommand and JavaFieldCommand inherit from

                    >>> AbstractProjectCommand.

                    >>>

                    >>>

                    >>>  Then, when you dive into a command (UIForgeStructure.pgn), some

                    >>> commands use interface and implementation (see in the second

                    >>> diagram JavaAddAnnotationCommandImpl

                    >>> implementing JavaAddAnnotationCommand), some don't

                    >>> (e.g. NewQualifierCommand). Is there a reason ?

                    >>>

                    >>>

                    >>>  Correct me if I'm wrong, but the way I see it would be (HowIseeIt.png)

                    >>> : under AbstractJavaEECommand you have a set

                    >>> of AbstractValidationCommand, AbstractCDICommand, AbstractJPACommand....

                    >>> each implementing PrerequisiteCommandsProvider (this way, each command sets

                    >>> up its own pre-requisite). And then, under AbstractCDICommand you have all

                    >>> the NewQualifierCommand, NewBeanCommand....

                    >>>

                    >>>

                    >>>  What do you think ? Am I the only one getting a little bit lost ;o)

                    >>>

                    >>>  What do you think of re-structuring the class hierarchy ?

                    >>>

                    >>>  --

                    >>> Antonio Goncalves

                    >>> Software architect and Java Champion

                    >>>

                    >>> Web site <http://www.antoniogoncalves.org/> | Twitter

                    >>> <http://twitter.com/agoncal> | LinkedIn

                    >>> <http://www.linkedin.com/in/agoncal> | Paris JUG

                    >>> <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>

                    >>>

                    >>>

                    >>>  _______________________________________________

                    >>> forge-dev mailing listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev

                    >>>

                    >>>

                    >>>

                    >>> _______________________________________________

                    >>> forge-dev mailing list

                    >>> forge-dev@lists.jboss.org

                    >>> https://lists.jboss.org/mailman/listinfo/forge-dev

                    >>>

                    >>

                    >>

                    >>

                    >>  --

                    >> Antonio Goncalves

                    >> Software architect and Java Champion

                    >>

                    >> Web site <http://www.antoniogoncalves.org/> | Twitter

                    >> <http://twitter.com/agoncal> | LinkedIn

                    >> <http://www.linkedin.com/in/agoncal> | Paris JUG

                    >> <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>

                    >>

                    >>

                    >> _______________________________________________

                    >> forge-dev mailing listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev

                    >>

                    >>

                    >>

                    >> _______________________________________________

                    >> forge-dev mailing list

                    >> forge-dev@lists.jboss.org

                    >> https://lists.jboss.org/mailman/listinfo/forge-dev

                    >>

                    >

                    >

                    --

                    Antonio Goncalves

                    Software architect and Java Champion

                     

                    Web site <http://www.antoniogoncalves.org/> | Twitter

                    <http://twitter.com/agoncal> | LinkedIn

                    <http://www.linkedin.com/in/agoncal> | Paris JUG

                    <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>

                     

                    >

                    _______________________________________________

                    forge-dev mailing listforge-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev

                     

                    >

                     

                    _______________________________________________

                    forge-dev mailing list

                    forge-dev@lists.jboss.org

                    https://lists.jboss.org/mailman/listinfo/forge-dev

                     

                     

                     

                     

                    --

                    Antonio Goncalves

                    Software architect and Java Champion

                     

                    Web site <http://www.antoniogoncalves.org/> | Twitter

                    <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal>

                    | Paris JUG <http://www.parisjug.org/> | Devoxx France

                    <http://www.devoxx.fr/>