4:58 a.m.
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/>
7:35 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
7:41 a.m.
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(a)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(a)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/>
7:43 a.m.
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(a)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(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
7:49 a.m.
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(a)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(a)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(a)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(a)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/>
8 a.m.
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(a)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(a)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(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)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(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
12:02 p.m.
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(a)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(a)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(a)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(a)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(a)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(a)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/>
3707
days inactive
3709
days old
6 comments
2 participants
participants (2)
-
Antonio Goncalves -
George Gastaldi