[
https://issues.jboss.org/browse/FORGE-2331?page=com.atlassian.jira.plugin...
]
Antonio Goncalves commented on FORGE-2331:
------------------------------------------
agoncal Basically, when you write a command, you need attributes :
agoncal named (for most of the commands), targetPackage (for the new commands),
targetClass (for the add commands)...
agoncal And then you also end up "duplicating" attributes : example the
"qualifiers" are used in several CDI commands
gastaldi right
agoncal So the idea was giving up inheritance (AsbtractCDINewCommand,
AbstractJPACommand....) in favor of aggragation
agoncal And then gastaldi came with an idea
agoncal gastaldi your turn ;o)
gastaldi my idea was to introduce some classes with the common inputs containing @Inject
UIInputxxx and then @Inject the aggregate class in the command
gastaldi something like @Inject DefaultCDIInputs inputs;
gastaldi and then in the initializeUI you could call inputs.initializeUI(builder)
gastaldi and fetch the values
agoncal gastaldi But also more specific ones ? Such as @Inject DefaultCDIQualifier,
@Inject DefaultJPAField... ?
gastaldi that could work too
gastaldi hm, maybe we could introduce a "input-only" concept here
gastaldi a class that has only injected inputs
gastaldi that would save some memory, by lazy-injecting them
gastaldi right now, every @Inject in the command is resolved every time a command is
executed
agoncal And one suggestion was to start with the "qualifiers" attribute (used
in several new CDI commands)
gastaldi agoncal, what do you mean by that, specifically?
agoncal gastaldi Well, if we could start introducing the concept after this release, and
if yes, the "qualifiers" attribute could be a good start
gastaldi you mean having a separate class for the inputs?
agoncal gastaldi Yes
gastaldi yeah, we can think about it in the next version. Still needs some thought to
become a pattern
agoncal gastaldi Ok, let's keep on exchanging on the subject
soro I didn't understand this yet. We have some issue of some document to explain
about it or will be discussed in future?
soro about this "qualifiers"
agoncal soro "qualifiers" is just an example
agoncal soro Basically, how do you aggregate common attributes into a command
soro agoncal, ah... ok!
soro nice!
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.3.15#6346)