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