Re: [forge-dev] Getting lost in UICommands class hierarchy

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