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