[
https://issues.jboss.org/browse/FORGE-2469?page=com.atlassian.jira.plugin...
]
Antonio Goncalves commented on FORGE-2469:
------------------------------------------
19:58:21 gastaldi In order to make that possible, I think we need to model them as
decorators
19:58:56 gastaldi Or create proxies for these interfaces, which I dont like personally
20:00:11 gastaldi We can have an AbstractUIInputDelegate
20:00:39 agoncal gastaldi Hum..... decorators..... could be a good idea actually
20:00:50 agoncal It adds extra behavior to a UIComponent
20:00:56 gastaldi Yes
20:01:09 agoncal Not bad at all actually
20:01:23 gastaldi I want to make that interface extend UIInput, but I don't want
people to extend the impl class
20:02:02 gastaldi The UIInput original implementation I mean
20:03:39 gastaldi So we'll have a interface TargetPackage extends
UIInput<String>
20:04:14 gastaldi And a class TargetPackageImpl extends
AbstractUIInputDelegate<String> extends TargetPackage
20:04:28 agoncal And that would be the decorator ?
20:04:34 gastaldi Yes
20:04:56 gastaldi It will take the original UIInput in the constructor
20:05:04 agoncal And same question : what if we need to "customize" the
behavior of targetClass ?
20:05:22 gastaldi How so?
20:05:43 agoncal Let's say :
20:06:11 agoncal 1) targetClass in java-add-method points at *all* the classes in the
project
20:06:48 agoncal 2) targetClass in jpa-add-lifecycle method point at *just* @Entity
classes
20:07:02 gastaldi That could be defined as methods in the TargetPackage interface
20:07:11 agoncal Both are implementation of TargetClass interface
20:07:41 agoncal But different implementation.... or different decorator actually
20:08:18 gastaldi JPATargetClass?
20:08:26 agoncal Too restrictive
20:08:32 gastaldi Agreed
20:08:49 agoncal We are coming back to the inheritance model we want to leave
20:08:56 gastaldi Yes
20:09:44 gastaldi Well. You could do that in the initializeUI method of your command
20:11:09 gastaldi Basically by having a interface TargetPackage extends
UIInput<String> we are releasing the burden of the developer to remember which
UIInput to use in this case
20:11:49 gastaldi All the necessary methods are there, and they are populated as they are
meant to be
20:11:52 agoncal gastaldi Yes, I think it's a better compromise : use the
initializeUI method to customize the target package or target class
20:12:30 gastaldi agoncal: yes, because that is a very specific scenario (only
@Entities)
20:13:22 agoncal gastaldi Hum... not so sure because we could be very precise then
faces-add-method, servlet-add-method....
20:13:44 agoncal and have several targetClass "implementation"
20:14:00 agoncal But basically, this will cover most of the cases, and as you say, ease
the life of new comers
20:14:46 gastaldi Yes, this won't replace what we already have, just ease the life as
you said
Getting a design pattern right for add commands
-----------------------------------------------
Key: FORGE-2469
URL:
https://issues.jboss.org/browse/FORGE-2469
Project: Forge
Issue Type: Sub-task
Components: Java EE
Affects Versions: 2.19.0.Final
Reporter: Antonio Goncalves
Fix For: 2.x Future
The {{new}} commands are straight forward, we just create a new artifact (mostly classes
in the Java EE addon). {{add}} commands are meant to add code to existing code. So all the
add}} commands have a {{targetClass}} attribute. The {{targetClass}} points to the current
class, or can point to a different one.
The algorithm to get the {{targetClass}} is very different from command to command (see
below). It would be very helpfull to find a generic design pattern that could be
applicable to most of the {{add}} commands.
{code:title=JavaEqualsHashcodeCommand}
@Override
public void initializeUI(UIBuilder builder) throws Exception
{
(...)
UISelection<Object> initialSelection = uiContext.getInitialSelection();
if (initialSelection.get() instanceof JavaResource)
{
targetClass.setValue((JavaResource) initialSelection.get());
}
targetClass.setValueChoices(projectOperations.getProjectClasses(project));
@Override
public Result execute(UIExecutionContext context) throws Exception
{
(...)
if (targetClass.hasMethodSignature("equals", Object.class))
{
if (prompt.promptBoolean("Class already has an equals method. Would you
like it to be overwritten?"))
{code}
{code:title=CDIAddInjectionPointCommand}
private void setupTargetClasses(UIContext uiContext)
{
UISelection<FileResource<?>> selection =
uiContext.getInitialSelection();
Project project = getSelectedProject(uiContext);
final List<JavaResource> classes =
cdiOperations.getProjectInjectionPointBeans(project);
targetClass.setValueChoices(classes);
int idx = -1;
if (!selection.isEmpty())
{
idx = classes.indexOf(selection.get());
}
if (idx == -1)
{
idx = classes.size() - 1;
}
if (idx != -1)
{
targetClass.setDefaultValue(classes.get(idx));
}
}
{code}
{code:title=CDIAddObserverMethodCommand}
private void setupTargetClass(UIContext uiContext, Project project)
{
UISelection<Resource<?>> resource = uiContext.getInitialSelection();
if (resource.get() instanceof JavaResource)
{
targetClass.setDefaultValue((JavaResource) resource.get());
}
targetClass.setValueChoices(projectOperations.getProjectClasses(project));
}
{code}
{code:title=FacesNewValidatorMethodCommand}
public void initializeUI(UIBuilder builder) throws Exception
{
Object selection = builder.getUIContext().getInitialSelection().get();
if (selection instanceof JavaResource)
{
targetClass.setDefaultValue((JavaResource) selection);
}
builder.add(targetClass).add(named);
}
@Override
public void validate(UIValidationContext validator)
{
try
{
JavaClassSource source =
targetClass.getValue().reify(JavaResource.class).getJavaType();
(...)
}
catch (FileNotFoundException e)
{
validator.addValidationError(targetClass, "Target Java class not
found.");
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)