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

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&gt;: > 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&gt;: > >> 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