[forge-dev] Getting lost in UICommands class hierarchy

George Gastaldi ggastald at redhat.com
Mon Oct 27 08:43:05 EDT 2014


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 at redhat.com 
> <mailto:ggastald at 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 at lists.jboss.org  <mailto:forge-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>     _______________________________________________
>     forge-dev mailing list
>     forge-dev at lists.jboss.org <mailto:forge-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20141027/c773f758/attachment-0001.html 


More information about the forge-dev mailing list