You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> on 2013/06/13 16:12:20 UTC
New template
Following the current implementation of the "dependencies" collection on the ToDoItem class, the following code template would be of interest for "ordered collections".
I've defined it with name "iscss" and description "Collection (set-sorted)", just as an example.
// {{ ${CollectionName} (Collection)
${:import(java.util.SortedSet,java.util.TreeSet,org.apache.isis.applib.annotation.MemberOrder)}private SortedSet<${ElementType}> ${collectionName} = new TreeSet<${ElementType}>();
@MemberOrder(sequence="1")
public SortedSet<${ElementType}> get${CollectionName}() {
return ${collectionName};
}
public void set${CollectionName}(final SortedSet<${ElementType}> ${collectionName}) {
this.${collectionName} = ${collectionName};
}
// }}
Also, is there any annotation that could allow the "addTo[CollectionName]" and "removeFrom[CollectionName]" to be available on the user interface?
In most collections, those names are "just valid" for the Ubiquitous Language.
If not available, or if is not recommended breaking the rule of not publishing to the UI the programming model methods , I could add a new template based on the "iscmod" like this one. which I've called "iscmoda" - "Collection modify (with actions)":
${:import(org.apache.isis.applib.annotation.MemberOrder)}// Action.
@MemberOrder(name="${collectionName}", sequence="1")
public ${enclosing_type} insertInto${CollectionName}(final ${ElementType} ${elementName}) {
addTo${CollectionName}(${elementName});
return this;
}
// Programming model.
public void addTo${CollectionName}(final ${ElementType} ${elementName}) {
// check for no-op
if (${elementName} == null ||
get${CollectionName}().contains(${elementName})) {
return;
}
// associate new
get${CollectionName}().add(${elementName});
// additional business logic
onAddTo${CollectionName}(${elementName});
}
// Action.
@MemberOrder(name="${collectionName}", sequence="2")
public ${enclosing_type} deleteFrom${CollectionName}(final ${ElementType} ${elementName}) {
removeFrom${CollectionName}(${elementName});
return this;
}
// Programming model.
public void removeFrom${CollectionName}(final ${ElementType} ${elementName}) {
// check for no-op
if (${elementName} == null ||
!get${CollectionName}().contains(${elementName})) {
return;
}
// dissociate existing
get${CollectionName}().remove(${elementName});
// additional business logic
onRemoveFrom${CollectionName}(${elementName});
}
protected void onAddTo${CollectionName}(final ${ElementType} ${elementName}) {
}
protected void onRemoveFrom${CollectionName}(final ${ElementType} ${elementName}) {
}
Just for all those reasons, I've defined a new template, "iscssa" - "Collection (set-sorted-with actions)" that riquires 4 inputs for a collection with "add/insert" and "delete/remove" actions:
// {{ ${CollectionName} (Collection)
${:import(java.util.SortedSet,java.util.TreeSet,org.apache.isis.applib.annotation.MemberOrder)}private SortedSet<${ElementType}> ${collectionName} = new TreeSet<${ElementType}>();
@MemberOrder(sequence="1")
public SortedSet<${ElementType}> get${CollectionName}() {
return ${collectionName};
}
public void set${CollectionName}(final SortedSet<${ElementType}> ${collectionName}) {
this.${collectionName} = ${collectionName};
}
@MemberOrder(name="${collectionName}", sequence="1")
public ${enclosing_type} insertInto${CollectionName}(final ${ElementType} ${elementName}) {
addTo${CollectionName}(${elementName});
return this;
}
// Programming model.
public void addTo${CollectionName}(final ${ElementType} ${elementName}) {
// check for no-op
if (${elementName} == null ||
get${CollectionName}().contains(${elementName})) {
return;
}
// associate new
get${CollectionName}().add(${elementName});
// additional business logic
onAddTo${CollectionName}(${elementName});
}
// Action.
@MemberOrder(name="${collectionName}", sequence="2")
public ${enclosing_type} deleteFrom${CollectionName}(final ${ElementType} ${elementName}) {
removeFrom${CollectionName}(${elementName});
return this;
}
// Programming model.
public void removeFrom${CollectionName}(final ${ElementType} ${elementName}) {
// check for no-op
if (${elementName} == null ||
!get${CollectionName}().contains(${elementName})) {
return;
}
// dissociate existing
get${CollectionName}().remove(${elementName});
// additional business logic
onRemoveFrom${CollectionName}(${elementName});
}
protected void onAddTo${CollectionName}(final ${ElementType} ${elementName}) {
}
protected void onRemoveFrom${CollectionName}(final ${ElementType} ${elementName}) {
}
// }}
Re: New template
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Not a problem to postpone those changes to the Wicket viewer, don't worry.
We are customizing our Wavemaker solution to run with Isis.
El 13/06/2013, a las 18:56, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> On 13 June 2013 15:12, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
>>
>> Following the current implementation of the "dependencies" collection on
>> the ToDoItem class, the following code template would be of interest for
>> "ordered collections".
>>
>> I've defined it with name "iscss" and description "Collection
>> (set-sorted)", just as an example.
>> [snip]
>
>
> Thanks, Oscar.
>
>
>
>> Also, is there any annotation that could allow the "addTo[CollectionName]"
>> and "removeFrom[CollectionName]" to be available on the user interface?
>>
>> In most collections, those names are "just valid" for the Ubiquitous
>> Language.
>>
>
> Um, no, there isn't. Those methods are actually explicitly removed from
> the metamodel when their parent collection is detected.
>
> That said, the Wicket viewer is slightly deficient here. Isis itself
> supports the notion of mutable collections (with an implicit
> addTo/removeFrom), but the Wicket viewer's collections are always
> immutable. The attaching of add and remove actions "adjacent" to the
> collections started off as a simple rendering trick, and has since evolved
> into a defacto mutable collection.
>
>
> What I really need to do is fix this deficiency; Wicket will automatically
> synthesize the 'add' and 'remove' actions if the collection is not
> immutable.
>
> I've raised a ticket for this [1]. Not sure when I'll get around to doing
> it though; not a top priority for me, and will be a bit fiddly.
>
>
>
>>
>> If not available, or if is not recommended breaking the rule of not
>> publishing to the UI the programming model methods , I could add a new
>> template based on the "iscmod" like this one. which I've called "iscmoda" -
>> "Collection modify (with actions)":
>>
>
>> [snip]
>
>
>
>> Just for all those reasons, I've defined a new template, "iscssa" -
>> "Collection (set-sorted-with actions)" that riquires 4 inputs for a
>> collection with "add/insert" and "delete/remove" actions:
>>
>> [snip]
>
>
> OK, I've added all three templates to the isis-templates.xml file, and
> uploaded to the site. Many thanks for these contributions.
>
> I've also taken the opportunity to add in two new templates: "ispauto" and
> "isaauto" for the new autoCompleteXxx(String) support [2], [3]
>
> Cheers
> Dan
>
> [1] https://issues.apache.org/jira/browse/ISIS-439
> [2]
> http://isis.apache.org/applib-guide/how-tos/how-to-03-015-How-to-specify-an-autocomplete-for-a-property.html
> [3]
> http://isis.apache.org/applib-guide/how-tos/how-to-03-025-How-to-specify-an-autocomplete-for-an-action-parameter.html
Re: New template
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 13 June 2013 15:12, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
> Following the current implementation of the "dependencies" collection on
> the ToDoItem class, the following code template would be of interest for
> "ordered collections".
>
> I've defined it with name "iscss" and description "Collection
> (set-sorted)", just as an example.
> [snip]
Thanks, Oscar.
> Also, is there any annotation that could allow the "addTo[CollectionName]"
> and "removeFrom[CollectionName]" to be available on the user interface?
>
> In most collections, those names are "just valid" for the Ubiquitous
> Language.
>
Um, no, there isn't. Those methods are actually explicitly removed from
the metamodel when their parent collection is detected.
That said, the Wicket viewer is slightly deficient here. Isis itself
supports the notion of mutable collections (with an implicit
addTo/removeFrom), but the Wicket viewer's collections are always
immutable. The attaching of add and remove actions "adjacent" to the
collections started off as a simple rendering trick, and has since evolved
into a defacto mutable collection.
What I really need to do is fix this deficiency; Wicket will automatically
synthesize the 'add' and 'remove' actions if the collection is not
immutable.
I've raised a ticket for this [1]. Not sure when I'll get around to doing
it though; not a top priority for me, and will be a bit fiddly.
>
> If not available, or if is not recommended breaking the rule of not
> publishing to the UI the programming model methods , I could add a new
> template based on the "iscmod" like this one. which I've called "iscmoda" -
> "Collection modify (with actions)":
>
> [snip]
> Just for all those reasons, I've defined a new template, "iscssa" -
> "Collection (set-sorted-with actions)" that riquires 4 inputs for a
> collection with "add/insert" and "delete/remove" actions:
>
> [snip]
OK, I've added all three templates to the isis-templates.xml file, and
uploaded to the site. Many thanks for these contributions.
I've also taken the opportunity to add in two new templates: "ispauto" and
"isaauto" for the new autoCompleteXxx(String) support [2], [3]
Cheers
Dan
[1] https://issues.apache.org/jira/browse/ISIS-439
[2]
http://isis.apache.org/applib-guide/how-tos/how-to-03-015-How-to-specify-an-autocomplete-for-a-property.html
[3]
http://isis.apache.org/applib-guide/how-tos/how-to-03-025-How-to-specify-an-autocomplete-for-an-action-parameter.html