[forge-issues] [JBoss JIRA] (FORGE-2331) Refactor New and Add commands

[George Gastaldi (JIRA)]

    [ https://issues.jboss.org/browse/FORGE-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105683#comment-13105683 ] 

George Gastaldi edited comment on FORGE-2331 at 9/4/15 1:46 PM:
----------------------------------------------------------------

The above solution would only work with a @Typed(TargetPackage.class), because there would be ambiguous dependency resolution issues (conflicting with @Inject UIInput<String>) 


was (Author: gastaldi):
The above solution wouldn't work, because there would be ambiguous dependency resolution issues (conflicting with @Inject UIInput<String>) 

> Refactor New and Add commands
> -----------------------------
>
>                 Key: FORGE-2331
>                 URL: https://issues.jboss.org/browse/FORGE-2331
>             Project: Forge
>          Issue Type: Sub-task
>          Components: Java EE
>    Affects Versions: 2.16.0.Final
>            Reporter: Antonio Goncalves
>             Fix For: 2.x Future
>
>
> {code}
> agoncal   gastaldi Do you have a moment ?
> gastaldi  agoncal, sure, what's up?
> agoncal   gastaldi I'm getting more confident with Forge and I can create more and more commands....
> agoncal   but actually, it's xxxNewxxxCommands
> agoncal   In Forge I see commands to create new classes (artifacts) : CDINewBean, JPANewEntity....
> agoncal   And commands to add code to existing classes : JPAAddField, CDIAddInjectionPoint
> agoncal   I find xxxAddCommands more difficult to write than xxxNewCommands
> agoncal   For example :
> agoncal   ServletNewServletCommand extends from AbstractServletNewCommand which extends from AbstractJavaSourceCommand
> agoncal   AbstractJavaSourceCommand gives me targetPackage, named and overwrite
> agoncal   I would like to have the same kind of hierarchy to easy my xxxAddCommands development
> agoncal   Something like :
> agoncal   ServletAddContextCommand extends from AbstractServletAddCommand which extends from AbstractAddCommand
> agoncal   And AbstractAddCommand would give me targetClass, named and overwrite
> agoncal   gastaldi WDYT ?
> gastaldi  hmmm
> gastaldi  interesting
> gastaldi  do all xxxAddCommands have targetClass, named and overwrite?
> agoncal   gastaldi Yes. You usually want to add something that is named (attribute, method...) into a class (target class) and if it's already there you want to override it
> gastaldi  hmmm
> gastaldi  I don't see it as a rule for the Add commands
> gastaldi  for example, AddDependenciesCommand does not feature that
> agoncal   Well, the New commands are : targetPackage, named and overwrite and I think it represents most of the cases
> agoncal   gastaldi are you talking about project-add-dependencies ?
> gastaldi  yes
> agoncal   I'm more focused on Java EE code (project-add-dependencies is indeed different)
> gastaldi  hmm, maybe we don't need to inherit, but have encapsulate these properties
> agoncal   yes, why not, I'm trying to get as closed to the current model as possible (so it doesn't break anything)
> agoncal   I would like to be as confident to write a AddCommand than a NewCommand, and at the moment it's not the case
> agoncal   If there was an AbstractNewCommand and an AbstractAddCommand in just the JavaEE addon, it would make development easier
> agoncal   (most of the Java EE commands share the same common properties and behaviour)
> gastaldi  ok, but what about the abstract classes per technology ?
> gastaldi  are they becoming xxxNewCommands?
> agoncal   Well, we could have AbstractNewCommand with targetPackage, named and overwrite, and AbstractCDINewCommands for the prerequisite (CDI needs CDISetup)
> agoncal   And same for the add :
> agoncal   AbstractAddCommand with targetClass, named and overwrite, and AbstractCDIAddCommands
> agoncal   .... humm....
> agoncal   Both AbstractCDINewCommands and AbstractCDIAddCommands are used for the prerequisite...
> gastaldi  it's awesome that you found a pattern between these command types
> gastaldi  but I think that at some point inheritance won't be the answer :)
> agoncal   gastaldi Thanks to writing the documentation ;o)
> agoncal   gastaldi Totally agree !
> gastaldi  what documentation?
> agoncal   I feel a bit stuck with inheritance sometimes
> agoncal   Because Add and New both have a named
> gastaldi  agoncal, yes, perhaps we need to start looking at encapsulation instead
> agoncal   Add has a targetClass and New a targetPackage
> gastaldi  that is a more flexible approach
> agoncal   Yes !
> agoncal   But that might break some current APIs
> agoncal   (don't know)
> gastaldi  we could have a class with these common attributes and pass them to the UIBuildder
> gastaldi  *UIBuilder
> agoncal   Yes
> agoncal   As a developper, I really just want to focus on writing the "business logic" of a command and less boiler plate code
> gastaldi  that's right
> gastaldi  totally agree
> agoncal   When writing a Add command I'm happy that the targetPackage is being taking care of
> agoncal   I also want the same for Add
> agoncal   (which is not the case at the moment)
> gastaldi  hmmm
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)