[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/>

[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

[e-mail]

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

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 <[e-mail]>:

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 [e-mail]://lists.jboss.org/mailman/listinfo/forge-dev

>

_______________________________________________

forge-dev mailing list

[e-mail]

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/>

[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 <[e-mail]

<mailto:[e-mail]>>:

    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

>>     [e-mail]  <mailto:[e-mail]>

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

>

    _______________________________________________

    forge-dev mailing list

    [e-mail] <mailto:[e-mail]>

    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

[e-mail]

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

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 <[e-mail]>:

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 <[e-mail]>:

>>  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 [e-mail]://lists.jboss.org/mailman/listinfo/forge-dev

>>

>>

>>

>> _______________________________________________

>> forge-dev mailing list

>> [e-mail]

>> 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 [e-mail]://lists.jboss.org/mailman/listinfo/forge-dev

>

_______________________________________________

forge-dev mailing list

[e-mail]

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/>

[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 <[e-mail]

<mailto:[e-mail]>>:

    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 <[e-mail]

>>     <mailto:[e-mail]>>:

>>

>>         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

>>>         [e-mail]  <mailto:[e-mail]>

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

>>

>>

>>         _______________________________________________

>>         forge-dev mailing list

>>         [e-mail] <mailto:[e-mail]>

>>         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

>>     [e-mail]  <mailto:[e-mail]>

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

>

    _______________________________________________

    forge-dev mailing list

    [e-mail] <mailto:[e-mail]>

    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

[e-mail]

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

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 <[e-mail]>:

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 <[e-mail]>:

>>  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 <[e-mail]>:

>>

>>>  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 [e-mail]://lists.jboss.org/mailman/listinfo/forge-dev

>>>

>>>

>>>

>>> _______________________________________________

>>> forge-dev mailing list

>>> [e-mail]

>>> 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 [e-mail]://lists.jboss.org/mailman/listinfo/forge-dev

>>

>>

>>

>> _______________________________________________

>> forge-dev mailing list

>> [e-mail]

>> 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 [e-mail]://lists.jboss.org/mailman/listinfo/forge-dev

>

_______________________________________________

forge-dev mailing list

[e-mail]

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/>