Re: ISIS-970 ... (new annotations) please review if you get a chance...
Folks, Thank you all so much for your contributions to this thread and also one I created on users@isis.a.o [1], discussing simplified a new set of annotations, as suggested in ISIS-970 [2]. I've decided to continue the discussion on this thread as it's hosted most of the conversation to date. If you reply then please include both users@ and dev@ so both users and contributors are kept in the loop. ~ It seems to me that there's no clear consensus as to what set of annotations we should go with; any decision will be seen as not ideal by at least some users. The most debate has been about whether to retain @ViewModel, or whether or not to merge it into @DomainObject. Oscar, David, Ahmed, Vladimir, Jeremy and Mike all (I think) expressed a preference for retaining @ViewModel. Jeroen, Martin, Kevin and I all preferred removing @ViewModel and merging it into @DomainObject (though some of those opinions were made prior to the spirited debate that followed, so I don't know if anyone in this second list has revised their opinion). If @ViewModel is retained, then there was a subsidiary idea as to whether to replace @DomainObject with @DomainEntity (so it would be @ViewModel and @DomainEntity). One or two have been in favour of that idea, but it's not had overwhelming endorsement. Ged offered the opinion that a view model is more like a domain event. No one else replied to that idea. For myself, I don't think that's correct, but it got me thinking. Rather, domain events are what we emit through the (current) @ActionInteraction/@PropertyInteraction/@CollectionInteraction annotations. In ISIS-970 I proposed replacing @ActionInteraction with @Action(interaction=...) etc. Ged's mention of domain events makes me think it should instead be @Action(domainEvent=...). I've updated the JIRA ticket accordingly. I also made a proposal about adding Domain as a prefix to @Property, @Collection, @Action... but no-one seems particularly in favour of that. ~~~ Before I go onto my own proposal for resolving this debate, let me just remind everyone that in Isis it's possible to write metamodel validators. We use these to check for no orphaned methods such as disableXxx(); I'm sure many will have encountered this. But it's also possible to write and register your own metamodel validators via isis.properties. Also, for Isis 1.8.0 we'll be releasing an Isis Maven plugin that allows the metamodel validation to be performed as part of the build, rather than rely on running up the app or its integration tests. There's an example of this in the simpleapp example [3] (and thus, will be part of the 1.8.0 archetype). I mention this because it opens up the concept of dialects of the Isis programming model, enforceable through the build pipeline. Out-of-the-box Isis can provide support for all dialects, but individual projects can constrain these by registering appropriate metamodel validators as they see fit. ~~~ So, my proposal is as follows: for the UI/app layer, retain/introduce: * @ViewModel * @ViewModelLayout for the domain layer: * @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | UI_VIEW) * @DomainObjectLayout for both: * @Property(domainEvent=..., ) and @PropertyLayout * @Collection(domainEvent=..., ) and @CollectionLayout * @Action(domainEvent=..., ) and @ActionLayout * @Parameter and @ParameterLayout Those that want to draw explicit attention to UI/app layer view models should use @ViewModel, and should ignore @DomainObject(nature=UI_VIEW). These folks might want to use a metamodel validator to ensure that @DomainObject(nature=UI_VIEW) is not used anywhere in their codebase. Conversely, those that consider that its all just domain objects should ignore @ViewModel, and instead use @DomainObject(nature=UI_VIEW). These folks might want to use a metamodel validator to ensure that @ViewModel is not used anywhere in their codebase. The @DomainObject(nature=JDO_ENTITY) is for regular Isis managed/persisted entities, while @DomainObject(nature=EXTERNAL_ENTITY) is for entities that are managed by some external system. Internally Isis installs a ViewModelFacet for these so that it knows how to manage their ongoing identity (in essence corresponding to the external system's URI for that entity), but that's an implementation detail. @ViewModelLayout and @DomainObjectLayout are basically identical. The above proposal does NOT include the introduction of @DomainEntity. ~~~ Opinions? I'm kinda hoping this will get us to some sort of consensus ... Thanks Dan [1] http://isis.markmail.org/thread/ng22jsmxeq55ewny [2] https://issues.apache.org/jira/browse/ISIS-970 [3] https://github.com/apache/isis/blob/a5b728f0606fa12c254ca1a0ecd49b88b816d6df/example/application/simpleapp/dom/pom.xml#L136 On 3 January 2015 at 11:23, David Tildesley davo...@yahoo.co.nz wrote: Hi Oscar, Seems to me it's the same thing: Let me add some clarity to that DDD example you shared: Port --- Domain Model ---Adapter is just a
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Hi Oscar, Seems to me it's the same thing: Let me add some clarity to that DDD example you shared: Port --- Domain Model ---Adapter is just a different set of terms for the same layers: User Interface -- Problem Domain --- System Interface Chaining applications together in an integration you get Adapter A of AppA calling Port B of AppB and so on - which I am guessing is what you meant by Inter Domain. Clearly ViewModel fits into Port quite nicely. In fact it's the only place it belongs. But Intra Domain? Does ISIS in some way prevent a domain object calling another domain object's operation directly? Anyway I suspect that's a separate discussion. The bottom line is that we can't stop people bleeding domain model behaviour out into viewmodels, however what we can do is to make it as clear and unambiguous as possible by avoiding/reducing overloading of terms/concepts and suggesting the correct approach to building an application. My single piece of advice to folk: If you want to avoid a disaster then make sure you model your problem domain in a just enough consensus modelling exercise before your team goes anywhere near View Models or any other part of the UI layer. ISIS offers nothing new that would change this advice. However View Models could be the scaffolding that you end up hanging yourself and your team on if you don't understand that they are not part of your domain model. I guess I should shut up now as I am just repeating myself. In summary: Big Tick for the addition of: @DomainObject (External) so that we don't have to misuse @ViewModel Regards,David. On Saturday, 3 January 2015 10:24 PM, GESCONSULTOR o@gesconsultor.com wrote: Hi David! What it's clear is that properties/collections can be useful not only for domain layer objects, so the @Domain prefix should not be added. Regarding the Application Layer, I agree that sometimes it can be a clear indication of an anemic domain. But properly implemented and used, it's well accepted on the DDD community as a way to create a layer over domain entities for orchestrating them. They're useful for representing Domain Entities the way is most useful for the end-user as perhaps the Domain Entities have been designed from another perpective different from that concrete use case. There are some examples on the latest book, Implementing DDD by Caughn Vernon. That use case is really similar to the most common use in Apache ISIS, with the advantage that the UI is automatically generated from it Anyway I don't advocate for using ViewModels only for the Application Layer, but in all case where views can be useful, including intra-domain or inter-domain use cases (for example, for modeling the integration patterns described on the Implementing DDD book such as Ports and Adapters. as an example sure you will find interesting this sole implementation made by Vernon, and how they could be implementing by Apache Isis[1]. So yes, as you said we must be careful with anemic domains :)) Regards, Oscar [1] https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_collaboration/src/main/java/com/saasovation/collaboration El 1/1/2015, a las 20:45, David Tildesley davo...@yahoo.co.nz escribió: Hi Oscar, I think we may be looking at the tail wagging the dog in this part of the thread. I.e. the reason why Jeroen has found ViewModels for some of the scenarios he outlined (e.g. External Entity service integration) so useful was because there was no alternative available to him. This is where Option 1 tidies things up from a conceptual layer point of view, as discussed earlier in the post, but doesn't in any way prevent you from doing what you suggest below if that is what you believe is correct i.e. there would nothing forcing you to use @ DomainObject (External) - you could instead carry on using @ViewModel within your domain layer if that is what you think is correct. For those of us that believe this is conceptually wrong, Option 1 keeps us happy because now we have @ DomainObject (External) available to us and furthermore, it allows @DomainObject (External) to evolve independently of @ViewModel sometime in the future. i.e. Option 1 removes the layer overloading as Dan already points out. On a further note, I don't like to use the concept Application Layer - this layer was invented by those that ran into difficulty when forced to use EJB 1 2 and unfortunately persisted even when the POJO movement started (maybe because it was easier to migrate from the EJB 1 2 legacy). I.e the presence of an Application Layer concept is a very strong indicator of the presence of Anemic Domain Model anti-pattern [1] and this is pointed out by Martin Fowler. Assuming a rich domain model then, what may be thought of as the Application Layer is really just part of the UI layer. [1] bliki: AnemicDomainModel bliki: AnemicDomainModel If you use
Re: Isis + Neo4j 2.1.6
Great work, Jeremy! I haven't checked your changes yet but since there is a task about upgrading to DataNucleus 4.x [1] I think it would be great if you send a Pull Request [2]. The Neo4j demo app could be used as a test in Isis to make sure we don't break the integration by accident in the future. 1. https://issues.apache.org/jira/browse/ISIS-789 2. https://help.github.com/articles/using-pull-requests/ Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Sat, Jan 3, 2015 at 12:00 AM, Branham, Jeremy [HR] jeremy.d.bran...@sprint.com wrote: If you are interested in running Isis with Neo4j - Have a look at this branch that contains a sample application [neoapp] based on the 'simpleapp' example. https://github.com/jdbranham/isis/tree/DN_404 And a small extension that enables the embedded Neo4j services - including the Neo4j browser, admin tools, and rest services. https://github.com/Sprint/isis-neo4j The Isis extension is small, and the one class could be copied and pasted into your application rather than building the jar. Hope this helps someone! Note - This branch uses DataNucleus 4.0.4 so there are currently many deviations from the master, though all tests are currently passing. Jeremy D. Branham Technology Architect Sprint University Performance Support Fort Worth, TX | Tel: **DOTNET Office: +1 (972) 405-2970| Mobile: +1 (817) 791-1627 This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
Re: IntelliJ Templates + Apache Isis
Thanks for sharing, Jeremy ! @Dan: Maybe it is a good idea to add a link to this repo at http://www.isisaddons.org/ ? Or even fork Jeremy's repo to https://github.com/isisaddons or your/mine own GitHub account so it is easier for us to update it in the future. For example I'd prefer to namespace the template names. Or make them File Templates instead of Live Templates. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Sat, Jan 3, 2015 at 4:30 AM, Branham, Jeremy [HR] jeremy.d.bran...@sprint.com wrote: I've added a few code templates for IntelliJ IDEA that help me build domain objects and services rapidly. Available here - https://github.com/Sprint/ide-templates It only takes me a few seconds now to scaffold new classes and properties. Dan/Martin - Thanks for turning me on to IDEA. I'm really digging it. This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
Re: Best Documentation for writing first Isis App
Just bringing this back on-list... ... Joshua was asking about some tutorial documentation for Isis, something in the style that Rails has [1], [2] so I've started working on some. It's still work-in-progress, but I think there's already enough there for it to be useful. There's a page on our website [3], with corresponding github repo [4]. I'll continue to add to it as and when I have time. My intention is to flesh out the use cases for this app, and then in later iterations to refactor in order to demonstrate how Isis supports decoupling using contributed actions/collections and also the event bus. Cheers Dan [1] http://12devs.co.uk/articles/writing-a-web-application-with-ruby-on-rails/ [2] http://guides.rubyonrails.org/getting_started.html [3] http://isis.apache.org/intro/tutorials/step-by-step-petclinic.html [4] https://github.com/danhaywood/isis-app-petclinic
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Hi Dan! Thanks for this proposal. Just some thoughts. i don't see compatible an option called UI_VIEW in a domain object. Perhaps just VIEW? If that's the case, what would differentiate it from a @ViewModel? That said, it would keep JDO_ENTITY, EXTERNAL_ENTITY (I love that concept :). Regarding the VIEW option, if implementation is nearly the same as @ViewModel the only reason to keep it would be the consensus. So it ok for me. If that wouldn't be introduced, the only options available would JDO_ENTITY and EXTERNAL_ENTITY given as a clear indication that the annotation could be named @DomainEntity ... :)) What a pity!!! El 3/1/2015, a las 12:59, Dan Haywood d...@haywood-associates.co.uk escribió: Folks, Thank you all so much for your contributions to this thread and also one I created on users@isis.a.o [1], discussing simplified a new set of annotations, as suggested in ISIS-970 [2]. I've decided to continue the discussion on this thread as it's hosted most of the conversation to date. If you reply then please include both users@ and dev@ so both users and contributors are kept in the loop. ~ It seems to me that there's no clear consensus as to what set of annotations we should go with; any decision will be seen as not ideal by at least some users. The most debate has been about whether to retain @ViewModel, or whether or not to merge it into @DomainObject. Oscar, David, Ahmed, Vladimir, Jeremy and Mike all (I think) expressed a preference for retaining @ViewModel. Jeroen, Martin, Kevin and I all preferred removing @ViewModel and merging it into @DomainObject (though some of those opinions were made prior to the spirited debate that followed, so I don't know if anyone in this second list has revised their opinion). If @ViewModel is retained, then there was a subsidiary idea as to whether to replace @DomainObject with @DomainEntity (so it would be @ViewModel and @DomainEntity). One or two have been in favour of that idea, but it's not had overwhelming endorsement. Ged offered the opinion that a view model is more like a domain event. No one else replied to that idea. For myself, I don't think that's correct, but it got me thinking. Rather, domain events are what we emit through the (current) @ActionInteraction/@PropertyInteraction/@CollectionInteraction annotations. In ISIS-970 I proposed replacing @ActionInteraction with @Action(interaction=...) etc. Ged's mention of domain events makes me think it should instead be @Action(domainEvent=...). I've updated the JIRA ticket accordingly. I also made a proposal about adding Domain as a prefix to @Property, @Collection, @Action... but no-one seems particularly in favour of that. ~~~ Before I go onto my own proposal for resolving this debate, let me just remind everyone that in Isis it's possible to write metamodel validators. We use these to check for no orphaned methods such as disableXxx(); I'm sure many will have encountered this. But it's also possible to write and register your own metamodel validators via isis.properties. Also, for Isis 1.8.0 we'll be releasing an Isis Maven plugin that allows the metamodel validation to be performed as part of the build, rather than rely on running up the app or its integration tests. There's an example of this in the simpleapp example [3] (and thus, will be part of the 1.8.0 archetype). I mention this because it opens up the concept of dialects of the Isis programming model, enforceable through the build pipeline. Out-of-the-box Isis can provide support for all dialects, but individual projects can constrain these by registering appropriate metamodel validators as they see fit. ~~~ So, my proposal is as follows: for the UI/app layer, retain/introduce: * @ViewModel * @ViewModelLayout for the domain layer: * @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | UI_VIEW) * @DomainObjectLayout for both: * @Property(domainEvent=..., ) and @PropertyLayout * @Collection(domainEvent=..., ) and @CollectionLayout * @Action(domainEvent=..., ) and @ActionLayout * @Parameter and @ParameterLayout Those that want to draw explicit attention to UI/app layer view models should use @ViewModel, and should ignore @DomainObject(nature=UI_VIEW). These folks might want to use a metamodel validator to ensure that @DomainObject(nature=UI_VIEW) is not used anywhere in their codebase. Conversely, those that consider that its all just domain objects should ignore @ViewModel, and instead use @DomainObject(nature=UI_VIEW). These folks might want to use a metamodel validator to ensure that @ViewModel is not used anywhere in their codebase. The @DomainObject(nature=JDO_ENTITY) is for regular Isis managed/persisted entities, while @DomainObject(nature=EXTERNAL_ENTITY) is for entities that are managed by some external system. Internally Isis installs a ViewModelFacet for these so that it knows how to manage
Re: Showing action results as tabs attached to entity pages
Many thanks, Dan.
El 3/1/2015, a las 16:39, Dan Haywood d...@haywood-associates.co.uk
escribió:
I've raised
* ISIS-993 [1] - for splitting out object into multiple tabs and
* ISIS-994 [2] - contributed properties that return a URL should be shown
inline within an iframe.
[1] https://issues.apache.org/jira/browse/ISIS-993
[2] https://issues.apache.org/jira/browse/ISIS-994
On 13 December 2014 at 17:32, GESCONSULTOR - Óscar Bou
o@gesconsultor.com wrote:
Hi to all.
I've uploaded some screenshots.
I'm going to explain different behaviors or implementation alternatives that
perhaps are of interest, including the ones exposed on previous posts on
this thread.
On [1], you can see the general current appearance of our entity forms.
Perhaps we wouldn't choose the toolbar paradigm right now, but it allows to
keep all forms with similar lookfeel and a predefined set of actions
defined.
The green menu button contains menu items for all factory methods of the
current entity.
The grey one contains the available actions detected through Isis metadata.
I'll explain on a coming thread an alternative implementation for default
entity delete and collection remove actions.
As you can see, there are 2 different rows of tabs: the outer ones
(Contributed Tabs) and the inner ones (Views).
*** ENTITY VIEWS ***
On screenshot [2] I've identified the inner tabs.
Those are automatically generated as a complement to sections. We call
them Views.
That way, we can divide entity properties and collections not only in
sections, but also on different views. There's always a General view
present by default.
The annotations for Entities (@XMSViews) Property (@XMSInViews - same
property/collection could be shown in more than one view) can be used as in
this example:
@XMSViews({ @XMSView(name = Dependency Assets, sequence = 110),
@XMSView(name = Impacted Assets, sequence = 120),
@XMSView(name = Associated Costs, sequence = 130) })
public abstract class Asset extends AbstractMultiTenantEntity {
// {{ RelationshipsWithDirectlyImpactedAssets (Collection)
@Persistent(mappedBy = sourceAsset, dependentElement = false)
private SortedSetRelationship relationshipsWithDirectlyImpactedAssets
= new TreeSetRelationship();
@Named((SUMMARY) Relationships - Directly Impacted Assets)
@XMSInViews(Impacted Assets, Other View)
@MemberOrder(sequence = 999)
public SortedSetRelationship
getRelationshipsWithDirectlyImpactedAssets() {
return this.relationshipsWithDirectlyImpactedAssets;
}
public void setRelationshipsWithDirectlyImpactedAssets(final
SortedSetRelationship relationshipsAsSource) {
this.relationshipsWithDirectlyImpactedAssets = relationshipsAsSource;
}
// }}
...
}
*** CONTRIBUTED VIEWS ***
On screenshot [3], I've identified the contributed tabs.
They should the result of a contributed action on a different tab, instead
of being showed as a contributed property/collection.
For example, in [4] you can see the form corresponding to the Entity
returned by an action that has been properly annotated on a Service with
@XMSContributedView (our current implementation is a bit different, as we
were including translations on them; but I've preferred to simplify).
public class AssetsBCMInformation extends
AbstractSingletonMultiTenantObjectRepositoryAndFactoryAssetBCMInformation {
@NotContributed(As.EITHER)
@DescribedAs(Contains the detailed Business Continuity Requirements for
a given Asset)
@ActionSemantics(Of.SAFE)
@XMSContributedView
public AssetBCMInformation businessContinuityInformation(@Named(Asset)
final Asset asset) {
...
}
...
}
Perhaps both Entity Contributed Views could be showed all-together on the
same tab control, without requiring two tab rows.
CONTRIBUTED VIEW REFERRING TO AN EXTERNAL URL ***
On [5], the content of a Contributed View is an external URL (on this case
is a highly customized diagram editor).
Hope all this helps to clarify past posts ... :)
Regards,
Oscar
[1] http://s23.postimg.org/ndvn4huez/Main_Form.png
[2] http://postimg.org/image/xg7mbfvh9/
[3] http://postimg.org/image/ucxki507l/
[4] http://postimg.org/image/43plbkg7j/
[5] http://postimg.org/image/k83i6b70x/
El 12/12/2014, a las 15:31, GESCONSULTOR o@gesconsultor.com escribió:
Ok.
I'll send them this weekend.
El 12/12/2014, a las 14:47, Dan Haywood d...@haywood-associates.co.uk
escribió:
Some screenshots/sketches would probably be useful; I'm not certain I'm
following everything you're saying here.
On 12 December 2014 at 13:37, GESCONSULTOR o@gesconsultor.com wrote:
Also, not sure about the default...
I think that they should be shown by default on the same page.
At least, is our current implementation and is
Re: Showing action results as tabs attached to entity pages
I've raised
* ISIS-993 [1] - for splitting out object into multiple tabs and
* ISIS-994 [2] - contributed properties that return a URL should be shown
inline within an iframe.
[1] https://issues.apache.org/jira/browse/ISIS-993
[2] https://issues.apache.org/jira/browse/ISIS-994
On 13 December 2014 at 17:32, GESCONSULTOR - Óscar Bou
o@gesconsultor.com wrote:
Hi to all.
I've uploaded some screenshots.
I'm going to explain different behaviors or implementation alternatives
that perhaps are of interest, including the ones exposed on previous posts
on this thread.
On [1], you can see the general current appearance of our entity forms.
Perhaps we wouldn't choose the toolbar paradigm right now, but it allows to
keep all forms with similar lookfeel and a predefined set of actions
defined.
The green menu button contains menu items for all factory methods of the
current entity.
The grey one contains the available actions detected through Isis metadata.
I'll explain on a coming thread an alternative implementation for default
entity delete and collection remove actions.
As you can see, there are 2 different rows of tabs: the outer ones
(Contributed Tabs) and the inner ones (Views).
*** ENTITY VIEWS ***
On screenshot [2] I've identified the inner tabs.
Those are automatically generated as a complement to sections. We call
them Views.
That way, we can divide entity properties and collections not only in
sections, but also on different views. There's always a General view
present by default.
The annotations for Entities (@XMSViews) Property (@XMSInViews - same
property/collection could be shown in more than one view) can be used as in
this example:
@XMSViews({ @XMSView(name = Dependency Assets, sequence = 110),
@XMSView(name = Impacted Assets, sequence = 120),
@XMSView(name = Associated Costs, sequence = 130) })
public abstract class Asset extends AbstractMultiTenantEntity {
// {{ RelationshipsWithDirectlyImpactedAssets (Collection)
@Persistent(mappedBy = sourceAsset, dependentElement = false)
private SortedSetRelationship
relationshipsWithDirectlyImpactedAssets = new TreeSetRelationship();
@Named((SUMMARY) Relationships - Directly Impacted Assets)
@XMSInViews(Impacted Assets, Other View)
@MemberOrder(sequence = 999)
public SortedSetRelationship
getRelationshipsWithDirectlyImpactedAssets() {
return this.relationshipsWithDirectlyImpactedAssets;
}
public void setRelationshipsWithDirectlyImpactedAssets(final
SortedSetRelationship relationshipsAsSource) {
this.relationshipsWithDirectlyImpactedAssets =
relationshipsAsSource;
}
// }}
...
}
*** CONTRIBUTED VIEWS ***
On screenshot [3], I've identified the contributed tabs.
They should the result of a contributed action on a different tab, instead
of being showed as a contributed property/collection.
For example, in [4] you can see the form corresponding to the Entity
returned by an action that has been properly annotated on a Service with
@XMSContributedView (our current implementation is a bit different, as we
were including translations on them; but I've preferred to simplify).
public class AssetsBCMInformation extends
AbstractSingletonMultiTenantObjectRepositoryAndFactoryAssetBCMInformation
{
@NotContributed(As.EITHER)
@DescribedAs(Contains the detailed Business Continuity Requirements
for a given Asset)
@ActionSemantics(Of.SAFE)
@XMSContributedView
public AssetBCMInformation
businessContinuityInformation(@Named(Asset) final Asset asset) {
...
}
...
}
Perhaps both Entity Contributed Views could be showed all-together on
the same tab control, without requiring two tab rows.
CONTRIBUTED VIEW REFERRING TO AN EXTERNAL URL ***
On [5], the content of a Contributed View is an external URL (on this case
is a highly customized diagram editor).
Hope all this helps to clarify past posts ... :)
Regards,
Oscar
[1] http://s23.postimg.org/ndvn4huez/Main_Form.png
[2] http://postimg.org/image/xg7mbfvh9/
[3] http://postimg.org/image/ucxki507l/
[4] http://postimg.org/image/43plbkg7j/
[5] http://postimg.org/image/k83i6b70x/
El 12/12/2014, a las 15:31, GESCONSULTOR o@gesconsultor.com
escribió:
Ok.
I'll send them this weekend.
El 12/12/2014, a las 14:47, Dan Haywood d...@haywood-associates.co.uk
escribió:
Some screenshots/sketches would probably be useful; I'm not certain I'm
following everything you're saying here.
On 12 December 2014 at 13:37, GESCONSULTOR o@gesconsultor.com wrote:
Also, not sure about the default...
I think that they should be shown by default on the same page.
At least, is our current implementation and is working nicely.
Sorry ... :)
El 12/12/2014, a las 14:29, Dan Haywood d...@haywood-associates.co.uk
escribió:
ok, yes, that helps.
In which case I think that all would be required is to
Re: Default implementations for Delete Entity and Collection Remove actions
I've raised ISIS-991 [1] and ISIS-992 [2] for these two points.
The first (collections) I agree with, shold be implemented; the second
(delete action) I'm not so sure.
Dan
[1] https://issues.apache.org/jira/browse/ISIS-991
[2] https://issues.apache.org/jira/browse/ISIS-992.
On 13 December 2014 at 18:08, GESCONSULTOR - Óscar Bou
o@gesconsultor.com wrote:
There are a lot of cases where the implementation of those operations is
the same, and Isis could avoid to explicitly implement it.
For entities, normally is something like:
public void delete(Entity entity) {
this.getContainer().remove(entity);
this.getContainer().flush();
}
Perhaps flush can be optional, perhaps if implemented directly on the
entity there shouldn't be any params, but base code remains the same.
If all entities have a common descendant, it can be implemented on a
generic service that accepts one instance as a param. But perhaps that
basic operation could be implemented directly by the framework.
Its deletion could be vetoed by means of the Isis removing() method, for
example, and also by means of the EventServiceBus.
Perhaps a default implementation on an Isis service could be given?
But there's another case that it's polluting our domain entities and we
haven't achieve a standard way to implement it, despite I think it's
possible.
For nearly each collection, we need:
- an addXXX action (that normally accepts one existing instance of the
collection elements - i.e., a Price List adding existing Items -).
- sometimes, a createXXX action (that create an instance and after that
calls addXXX; think of an Aggregated Root creating all contained Entity
instances - i.e., an Order creating new Line Items -).
- a deleteXXX action (that mainly consists of a
getCollection.remove(entity); if the collection was annotated with
dependentElement=true, the instance will removed AND deleted by
DataNucleus after executing it).
From those three, createXXX need custom business logic to work and cannot
be easily generalized (createXXX needs required fields of the entity
created).
But addXXX and deleteXXX, when available, have a quite generic
implementation:
@PersistenceCapable
@Inheritance(strategy = InheritanceStrategy.NEW_TABLE)
@Discriminator(value = BusinessService)
public class InformationSystem extends ApplicationComponent {
// {{ UsesSoftwareServices (Collection)
@Persistent(mappedBy = usedByInformationSystem, dependentElement
= false)
private SortedSetSoftwareService usesSoftwareServices = new
TreeSetSoftwareService();
@MemberOrder(sequence = 710)
public SortedSetSoftwareService getUsesSoftwareServices() {
return this.usesSoftwareServices;
}
public void setUsesSoftwareServices(final SortedSetSoftwareService
usesSoftwareServices) {
this.usesSoftwareServices = usesSoftwareServices;
}
// }}
// {{ addSoftwareService (action)
@ActionSemantics(Of.IDEMPOTENT)
@MemberOrder(name = usesSoftwareServices, sequence = 010)
public void addSoftwareService(@XMSBulkParam @Named(Software
Service) final SoftwareService softwareService) {
this.getUsesSoftwareServices().add(softwareService);
this.getContainer().flush();
}
// }}
// {{ deleteFromUsesSoftwareServices (action)
@ActionSemantics(Of.IDEMPOTENT)
@MemberOrder(name = usesSoftwareServices, sequence = 020)
public void deleteFromUsesSoftwareServices(@XMSBulkParam @Named(Servicio
de Software) final SoftwareService softwareService) {
this.getUsesSoftwareServices().remove(softwareService);
this.getContainer().flush();
}
// }}
...
}
Couldn't they be provided by default also by Isis?
For example, by annotating the collection with something similar to:
@Collection(addAction=Add Software Service, deleteAction=Remove
Software Service)
Which would reduced the code to:
@PersistenceCapable
@Inheritance(strategy = InheritanceStrategy.NEW_TABLE)
@Discriminator(value = BusinessService)
public class InformationSystem extends ApplicationComponent {
// {{ UsesSoftwareServices (Collection)
@Persistent(mappedBy = usedByInformationSystem, dependentElement
= false)
private SortedSetSoftwareService usesSoftwareServices = new
TreeSetSoftwareService();
@Collection(addMethodName=Add Software Service, deleteAction=Remove
Software Service)
@MemberOrder(sequence = 710)
public SortedSetSoftwareService getUsesSoftwareServices() {
return this.usesSoftwareServices;
}
public void setUsesSoftwareServices(final SortedSetSoftwareService
usesSoftwareServices) {
this.usesSoftwareServices = usesSoftwareServices;
}
// }}
...
}
If I remember it well, Martin suggested once something similar for
collections.
Perhaps am I missing anything not allowing such generic implementations
being supported by Isis ?
Regards,
RE: Removing the ObjectAdapter mappings
So either your machine is much slower or your changes made the build slower ?! I suspect it's this enterprise laptop that's loaded down with services [and streaming music =] But I'll need to check if I left extra validations turned on during the integration tests. Jeremy D. Branham Tel: **DOTNET -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Saturday, January 03, 2015 6:42 AM To: users Subject: Re: Removing the ObjectAdapter mappings Hi Jeremy, On Fri, Jan 2, 2015 at 8:15 AM, Branham, Jeremy [HR] jeremy.d.bran...@sprint.com wrote: So removing the HashMaps turned out to be more work then I'm ready for right now. [I threw that branch out] The good news is that the DN 4.x branch is now working. There were some 'instanceOf' checks for PersistenceCapable that I missed before. Now to use the latest Neo4j =] [INFO] Reactor Summary: [INFO] [INFO] Apache Isis Core .. SUCCESS [2.668s] [INFO] Isis Core Unit Test Support ... SUCCESS [7.635s] [INFO] Isis Core AppLib .. SUCCESS [10.587s] [INFO] Isis Core Log4j Impls . SUCCESS [0.871s] [INFO] Isis Core MetaModel ... SUCCESS [42.513s] [INFO] Isis Core Runtime . SUCCESS [13.920s] [INFO] Isis Core Wrapper Service . SUCCESS [2.948s] [INFO] Isis Core WebServer ... SUCCESS [0.906s] [INFO] Isis Core (Bypass) Security ... SUCCESS [0.693s] [INFO] Isis Core Shiro Security .. SUCCESS [2.455s] [INFO] Isis Core Spec Support SUCCESS [0.911s] [INFO] Isis Core Integration Testing Support . SUCCESS [1.545s] [INFO] Isis Core RestfulObjects Viewer AppLib SUCCESS [3.395s] [INFO] Isis Core RestfulObjects Viewer Rendering . SUCCESS [3.072s] [INFO] Isis Core RestfulObjects Viewer Server SUCCESS [3.164s] [INFO] Isis Maven Plugin (isis-maven-plugin) . SUCCESS [4.312s] [INFO] Isis Wicket Viewer SUCCESS [0.230s] [INFO] Isis Wicket Viewer Applib . SUCCESS [0.569s] [INFO] Isis Wicket Viewer Model .. SUCCESS [2.586s] [INFO] Isis Wicket Viewer UI Components .. SUCCESS [20.864s] [INFO] Isis Wicket Viewer Implementation . SUCCESS [3.407s] [INFO] Isis TCK App .. SUCCESS [0.174s] [INFO] Isis TCK DOM .. SUCCESS [2.157s] [INFO] Isis TCK Fixtures . SUCCESS [0.664s] [INFO] Isis TCK IntegTests ... SUCCESS [2.958s] [INFO] Isis RestfulObjects Viewer TCK tests .. SUCCESS [6.109s] [INFO] Isis TCK Wicket Viewer tests .. SUCCESS [3.455s] [INFO] ToDo App .. SUCCESS [0.089s] [INFO] ToDo App DOM .. SUCCESS [3.398s] [INFO] ToDo App Fixtures . SUCCESS [0.972s] [INFO] ToDo App Integration Tests SUCCESS [25.814s] [INFO] ToDo App Webapp ... SUCCESS [18.974s] [INFO] Simple App SUCCESS [0.010s] [INFO] Simple App DOM SUCCESS [1.911s] [INFO] Simple App Fixtures ... SUCCESS [0.639s] [INFO] Simple App Integration Tests .. SUCCESS [8.050s] [INFO] Simple App Webapp . SUCCESS [16.134s] [INFO] todoapp-archetype . SUCCESS [20.689s] [INFO] simpleapp-archetype ... SUCCESS [6.850s] [INFO] Isis Scimpi Viewer SUCCESS [0.362s] [INFO] Isis Scimpi Viewer Dispatcher . SUCCESS [10.513s] [INFO] Isis Scimpi Viewer Servlet SUCCESS [1.043s] [INFO] Apache Isis (Aggregator) .. SUCCESS [0.485s] [INFO] -- -- [INFO] BUILD SUCCESS [INFO] -- -- [INFO] Total time: 4:22.458s How long it takes to build Isis master branch at your machine ? Here it takes 01:26min and my laptop is 2+ years old now. So either your machine is much slower or your changes made the build slower ?! I guess it is the first but wanted to check. [INFO] Finished at: Fri Jan 02 00:11:45 CST 2015 [INFO] Final Memory: 130M/920M [INFO] -- -- Jeremy D. Branham Tel: **DOTNET -Original Message- From: Branham, Jeremy [HR] Sent: Thursday, January 01, 2015
RE: Isis + Neo4j 2.1.6
Thanks guys - I'm glad to make the contribution. I've been leveraging OSS for more than 15 years; it's about time I start paying the community back ;) Jeremy D. Branham Tel: **DOTNET -Original Message- From: Dan Haywood [mailto:d...@haywood-associates.co.uk] Sent: Saturday, January 03, 2015 7:48 AM To: users Subject: Re: Isis + Neo4j 2.1.6 Jeremy, really good stuff. Appreciate I didn't get round to answering all of your earlier questions, but happy with the direction you've gone. Picking up on Martin's email, I've created a new branch ISIS-789 on origin and merged in your branch there. Obviously, I want to do a full review of the work first, plus run some regression tests, before merging into master. In particular, I need to wrap my head around the use of org.datanucleus.enhancer.Persistable instead of javax.jdo.spi.PersistenceCapable. I suspect it's all fine and won't impact end users, but need to double check etc. But thanks a lot, again. I appreciate that there's a lot of work in that branch. Meantime, if you add any further commits, please add the ISIS-789: as a prefix to the commit messages. Cheers Dan On 3 January 2015 at 11:14, Martin Grigorov mgrigo...@apache.org wrote: Great work, Jeremy! I haven't checked your changes yet but since there is a task about upgrading to DataNucleus 4.x [1] I think it would be great if you send a Pull Request [2]. The Neo4j demo app could be used as a test in Isis to make sure we don't break the integration by accident in the future. 1. https://issues.apache.org/jira/browse/ISIS-789 2. https://help.github.com/articles/using-pull-requests/ Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Sat, Jan 3, 2015 at 12:00 AM, Branham, Jeremy [HR] jeremy.d.bran...@sprint.com wrote: If you are interested in running Isis with Neo4j - Have a look at this branch that contains a sample application [neoapp] based on the 'simpleapp' example. https://github.com/jdbranham/isis/tree/DN_404 And a small extension that enables the embedded Neo4j services - including the Neo4j browser, admin tools, and rest services. https://github.com/Sprint/isis-neo4j The Isis extension is small, and the one class could be copied and pasted into your application rather than building the jar. Hope this helps someone! Note - This branch uses DataNucleus 4.0.4 so there are currently many deviations from the master, though all tests are currently passing. Jeremy D. Branham Technology Architect Sprint University Performance Support Fort Worth, TX | Tel: **DOTNET Office: +1 (972) 405-2970| Mobile: +1 (817) 791-1627 This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
Re: Isis + Neo4j 2.1.6
Jeremy, really good stuff. Appreciate I didn't get round to answering all of your earlier questions, but happy with the direction you've gone. Picking up on Martin's email, I've created a new branch ISIS-789 on origin and merged in your branch there. Obviously, I want to do a full review of the work first, plus run some regression tests, before merging into master. In particular, I need to wrap my head around the use of org.datanucleus.enhancer.Persistable instead of javax.jdo.spi.PersistenceCapable. I suspect it's all fine and won't impact end users, but need to double check etc. But thanks a lot, again. I appreciate that there's a lot of work in that branch. Meantime, if you add any further commits, please add the ISIS-789: as a prefix to the commit messages. Cheers Dan On 3 January 2015 at 11:14, Martin Grigorov mgrigo...@apache.org wrote: Great work, Jeremy! I haven't checked your changes yet but since there is a task about upgrading to DataNucleus 4.x [1] I think it would be great if you send a Pull Request [2]. The Neo4j demo app could be used as a test in Isis to make sure we don't break the integration by accident in the future. 1. https://issues.apache.org/jira/browse/ISIS-789 2. https://help.github.com/articles/using-pull-requests/ Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Sat, Jan 3, 2015 at 12:00 AM, Branham, Jeremy [HR] jeremy.d.bran...@sprint.com wrote: If you are interested in running Isis with Neo4j - Have a look at this branch that contains a sample application [neoapp] based on the 'simpleapp' example. https://github.com/jdbranham/isis/tree/DN_404 And a small extension that enables the embedded Neo4j services - including the Neo4j browser, admin tools, and rest services. https://github.com/Sprint/isis-neo4j The Isis extension is small, and the one class could be copied and pasted into your application rather than building the jar. Hope this helps someone! Note - This branch uses DataNucleus 4.0.4 so there are currently many deviations from the master, though all tests are currently passing. Jeremy D. Branham Technology Architect Sprint University Performance Support Fort Worth, TX | Tel: **DOTNET Office: +1 (972) 405-2970| Mobile: +1 (817) 791-1627 This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
RE: ISIS-970 ... (new annotations) please review if you get a chance...
This is a good compromise IMHO. Jeremy D. Branham Tel: **DOTNET -Original Message- From: Dan Haywood [mailto:d...@haywood-associates.co.uk] Sent: Saturday, January 03, 2015 7:27 AM To: users Cc: d...@isis.apache.org Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance... On 3 January 2015 at 13:14, Jeroen van der Wal jer...@stromboli.it wrote: I have one more thought: since @ViewModel and @DomainObject(nature=UI_VIEW) are the same concepts it might be more intuitive to use @DomainObject(nature=VIEW_MODEL) Yes, that probably does make sense; we are just providing two equivalent syntaxes for describing a (UI) view model. So the revised proposal is: for the UI/app layer, retain/introduce: * @ViewModel * @ViewModelLayout for the domain layer: * @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | VIEW_MODEL) * @DomainObjectLayout for both: * @Property(domainEvent=..., ) and @PropertyLayout * @Collection(domainEvent=..., ) and @CollectionLayout * @Action(domainEvent=..., ) and @ActionLayout * @Parameter and @ParameterLayout where @ViewModel and @DomainObject(nature=VIEW_MODEL) are basically equivalent; choose whichever notation you prefer (and use a metamodel validator to exclude the other). thx Dan This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Good consensus for me also :) El 3/1/2015, a las 18:48, Branham, Jeremy [HR] jeremy.d.bran...@sprint.com escribió: This is a good compromise IMHO. Jeremy D. Branham Tel: **DOTNET -Original Message- From: Dan Haywood [mailto:d...@haywood-associates.co.uk] Sent: Saturday, January 03, 2015 7:27 AM To: users Cc: d...@isis.apache.org Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance... On 3 January 2015 at 13:14, Jeroen van der Wal jer...@stromboli.it wrote: I have one more thought: since @ViewModel and @DomainObject(nature=UI_VIEW) are the same concepts it might be more intuitive to use @DomainObject(nature=VIEW_MODEL) Yes, that probably does make sense; we are just providing two equivalent syntaxes for describing a (UI) view model. So the revised proposal is: for the UI/app layer, retain/introduce: * @ViewModel * @ViewModelLayout for the domain layer: * @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | VIEW_MODEL) * @DomainObjectLayout for both: * @Property(domainEvent=..., ) and @PropertyLayout * @Collection(domainEvent=..., ) and @CollectionLayout * @Action(domainEvent=..., ) and @ActionLayout * @Parameter and @ParameterLayout where @ViewModel and @DomainObject(nature=VIEW_MODEL) are basically equivalent; choose whichever notation you prefer (and use a metamodel validator to exclude the other). thx Dan This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
