• Sub-task
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 2.16.0.Final
    • 3.x Future
    • Java EE
    • None


      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


        Issue Links



              Unassigned Unassigned
              agoncal Antonio Goncalves (Inactive)
              0 Vote for this issue
              2 Start watching this issue