[forge-issues] [JBoss JIRA] (FORGE-2331) Refactor New and Add commands
Antonio Goncalves (JIRA)
issues at jboss.org
Fri Sep 4 10:15:01 EDT 2015
[ https://issues.jboss.org/browse/FORGE-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105655#comment-13105655 ]
Antonio Goncalves commented on FORGE-2331:
------------------------------------------
https://gist.github.com/gastaldi/46b3f38bc38c5efcc0ba
> 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)
More information about the forge-issues
mailing list