[JBoss JIRA] (FORGE-2468) Being able to add methods to an existing JSF backing bean
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2468?page=com.atlassian.jira.plugin... ]
George Gastaldi updated FORGE-2468:
-----------------------------------
Labels: Starter (was: )
> Being able to add methods to an existing JSF backing bean
> ---------------------------------------------------------
>
> Key: FORGE-2468
> URL: https://issues.jboss.org/browse/FORGE-2468
> Project: Forge
> Issue Type: Sub-task
> Components: Java EE
> Affects Versions: 2.19.0.Final
> Reporter: Antonio Goncalves
> Labels: Starter
> Fix For: 2.x Future
>
>
> It would be good to be able to add methods to a JSF backing bean with the following command :
> {code}
> faces-add-method --named myMethod
> {code}
> Most of the JSF methods return a String which is the page to go to (null means "go to the current page"). This would add the following {{myMethod}} method to the existing backing bean :
> {code}
> @Named
> public class MyBackingBean {
> public String myMethod() {
> return null;
> }
> {code}
> We could also have a outcome parameter which will be the page to go to :
> {code}
> faces-add-method --named myMethod --outcome main.xhtml
> {code}
> Gives :
> {code}
> @Named
> public class MyBackingBean {
> public String myMethod() {
> return "main.xhtml";
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGE-2469) Getting a design pattern right for add commands
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2469?page=com.atlassian.jira.plugin... ]
Antonio Goncalves updated FORGE-2469:
-------------------------------------
Description:
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}
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}
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}
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}
was:
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}
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}
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}
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}
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}
> 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}
> 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}
> 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}
> 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)
10 years, 8 months
[JBoss JIRA] (FORGE-2469) Getting a design pattern right for add commands
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/FORGE-2469?page=com.atlassian.jira.plugin... ]
Antonio Goncalves updated FORGE-2469:
-------------------------------------
Description:
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}
was:
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}
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}
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}
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}
> 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)
10 years, 8 months
[JBoss JIRA] (FORGE-2469) Getting a design pattern right for add commands
by Antonio Goncalves (JIRA)
Antonio Goncalves created FORGE-2469:
----------------------------------------
Summary: 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}
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}
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}
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}
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)
10 years, 8 months
[JBoss JIRA] (FORGE-2468) Being able to add methods to an existing JSF backing bean
by Antonio Goncalves (JIRA)
Antonio Goncalves created FORGE-2468:
----------------------------------------
Summary: Being able to add methods to an existing JSF backing bean
Key: FORGE-2468
URL: https://issues.jboss.org/browse/FORGE-2468
Project: Forge
Issue Type: Sub-task
Components: Java EE
Affects Versions: 2.19.0.Final
Reporter: Antonio Goncalves
Fix For: 2.x Future
It would be good to be able to add methods to a JSF backing bean with the following command :
{code}
faces-add-method --named myMethod
{code}
Most of the JSF methods return a String which is the page to go to (null means "go to the current page"). This would add the following {{myMethod}} method to the existing backing bean :
{code}
@Named
public class MyBackingBean {
public String myMethod() {
return null;
}
{code}
We could also have a outcome parameter which will be the page to go to :
{code}
faces-add-method --named myMethod --outcome main.xhtml
{code}
Gives :
{code}
@Named
public class MyBackingBean {
public String myMethod() {
return "main.xhtml";
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (FORGEPLUGINS-209) JPA Entities using @MappedSuperclass don't get recognized by Scaffold: Generate for AngularJS/Rest Endpoint from Entity
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGEPLUGINS-209?page=com.atlassian.jira.... ]
George Gastaldi moved FORGE-2467 to FORGEPLUGINS-209:
-----------------------------------------------------
Project: Forge Plugins/Addons (was: Forge)
Key: FORGEPLUGINS-209 (was: FORGE-2467)
Issue Type: Bug (was: Enhancement)
Component/s: AngularJS Scaffold
(was: Scaffold)
Affects Version/s: (was: 2.16.1.Final)
Fix Version/s: (was: 2.x Future)
> JPA Entities using @MappedSuperclass don't get recognized by Scaffold: Generate for AngularJS/Rest Endpoint from Entity
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: FORGEPLUGINS-209
> URL: https://issues.jboss.org/browse/FORGEPLUGINS-209
> Project: Forge Plugins/Addons
> Issue Type: Bug
> Components: AngularJS Scaffold
> Environment: Eclipse MARS,
> Reporter: Matyas Danter
>
> When JPA Entities use a @MappedSuperclass that provides the @id field, the Scaffold: Generate wizard's AngularJS option, and Rest Endpoint from Entities command don't show the Entities in the selection table.
> The entities DO appear in the JSF scaffolding table. It would be helpful if Endpoint creation and Scaffolding supported @MappedSuperclass and @Embedded entities containing the ID or primary key fields.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (FORGE-2467) JPA Entities using @MappedSuperclass don't get recognized by Scaffold: Generate for AngularJS/Rest Endpoint from Entity
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2467?page=com.atlassian.jira.plugin... ]
George Gastaldi updated FORGE-2467:
-----------------------------------
Fix Version/s: 2.x Future
> JPA Entities using @MappedSuperclass don't get recognized by Scaffold: Generate for AngularJS/Rest Endpoint from Entity
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: FORGE-2467
> URL: https://issues.jboss.org/browse/FORGE-2467
> Project: Forge
> Issue Type: Enhancement
> Components: Scaffold
> Affects Versions: 2.16.1.Final
> Environment: Eclipse MARS,
> Reporter: Matyas Danter
> Fix For: 2.x Future
>
>
> When JPA Entities use a @MappedSuperclass that provides the @id field, the Scaffold: Generate wizard's AngularJS option, and Rest Endpoint from Entities command don't show the Entities in the selection table.
> The entities DO appear in the JSF scaffolding table. It would be helpful if Endpoint creation and Scaffolding supported @MappedSuperclass and @Embedded entities containing the ID or primary key fields.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (FORGE-2467) JPA Entities using @MappedSuperclass don't get recognized by Scaffold: Generate for AngularJS/Rest Endpoint from Entity
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2467?page=com.atlassian.jira.plugin... ]
George Gastaldi commented on FORGE-2467:
----------------------------------------
Hi Matyas, thank you for your feedback. Do you have a test case we could use to reproduce the problem?
The entity classes or the steps you have done to create the entities will also help.
> JPA Entities using @MappedSuperclass don't get recognized by Scaffold: Generate for AngularJS/Rest Endpoint from Entity
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: FORGE-2467
> URL: https://issues.jboss.org/browse/FORGE-2467
> Project: Forge
> Issue Type: Enhancement
> Components: Scaffold
> Affects Versions: 2.16.1.Final
> Environment: Eclipse MARS,
> Reporter: Matyas Danter
>
> When JPA Entities use a @MappedSuperclass that provides the @id field, the Scaffold: Generate wizard's AngularJS option, and Rest Endpoint from Entities command don't show the Entities in the selection table.
> The entities DO appear in the JSF scaffolding table. It would be helpful if Endpoint creation and Scaffolding supported @MappedSuperclass and @Embedded entities containing the ID or primary key fields.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months