[forge-dev] Getting lost in UICommands class hierarchy
George Gastaldi
ggastald at redhat.com
Mon Oct 27 09:00:41 EDT 2014
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 at redhat.com
> <mailto:ggastald at 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 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 <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/2f253e0b/attachment-0001.html
More information about the forge-dev
mailing list