Re: New screencasts for v1.12.0

[David Tildesley]

Thanks Dan,Very useful.
Cheers,David.

Sent from Yahoo Mail on Android 
 
  On Sat, 2 Apr, 2016 at 0:00, Dan Haywood 
wrote:   Hi folks,

I've spent a few evenings recording some new screencasts for v1.12.0 [1]
 Do take a look, you'll probably see something that you weren't aware of.

I plan to do some more still ... there's still lots of functionality that
hasn't covered.  If there's anything particularly you'd like me to cover,
do say.

Feedback welcome as always.

Thx
Dan

[1] http://isis.apache.org/screencasts.html
  

[jira] [Commented] (ISIS-1303) Rename the project to better describe its values and purpose

[David Tildesley (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15136043#comment-15136043
 ] 

David Tildesley commented on ISIS-1303:
---

Picking up on Dan's list of prompts, I thing DDAQ (Domain Driven Applications 
Quickly) is a good candidate. It rolls off the tongue nicely ("Deedack"). A 
quick google on DDAQ didn't reveal anything of concern.

In fact it looks very "available".

David. 

> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
> Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD community got massively sidetracked for a while by the CQRS pattern is 
> perhaps part of it.   I also often detect the view that DDD should imply not 
> using a framework.  The irony of course is that in rejecting framework such 
> developers actually have to write more infrastructure code vs business domain 
> code.
> Also, the fit is perhaps not all that good after all.  In the DDD community I 
> don't see anyone talking about modules... one of the named patterns, and a 
> major focus of our framework, but missing from DDD talks.  Instead they get 
> side-tracked talking only about aggregate roots or bounded contexts; all well 
> and good, but over-emphasised).
> [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
> person), and he agreed there was little emphasis.  When I described our 
> framework's use of domain events to hook modules together (along with vetoing 
> behaviour we support) he admitted it was a new approach/pattern to him...]
> Anyway, so DDD - which looked so promising - hasn't delivered.  They might 
> come around to us one day, but it's probably time to define our own 
> individual space.  Also, in the same way that everyone takes agile 
> development for granted as the "de facto", we ought to simply take DDD for 
> granted too... "of course you will be doing DDD, but are you doing it well?"
> What we need to better market the framework is some other pattern or concept 
> or hook, and become known as the framework that best supports that idea.  
> There are several candidates:
> - hexagonal architecture (also called ports and adapters, or the onion 
> architecture, and related to the clean architecture)
> - don't repeat yourself principle
> - aspect oriented programming (naked objects pattern is really the 
> recognition that UI presentation is a cross-cutting concern)
> - the general concept of modularity
> - DCI (data/context/interactions).
> - "clean" "pure" "essential" pojo programming model
> - agile, lean
> - breaking down barriers between IT and business
> Of these, I think that hexagonal arch

[jira] [Commented] (ISIS-1303) Rename the project to better describe its values and purpose

[David Tildesley (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134896#comment-15134896
 ] 

David Tildesley commented on ISIS-1303:
---

Hi All,

My suggestion: Apache Jedu

"Jedu" is Czech for "Jet" which invokes the idea of "rapid", "speed".

JEDU is "Just Enough Design Upfront" - sweet spot for Apache ISIS as a tool to 
aid consensus based domain modelling  - which is JEDU in practice.

David.


> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
> Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD community got massively sidetracked for a while by the CQRS pattern is 
> perhaps part of it.   I also often detect the view that DDD should imply not 
> using a framework.  The irony of course is that in rejecting framework such 
> developers actually have to write more infrastructure code vs business domain 
> code.
> Also, the fit is perhaps not all that good after all.  In the DDD community I 
> don't see anyone talking about modules... one of the named patterns, and a 
> major focus of our framework, but missing from DDD talks.  Instead they get 
> side-tracked talking only about aggregate roots or bounded contexts; all well 
> and good, but over-emphasised).
> [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
> person), and he agreed there was little emphasis.  When I described our 
> framework's use of domain events to hook modules together (along with vetoing 
> behaviour we support) he admitted it was a new approach/pattern to him...]
> Anyway, so DDD - which looked so promising - hasn't delivered.  They might 
> come around to us one day, but it's probably time to define our own 
> individual space.  Also, in the same way that everyone takes agile 
> development for granted as the "de facto", we ought to simply take DDD for 
> granted too... "of course you will be doing DDD, but are you doing it well?"
> What we need to better market the framework is some other pattern or concept 
> or hook, and become known as the framework that best supports that idea.  
> There are several candidates:
> - hexagonal architecture (also called ports and adapters, or the onion 
> architecture, and related to the clean architecture)
> - don't repeat yourself principle
> - aspect oriented programming (naked objects pattern is really the 
> recognition that UI presentation is a cross-cutting concern)
> - the general concept of modularity
> - DCI (data/context/interactions).
> - "clean" "pure" "essential" pojo programming model
> - agile, lean
> - breaking down barriers between IT and business
> 

[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose

[David Tildesley (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134896#comment-15134896
 ] 

David Tildesley edited comment on ISIS-1303 at 2/5/16 8:42 PM:
---

Hi All,

My suggestion: Apache Jedu

JEDU is "Just Enough Design Upfront" - sweet spot for Apache ISIS as a tool to 
aid consensus based domain modelling  - which is JEDU in practice.

N.B. - removed the reference to Czech translation - I got that wrong - sorry. 
As a Czech sounding verb equivalent, apparently it may mean "go" / "take a 
ride".

Remarkably, while easy to pronounce, it really doesn't have any meanings in 
languages according to Google search apart from the Czech verb reference.

David.



was (Author: davotnz):
Hi All,

My suggestion: Apache Jedu

JEDU is "Just Enough Design Upfront" - sweet spot for Apache ISIS as a tool to 
aid consensus based domain modelling  - which is JEDU in practice.

N.B. - removed the reference to Czech translation - I got that wrong - sorry.

David.


> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
> Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD community got massively sidetracked for a while by the CQRS pattern is 
> perhaps part of it.   I also often detect the view that DDD should imply not 
> using a framework.  The irony of course is that in rejecting framework such 
> developers actually have to write more infrastructure code vs business domain 
> code.
> Also, the fit is perhaps not all that good after all.  In the DDD community I 
> don't see anyone talking about modules... one of the named patterns, and a 
> major focus of our framework, but missing from DDD talks.  Instead they get 
> side-tracked talking only about aggregate roots or bounded contexts; all well 
> and good, but over-emphasised).
> [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
> person), and he agreed there was little emphasis.  When I described our 
> framework's use of domain events to hook modules together (along with vetoing 
> behaviour we support) he admitted it was a new approach/pattern to him...]
> Anyway, so DDD - which looked so promising - hasn't delivered.  They might 
> come around to us one day, but it's probably time to define our own 
> individual space.  Also, in the same way that everyone takes agile 
> development for granted as the "de facto", we ought to simply take DDD for 
> granted too... "of course you will be doing DDD, but are you doing it well?"
> What we need to better market the framework is some other pattern or concept 
> or hook, and become known as the framework that best supports that idea.  
> There are se

[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose

[David Tildesley (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134896#comment-15134896
 ] 

David Tildesley edited comment on ISIS-1303 at 2/5/16 8:23 PM:
---

Hi All,

My suggestion: Apache Jedu

JEDU is "Just Enough Design Upfront" - sweet spot for Apache ISIS as a tool to 
aid consensus based domain modelling  - which is JEDU in practice.

N.B. - removed the reference to Czech translation - I got that wrong - sorry.

David.



was (Author: davotnz):
Hi All,

My suggestion: Apache Jedu

"Jedu" is Czech for "Jet" which invokes the idea of "rapid", "speed".

JEDU is "Just Enough Design Upfront" - sweet spot for Apache ISIS as a tool to 
aid consensus based domain modelling  - which is JEDU in practice.

David.


> Rename the project to better describe its values and purpose
> 
>
> Key: ISIS-1303
> URL: https://issues.apache.org/jira/browse/ISIS-1303
> Project: Isis
>  Issue Type: Wish
>Affects Versions: 1.11.1
>Reporter: Dan Haywood
>Assignee: Dan Haywood
> Fix For: 1.13.0
>
> Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg
>
>
> In the past there have been a couple of discussions regarding renaming the 
> project, the reason generally cited being the potential embarrassment of 
> sharing a name with the jihadist militant group [1] currently prominent in 
> the headlines.  After due discussion on the mailing lists the prevailing view 
> has been to retain our name: "we were here first".  
> Until now I've concurred with that view also... after all, I originally came 
> up with the name "Isis", originally based on the name of the Thames as it 
> flows through Oxford [2] (many of the original authors of the framework live 
> within Oxfordshire, UK).
> Separately to that discussion, we have the issue of marketing.  Originally we 
> marketed ourselves as a framework implementing the "naked objects" pattern 
> [3]; the original name of the framework (prior to Apache) was of course the 
> Naked Objects Framework.  However, this pattern is either not well-known or 
> is misunderstood (only a low proportion of developers that encounter the idea 
> immediately "get it").  The crudity of the original user interfaces didn't 
> help.  And the name also, of course, can cause embarrassment in some cultures.
> Then, when domain-driven design [4] came along as a movement, that seemed an 
> obvious platform upon which to position the framework: we obviously share the 
> core belief that the domain is the most important bit of the system.  However 
> - and I still find this surprising - despite attempts otherwise we haven't 
> really made too much of an impression in that community.  The fact that the 
> DDD community got massively sidetracked for a while by the CQRS pattern is 
> perhaps part of it.   I also often detect the view that DDD should imply not 
> using a framework.  The irony of course is that in rejecting framework such 
> developers actually have to write more infrastructure code vs business domain 
> code.
> Also, the fit is perhaps not all that good after all.  In the DDD community I 
> don't see anyone talking about modules... one of the named patterns, and a 
> major focus of our framework, but missing from DDD talks.  Instead they get 
> side-tracked talking only about aggregate roots or bounded contexts; all well 
> and good, but over-emphasised).
> [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in 
> person), and he agreed there was little emphasis.  When I described our 
> framework's use of domain events to hook modules together (along with vetoing 
> behaviour we support) he admitted it was a new approach/pattern to him...]
> Anyway, so DDD - which looked so promising - hasn't delivered.  They might 
> come around to us one day, but it's probably time to define our own 
> individual space.  Also, in the same way that everyone takes agile 
> development for granted as the "de facto", we ought to simply take DDD for 
> granted too... "of course you will be doing DDD, but are you doing it well?"
> What we need to better market the framework is some other pattern or concept 
> or hook, and become known as the framework that best supports that idea.  
> There are several candidates:
> - hexagonal architecture (also called ports and adapters, or the onion 
> architecture, and related to the clean architecture)
> - don't repeat yourself principle
> - aspect oriented pr

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[David Tildesley]

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-970 ... (new annotations) please review if you get a chance...

[David Tildesley]

For me also. It is a good consensus.

Thanks,
David.

Sent from Yahoo Mail on Android

ViewModel documentation update.

[David Tildesley]

Hi,
Thought this would be better as a separate thread. There is a current document 
page on ISIS wiki [1] describing ISIS View Model. I think this is a good 
description of ISIS View Model as it reinforces that you may on occasion have 
need of a View Model for some UI scenarios but otherwise it is not the norm.
I would suggest adding the following:
One of the compelling things about ISIS based applications is that the cost of 
the UI/Application layer is zero if you don't make use of 'View Models'.
So the sensible thing to do with this powerful tool when building non-trivial 
business applications is:
(1) Focus on the overall domain model (particularly the shape which in turn 
gets influenced by the domain behaviour required - so sorting out the business 
behaviour up front with your business subject matter experts avoids an 
unsuitable shape that results from a CRUD behaviour alone). The domain model 
as represented by a UML class/object model should be devoid of all 
infrastructure plumbing concerns.
(2) Build the ISIS app with just using Domain Objects taken directly from the 
Domain Model only (do not introduce View Models at this crucial stage).
(3) Verify the domain model with the business  using the live application from 
(2) and adjust as necessary.
(4) Once you have a consensus with the overall domain model then you can have a 
discussion with the business about any specialised UI interactions that might 
require the use of a View Model or several. 
(5) Add as many View Models over time as necessary but don't use these to 
compensate for an inadequate Domain Model and don't use them in lieu of a 
required extension to the Domain Model (a good domain model shape that more or 
less follows Peter Coad's Domain Neutral Component archetypal domain shape will 
stand you in good stead for extensibility and longevity). 
(6) Never be tempted to put domain logic into View Models. 
(7) Never have any of the domain objects dependent on View Models. I.e. The 
direction of dependency is one way: The View Models depend on the Domain Layer.
[1] ViewModels
|   |
|   |   |   |   |   |
| ViewModelsDocs »More Advanced Topics ViewModels In most cases users can 
accomplish the business operations they need by invoking actions directly on 
domain entities.  |
|  |
| View on isis.apache.org | Preview by Yahoo |
|  |
|   |

 [2] Model Archetypes and the Domain Neutral Component
|   |
|   |  |   |   |   |   |   |
| Model Archetypes and the Domain Neutral ComponentPeter Coad's 'Modeling in 
color' defines four class archetypes. A model archetype is a typical structure 
of collobaorating classes that guides the rapid constructio... |
|  |
| View on www.step-10.com | Preview by Yahoo |
|  |
|   |

 

Re: ViewModel documentation update.

[David Tildesley]

Hi,
Apologies for Yahoo Mail mangling my reference URLs below. It's a recent 
feature and I have just figured out it causes a problem and how to deactivate 
it.
Anyway, here is another go at the URLs:
[1] http://isis.apache.org/more-advanced-topics/ViewModel.html[2] 
http://www.step-10.com/SoftwareDesign/ModellingInColour/dnc.html
   

 On Sunday, 4 January 2015 10:53 AM, David Tildesley davo...@yahoo.co.nz 
wrote:
   

 Hi,
Thought this would be better as a separate thread. There is a current document 
page on ISIS wiki [1] describing ISIS View Model. I think this is a good 
description of ISIS View Model as it reinforces that you may on occasion have 
need of a View Model for some UI scenarios but otherwise it is not the norm.
I would suggest adding the following:
One of the compelling things about ISIS based applications is that the cost of 
the UI/Application layer is zero if you don't make use of 'View Models'.
So the sensible thing to do with this powerful tool when building non-trivial 
business applications is:
(1) Focus on the overall domain model (particularly the shape which in turn 
gets influenced by the domain behaviour required - so sorting out the business 
behaviour up front with your business subject matter experts avoids an 
unsuitable shape that results from a CRUD behaviour alone). The domain model 
as represented by a UML class/object model should be devoid of all 
infrastructure plumbing concerns.
(2) Build the ISIS app with just using Domain Objects taken directly from the 
Domain Model only (do not introduce View Models at this crucial stage).
(3) Verify the domain model with the business  using the live application from 
(2) and adjust as necessary.
(4) Once you have a consensus with the overall domain model then you can have a 
discussion with the business about any specialised UI interactions that might 
require the use of a View Model or several. 
(5) Add as many View Models over time as necessary but don't use these to 
compensate for an inadequate Domain Model and don't use them in lieu of a 
required extension to the Domain Model (a good domain model shape that more or 
less follows Peter Coad's Domain Neutral Component archetypal domain shape will 
stand you in good stead for extensibility and longevity). 
(6) Never be tempted to put domain logic into View Models. 
(7) Never have any of the domain objects dependent on View Models. I.e. The 
direction of dependency is one way: The View Models depend on the Domain Layer.
[1] ViewModels
|   |
|   |   |   |   |   |
| ViewModelsDocs »More Advanced Topics ViewModels In most cases users can 
accomplish the business operations they need by invoking actions directly on 
domain entities.  |
|  |
| View on isis.apache.org | Preview by Yahoo |
|  |
|   |

 [2] Model Archetypes and the Domain Neutral Component
|   |
|   |  |   |   |   |   |   |
| Model Archetypes and the Domain Neutral ComponentPeter Coad's 'Modeling in 
color' defines four class archetypes. A model archetype is a typical structure 
of collobaorating classes that guides the rapid constructio... |
|  |
| View on www.step-10.com | Preview by Yahoo |
|  |
|   |

 

   

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[David Tildesley]

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: AnemicDomainModelIf you use an object-oriented domain model, and you 
don't put behavior in your objects, you're missing out on most of the benefits 
of that pattern. |
|  |
| View on www.martinfowler.com | Preview by Yahoo |
|  |
|   |

  
Regards,David.

 On Friday, 2 January 2015 12:40 AM, GESCONSULTOR - Óscar Bou 
o@gesconsultor.com wrote:
   

 Hi folks!!
Happy New Year to all those following the Gregorian Calendar !!!

As David mentions, we can think about ViewModels to be like views.
In that case, as Jeroen has commented, those views can be useful both at the 
Domain layer and the Application layer. So we cannot assume that View Models 
are going to be useful only for the Application layer, but also for the Domain 
layer.And not only they are views from this system's domain objects. As he 
points out, Views can also be used to represent external systems entities.
As Isis managed Properties/Collections can belong to any class of this Bounded 
Context / Domain or External Systems Domains objects (being a DomainEntity, a 
ViewModel used on the Domain Layer, a ViewModel used on the ApplicationLayer, a 
ViewModel representing entities managed by External Systems) they shouldn't be 
prefixed with a layer-specific term, IMHO.

Oscar





El 31/12/2014, a las 23:40, Branham, Jeremy [HR] jeremy.d.bran...@sprint.com 
escribió:

At least it wasn’t DOA =]

That helps me understand the evolution of Isis better, and It makes sense the 
PD would never depend on the UI.

So having separate annotations [@ViewModel and  @DomainEntity] would help 
maintain the distinction between UI and PD.
Where a single annotation [@DomainObject, @Model, or whatever else] would blur 
the lines of responsibility.
Do I understand this correctly?

Jeremy D. Branham
Tel: **DOTNET


-Original Message-
From: David Tildesley [mailto:davo...@yahoo.co.nz]
Sent: Wednesday, December 31, 2014 4:36 PM
To: dev@isis.apache.org; us...@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...

Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled 
with IoC in my brain).

    On Thursday, 1 January 2015 11:04 AM, David Tildesley davo...@yahoo.co.nz 
wrote:


Hi Jeremy,
The intention of ViewModel is provide a Use Case specific mechanism to 
aggregate/present/cut and dice a view of the problem domain. In this respect 
it is certainly not part of the domain layer and logically belongs the UI 
layer. It was invented as part of ISIS as the mechanism for significantly 
influencing the UI. In this way, it is a departure from the original concept of 
Naked Objects from which ISIS evolved, however if you choose not to use 
ViewModel then you are left with the original concept of Naked Objects and 
therefore ISIS remains true to Naked Objects.
The domain layer has long term enduring value to the business who paid for the 
application to be built and should never depend on other layers. The UI layer 
should be thought of as disposable and will mutate at a high rate, whilst the 
domain layer should remain stable in shape and independent of the other 
layers. There is nothing inherent about ISIS that would give you a valid reason 
to ignore this architecture pattern. If we ignore the data management layer 
which is no longer

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[David Tildesley]

Hi Dan,
Perhaps a prefix that is layer agnostic for those annotations?
Regards,David.   

 On Wednesday, 31 December 2014 7:42 PM, Dan Haywood 
d...@haywood-associates.co.uk wrote:
   

 On 30 December 2014 at 23:44, David Tildesley davo...@yahoo.co.nz wrote:

 +1 for the counter proposal (although I would suggest cloning/deriving
 @DomainObjectLayout to @ViewModelLayout etc. so that Domain* tags are
 not used in ViewModel - less confusing).



On a different thread to dev@ I also made a related proposal that
@Property, @Collection, @Action etc be renamed to @DomainProperty,
@DomainCollection, @DomainAction etc... the primary reason being that
clashes with @Collection clashes with java.util.Collection, plus I like the
idea of all Isis-related annotations starting with an @DomainXxx prefix.

No one's commented on that, yet.

Given your preference of @ViewModel and reserving @Domain to be strictly
for domain layer concepts, would I be right to guess you wouldn't be in
favour of adding Domain as a prefix to all those annotations?






      On Tuesday, 30 December 2014 3:07 AM, Dan Haywood 
 d...@haywood-associates.co.uk wrote:


  On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:

  Ok.
 
  So let's raise some questions/doubts :)
 
  *** @DomainObject  ***
 
  Is a ViewModel a DomainObject at all ?
 
 
 it's a good question, and I've debated it myself.  Let me lay out my
 thinking on this so far and see if we can collectively come to a view on
 this.

 First thing to note is that there are two varieties of view models (even
 though the implementation is identical)

 - those that are part of the domain layer and are, conceptually at least,
 entities, but where the persistence is managed outside of Isis.  An example
 is a document in a CMS
 - those that are part of the application layer, and represent a view on top
 of one or more entities.

 Of course, we expect an application layer to depend on the domain layer and
 not vice versa, but even so, because some view models are conceptually
 entities I suspect that in a typical Isis application it will be reasonable
 to allow JDO-managed domain entities to interact with externally-managed
 view model entities.


 Because of this, I've been thinking of DomainObject as being a superset
 of both entities and view models.




  I would consider them as a different kind, so the @ViewModel annotation
  shouldn't be deleted.
 

 You are certainly right that quite a few of the features in @DomainObject
 don't apply to view models (even if conceptually they are entities)...
 because we rely on JDO to implement.  Specifically:

 - auditing... requires JDO so doesn't apply to view models
 - publishing ... requires JDO so doesn't apply to view models
 - bounded = not sure... even though doesn't depend on JDO, suspect that it
 isn't supported for view models

 - autoComplete ... is supported for view models
 - editing ... is supported so long as the ViewModel.Cloneable interface is
 also implemented.  I can foresee this restriction being lifted in the
 future
 - objectType ... is supported for view models (used as REST URLs)





  Also, perhaps we can introduce Isis platform logic like not
  saving/persisting view models, etc. If that would be the case, the
  editing and editingDisabledReason at least might not have any sense.
 
 
 Not sure I understand this point.  But at any rate, given that some view
 models are basically externally-managed entities, the semantics of
 saving/persisting would also apply.





 
  If so, I would better align with DDD naming conventions, in order to gain
  acceptance.
 
  So, names should be @Entity or @DomainEntity (for avoiding name collision
  with JPA) - instead of @DomainObject -.
 
 
 I did consider @DomainEntity, but as I say, sometimes view models act like
 entities.  I do quite like it though.

 I have a counter-proposal, see below.



  I like the @DomainService name, as it can act as a DDD Factory and/or
  Repository.
 
 
  As currently there's no special support for AggregateRoots or
  ValueObjects, no more annotations are needed.
 
 
 Sounds like a vote to deprecate.  Jeroen has said the same thing.  Perhaps
 they should be deleted in v2.0 and reappear, if we want them back, in v3.0.



  So the proposed set would be:
  • @ViewModel and @ViewModelLayout
  • @DomainService and @DomainServiceLayout
  • @DomainEntity and @DomainEntityLayout
  • @Property and @PropertyLayout
  • @Collection and @CollectionLayout
  • @Action and @ActionLayout
  • @Parameter and @ParameterLayout
 
 
 
 Here's my counter-proposal.  It's not as symmetrical as before, but perhaps
 is less confusing overall:

 * replace @DomainObject(viewModel=false)  with
 @DomainEntity(persistence=JDO)
  ... this would be the default
 * replace @DomainObject(viewModel=true)    with
 @DomainEntity(persistence=EXTERNAL)
  ... for view models representing externally-persisted entities.  In the
 Javadoc, say that auditing

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[David Tildesley]

I can't help but think DomainObject is a far better representation of the 
(Business) Problem Domain concept than DomainEntity.
DDD for some reason known only to Eric Evans made a fetish of the term Domain 
Entity as a type of Domain Object.  It was defined in juxtaposition to a 
contrived Value Object type Domain Object. Sure some domain objects are light 
on Identity but that doesn't imply such domain objects always lack 
significant behaviour or attributes (I'm thinking of Coad's  Description 
archetypes here).   
Entity has unfortunate connotations - anemic domain model antipattern, EJB 
12, ...

So what is wrong with just plain old Domain Object?
 
 

 On Wednesday, 31 December 2014 10:05 PM, David Tildesley 
davo...@yahoo.co.nz wrote:
   

 Hi Dan,
Perhaps a prefix that is layer agnostic for those annotations?
Regards,David.   

 On Wednesday, 31 December 2014 7:42 PM, Dan Haywood 
d...@haywood-associates.co.uk wrote:
   

 On 30 December 2014 at 23:44, David Tildesley davo...@yahoo.co.nz wrote:

 +1 for the counter proposal (although I would suggest cloning/deriving
 @DomainObjectLayout to @ViewModelLayout etc. so that Domain* tags are
 not used in ViewModel - less confusing).



On a different thread to dev@ I also made a related proposal that
@Property, @Collection, @Action etc be renamed to @DomainProperty,
@DomainCollection, @DomainAction etc... the primary reason being that
clashes with @Collection clashes with java.util.Collection, plus I like the
idea of all Isis-related annotations starting with an @DomainXxx prefix.

No one's commented on that, yet.

Given your preference of @ViewModel and reserving @Domain to be strictly
for domain layer concepts, would I be right to guess you wouldn't be in
favour of adding Domain as a prefix to all those annotations?






      On Tuesday, 30 December 2014 3:07 AM, Dan Haywood 
 d...@haywood-associates.co.uk wrote:


  On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:

  Ok.
 
  So let's raise some questions/doubts :)
 
  *** @DomainObject  ***
 
  Is a ViewModel a DomainObject at all ?
 
 
 it's a good question, and I've debated it myself.  Let me lay out my
 thinking on this so far and see if we can collectively come to a view on
 this.

 First thing to note is that there are two varieties of view models (even
 though the implementation is identical)

 - those that are part of the domain layer and are, conceptually at least,
 entities, but where the persistence is managed outside of Isis.  An example
 is a document in a CMS
 - those that are part of the application layer, and represent a view on top
 of one or more entities.

 Of course, we expect an application layer to depend on the domain layer and
 not vice versa, but even so, because some view models are conceptually
 entities I suspect that in a typical Isis application it will be reasonable
 to allow JDO-managed domain entities to interact with externally-managed
 view model entities.


 Because of this, I've been thinking of DomainObject as being a superset
 of both entities and view models.




  I would consider them as a different kind, so the @ViewModel annotation
  shouldn't be deleted.
 

 You are certainly right that quite a few of the features in @DomainObject
 don't apply to view models (even if conceptually they are entities)...
 because we rely on JDO to implement.  Specifically:

 - auditing... requires JDO so doesn't apply to view models
 - publishing ... requires JDO so doesn't apply to view models
 - bounded = not sure... even though doesn't depend on JDO, suspect that it
 isn't supported for view models

 - autoComplete ... is supported for view models
 - editing ... is supported so long as the ViewModel.Cloneable interface is
 also implemented.  I can foresee this restriction being lifted in the
 future
 - objectType ... is supported for view models (used as REST URLs)





  Also, perhaps we can introduce Isis platform logic like not
  saving/persisting view models, etc. If that would be the case, the
  editing and editingDisabledReason at least might not have any sense.
 
 
 Not sure I understand this point.  But at any rate, given that some view
 models are basically externally-managed entities, the semantics of
 saving/persisting would also apply.





 
  If so, I would better align with DDD naming conventions, in order to gain
  acceptance.
 
  So, names should be @Entity or @DomainEntity (for avoiding name collision
  with JPA) - instead of @DomainObject -.
 
 
 I did consider @DomainEntity, but as I say, sometimes view models act like
 entities.  I do quite like it though.

 I have a counter-proposal, see below.



  I like the @DomainService name, as it can act as a DDD Factory and/or
  Repository.
 
 
  As currently there's no special support for AggregateRoots or
  ValueObjects, no more annotations are needed.
 
 
 Sounds like a vote to deprecate.  Jeroen has said the same thing.  Perhaps
 they should be deleted in v2.0

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[David Tildesley]

@DomainEntityLayout
@ViewModelLayout



Regarding adding the Domain preffix to properties and collections, I think 
it's not needed.

As Dan's exposed, they are present on any type of class (despite being a 
domain or application level one).
As they're annotations an not classes, in my current setup (based on Apache 
Isis latest snapshot):
- @Property does not conflict with any other annotation (i.e., no identically 
named annotation is present on any dependency).
- @Collection does not conflict with any other annotation.
- @Action clashes with the javax.xml.ws.Action annotation.
- @Parameter clashes with the org.junit.runners.parammetrized.Parameter 
annotation.

None of them can be confused with Isis ones by a junior developer.

In fact, this clash conflict was already present with @Named (that it's going 
to be kept) and same other Apache Isis annotations without being more relevant.

So my opinion would be to not add the Domain prefix to them.


Perhaps this could also be a good moment to add a collateral debate :)

In my head, I also associate Collections with Properties. I would consider 
Simple Properties and Collection Properties.
So perhaps naming could be instead SimpleProperty and CollectionProperty ? 
:-))



HTH,

Oscar






El 31/12/2014, a las 12:39, Vladimir Nišević 
vnise...@gmail.commailto:vnise...@gmail.com escribió:


I would vote for most well described DDD terms (described in Evans book) - this 
would help users to adopt/understand ISIS framework easier and have a kind of 
reference documentation. Term 'Object' is too general, and Business Object 
modelling antipatterns are also very wide spreaded, e.g. by people like 
enterpise information modelling architects...

Regs, Vladimir



Am 31.12.2014 um 07:40 schrieb Dan Haywood 
d...@haywood-associates.co.ukmailto:d...@haywood-associates.co.uk:


On 30 December 2014 at 23:44, David Tildesley 
davo...@yahoo.co.nzmailto:davo...@yahoo.co.nz wrote:

+1 for the counter proposal (although I would suggest cloning/deriving
@DomainObjectLayout to @ViewModelLayout etc. so that Domain* tags are
not used in ViewModel - less confusing).

On a different thread to dev@ I also made a related proposal that
@Property, @Collection, @Action etc be renamed to @DomainProperty,
@DomainCollection, @DomainAction etc... the primary reason being that
clashes with @Collection clashes with java.util.Collection, plus I like the
idea of all Isis-related annotations starting with an @DomainXxx prefix.

No one's commented on that, yet.

Given your preference of @ViewModel and reserving @Domain to be strictly
for domain layer concepts, would I be right to guess you wouldn't be in
favour of adding Domain as a prefix to all those annotations?







  On Tuesday, 30 December 2014 3:07 AM, Dan Haywood 
d...@haywood-associates.co.ukmailto:d...@haywood-associates.co.uk wrote:


On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou 
o@gesconsultor.commailto:o@gesconsultor.com wrote:


Ok.

So let's raise some questions/doubts :)

*** @DomainObject  ***

Is a ViewModel a DomainObject at all ?
it's a good question, and I've debated it myself.  Let me lay out my
thinking on this so far and see if we can collectively come to a view on
this.

First thing to note is that there are two varieties of view models (even
though the implementation is identical)

- those that are part of the domain layer and are, conceptually at least,
entities, but where the persistence is managed outside of Isis.  An example
is a document in a CMS
- those that are part of the application layer, and represent a view on top
of one or more entities.

Of course, we expect an application layer to depend on the domain layer and
not vice versa, but even so, because some view models are conceptually
entities I suspect that in a typical Isis application it will be reasonable
to allow JDO-managed domain entities to interact with externally-managed
view model entities.


Because of this, I've been thinking of DomainObject as being a superset
of both entities and view models.





I would consider them as a different kind, so the @ViewModel annotation
shouldn't be deleted.

You are certainly right that quite a few of the features in @DomainObject
don't apply to view models (even if conceptually they are entities)...
because we rely on JDO to implement.  Specifically:

- auditing... requires JDO so doesn't apply to view models
- publishing ... requires JDO so doesn't apply to view models
- bounded = not sure... even though doesn't depend on JDO, suspect that it
isn't supported for view models

- autoComplete ... is supported for view models
- editing ... is supported so long as the ViewModel.Cloneable interface is
also implemented.  I can foresee this restriction being lifted in the
future
- objectType ... is supported for view models (used as REST URLs)






Also, perhaps we can introduce Isis platform logic like not
saving/persisting view models, etc. If that would be the case, the
editing

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[David Tildesley]

Hi Vladimir
That's just the point I was making - using the term Entity to cover both 
DDD.Entity archetype and DDD.ValueObject archetype is in fact a violation of 
the DDD metamodel standard. Read page 89 of Eric's book.
I would have the same objection if ISIS chose to use Coad's colour modelling 
metamodel terminology as a reference for naming instead of Erics DDD metamodel 
terminology and then went ahead to call every domain object a Moment-Interval 
when clearly they could be Moment-Interval OR Party-Place-Thing OR Role 
OR Description. 
Domain Object is the correct level of abstraction and provides the least 
ambiguity. Use of DomainEntity, and at the same time referencing DDD 
metamodel, is clearly trying to use a DDD specialisation to stand in place of 
the DDD generalisation. IMHO, just wrong.
If you chose not to reference DDD but chose to reference the english dictionary 
meaning of Entity then I would  have to change my argument to pointing out that 
we are doing OO design and programming and the scholars that started that 
concept chose to use the term Object and not Entity.
Regards,David.   

 On Thursday, 1 January 2015 12:40 AM, Vladimir Nišević 
vnise...@gmail.com wrote:
   

 I would vote for most well described DDD terms (described in Evans book) - 
this would help users to adopt/understand ISIS framework easier and have a kind 
of reference documentation. Term 'Object' is too general, and Business Object 
modelling antipatterns are also very wide spreaded, e.g. by people like 
enterpise information modelling architects...

Regs, Vladimir


 Am 31.12.2014 um 07:40 schrieb Dan Haywood d...@haywood-associates.co.uk:
 
 On 30 December 2014 at 23:44, David Tildesley davo...@yahoo.co.nz wrote:
 
 +1 for the counter proposal (although I would suggest cloning/deriving
 @DomainObjectLayout to @ViewModelLayout etc. so that Domain* tags are
 not used in ViewModel - less confusing).
 
 On a different thread to dev@ I also made a related proposal that
 @Property, @Collection, @Action etc be renamed to @DomainProperty,
 @DomainCollection, @DomainAction etc... the primary reason being that
 clashes with @Collection clashes with java.util.Collection, plus I like the
 idea of all Isis-related annotations starting with an @DomainXxx prefix.
 
 No one's commented on that, yet.
 
 Given your preference of @ViewModel and reserving @Domain to be strictly
 for domain layer concepts, would I be right to guess you wouldn't be in
 favour of adding Domain as a prefix to all those annotations?
 
 
 
 
 
 
    On Tuesday, 30 December 2014 3:07 AM, Dan Haywood 
 d...@haywood-associates.co.uk wrote:
 
 
 On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:
 
 Ok.
 
 So let's raise some questions/doubts :)
 
 *** @DomainObject  ***
 
 Is a ViewModel a DomainObject at all ?
 it's a good question, and I've debated it myself.  Let me lay out my
 thinking on this so far and see if we can collectively come to a view on
 this.
 
 First thing to note is that there are two varieties of view models (even
 though the implementation is identical)
 
 - those that are part of the domain layer and are, conceptually at least,
 entities, but where the persistence is managed outside of Isis.  An example
 is a document in a CMS
 - those that are part of the application layer, and represent a view on top
 of one or more entities.
 
 Of course, we expect an application layer to depend on the domain layer and
 not vice versa, but even so, because some view models are conceptually
 entities I suspect that in a typical Isis application it will be reasonable
 to allow JDO-managed domain entities to interact with externally-managed
 view model entities.
 
 
 Because of this, I've been thinking of DomainObject as being a superset
 of both entities and view models.
 
 
 
 
 I would consider them as a different kind, so the @ViewModel annotation
 shouldn't be deleted.
 
 You are certainly right that quite a few of the features in @DomainObject
 don't apply to view models (even if conceptually they are entities)...
 because we rely on JDO to implement.  Specifically:
 
 - auditing... requires JDO so doesn't apply to view models
 - publishing ... requires JDO so doesn't apply to view models
 - bounded = not sure... even though doesn't depend on JDO, suspect that it
 isn't supported for view models
 
 - autoComplete ... is supported for view models
 - editing ... is supported so long as the ViewModel.Cloneable interface is
 also implemented.  I can foresee this restriction being lifted in the
 future
 - objectType ... is supported for view models (used as REST URLs)
 
 
 
 
 
 Also, perhaps we can introduce Isis platform logic like not
 saving/persisting view models, etc. If that would be the case, the
 editing and editingDisabledReason at least might not have any sense.
 Not sure I understand this point.  But at any rate, given that some view
 models are basically externally-managed entities, the semantics

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[David Tildesley]

Hi Jeremy,
That's correct.
Regards,David. 

 On Thursday, 1 January 2015 11:48 AM, Branham, Jeremy [HR] 
jeremy.d.bran...@sprint.com wrote:
   

 At least it wasn’t DOA =]

That helps me understand the evolution of Isis better, and It makes sense the 
PD would never depend on the UI.

So having separate annotations [@ViewModel and  @DomainEntity] would help 
maintain the distinction between UI and PD.
Where a single annotation [@DomainObject, @Model, or whatever else] would blur 
the lines of responsibility.
Do I understand this correctly?

Jeremy D. Branham
Tel: **DOTNET


-Original Message-
From: David Tildesley [mailto:davo...@yahoo.co.nz]
Sent: Wednesday, December 31, 2014 4:36 PM
To: dev@isis.apache.org; us...@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...

Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled 
with IoC in my brain).

    On Thursday, 1 January 2015 11:04 AM, David Tildesley davo...@yahoo.co.nz 
wrote:


 Hi Jeremy,
The intention of ViewModel is provide a Use Case specific mechanism to 
aggregate/present/cut and dice a view of the problem domain. In this respect 
it is certainly not part of the domain layer and logically belongs the UI 
layer. It was invented as part of ISIS as the mechanism for significantly 
influencing the UI. In this way, it is a departure from the original concept of 
Naked Objects from which ISIS evolved, however if you choose not to use 
ViewModel then you are left with the original concept of Naked Objects and 
therefore ISIS remains true to Naked Objects.
The domain layer has long term enduring value to the business who paid for the 
application to be built and should never depend on other layers. The UI layer 
should be thought of as disposable and will mutate at a high rate, whilst the 
domain layer should remain stable in shape and independent of the other 
layers. There is nothing inherent about ISIS that would give you a valid reason 
to ignore this architecture pattern. If we ignore the data management layer 
which is no longer of significance due to persistence frameworks like 
DataNucleus, JPA, Hibernate, Toplink, etc., then there are only the  
traditional three layers in consideration for the developer (if they choose not 
to stick to the pure Naked Objects paradigm for user experience) and the below 
represents these with the direction of dependency shown by the arrows:
UI -- PD -- SI
Where:
UI = User Interface (system or human)*PD = Problem DomainSI = System 
Integration.
* UI layer Includes both the ViewModels and the generated UI(s).  Where things 
got messy for ISIS was when Domain Objects in the domain layer were required 
not to be locally persisted but instead required DOI based integration with an 
external system (integration). The ISIS Domain Objects were locked into local 
persistance and that was because that was where the initial focus was 
(necessary because you have to get this right as priority because this is the 
majority scenario). Then in this vacuum, folk started proposing to use 
ViewModel as Domain Objects that required DOI based external system 
integration because ViewModel was free from the local persistance lock-in. 
Other proposals were also on the table (e.g roll your own datanucleus 
persistance plugin) that came with their own headaches.
Option 1 then tidies this up and nothing is lost.
Speaking to Jereon's point - yes there are some trivial system integrations 
where it is valid to bypass the PD layer and have a direct integration from UI 
layer to SI layer (e.g fetch a controlled value list from some other system) 
although I would say that ISIS negates the need to do this anyway by lowering 
development cost.
A step in the right direction is to first sort out the semantics with Option 1 
and then later when folk feel comfortable, to have ISIS enforce the UI -- PD 
dependency direction (i.e. disallow PD -- UI).
Applications  should reinforce the layer separation via package naming 
convention. e.g.
com.mycompany.myapp.pd.*com.mycompany.myapp.ui.*
David.

    On Thursday, 1 January 2015 3:24 AM, Branham, Jeremy [HR] 
jeremy.d.bran...@sprint.com wrote:


 What would it look like with @Model?
Giving more specificity than ‘Object’ but opening the interpretation to 
Entities and ViewModels.

Or am I overlooking something? [I am new to Isis]

(fyi - there is a name clash with Model in Spring-MVC)


Jeremy D. Branham
Tel: **DOTNET

From: Jeroen van der Wal [mailto:jer...@stromboli.it]
Sent: Wednesday, December 31, 2014 7:37 AM
To: dev; users
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...

I like this discussion because it's defining where Apache Isis is right now. 
Personally I think Isis has grown far beyond the concepts of DDD so sticking to 
it's grammar would limit ourselves.

In the applications I'm developing things aren't black or white: we have view 
models that represent documents in a CMIS

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[David Tildesley]

+1 for the counter proposal (although I would suggest cloning/deriving 
@DomainObjectLayout to @ViewModelLayout etc. so that Domain* tags are not 
used in ViewModel - less confusing). 

 On Tuesday, 30 December 2014 3:07 AM, Dan Haywood 
d...@haywood-associates.co.uk wrote:
   

 On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou 
o@gesconsultor.com wrote:

 Ok.

 So let's raise some questions/doubts :)

 *** @DomainObject  ***

 Is a ViewModel a DomainObject at all ?


it's a good question, and I've debated it myself.  Let me lay out my
thinking on this so far and see if we can collectively come to a view on
this.

First thing to note is that there are two varieties of view models (even
though the implementation is identical)

- those that are part of the domain layer and are, conceptually at least,
entities, but where the persistence is managed outside of Isis.  An example
is a document in a CMS
- those that are part of the application layer, and represent a view on top
of one or more entities.

Of course, we expect an application layer to depend on the domain layer and
not vice versa, but even so, because some view models are conceptually
entities I suspect that in a typical Isis application it will be reasonable
to allow JDO-managed domain entities to interact with externally-managed
view model entities.


Because of this, I've been thinking of DomainObject as being a superset
of both entities and view models.




 I would consider them as a different kind, so the @ViewModel annotation
 shouldn't be deleted.


You are certainly right that quite a few of the features in @DomainObject
don't apply to view models (even if conceptually they are entities)...
because we rely on JDO to implement.  Specifically:

- auditing... requires JDO so doesn't apply to view models
- publishing ... requires JDO so doesn't apply to view models
- bounded = not sure... even though doesn't depend on JDO, suspect that it
isn't supported for view models

- autoComplete ... is supported for view models
- editing ... is supported so long as the ViewModel.Cloneable interface is
also implemented.  I can foresee this restriction being lifted in the future
- objectType ... is supported for view models (used as REST URLs)





 Also, perhaps we can introduce Isis platform logic like not
 saving/persisting view models, etc. If that would be the case, the
 editing and editingDisabledReason at least might not have any sense.


Not sure I understand this point.  But at any rate, given that some view
models are basically externally-managed entities, the semantics of
saving/persisting would also apply.






 If so, I would better align with DDD naming conventions, in order to gain
 acceptance.

 So, names should be @Entity or @DomainEntity (for avoiding name collision
 with JPA) - instead of @DomainObject -.


I did consider @DomainEntity, but as I say, sometimes view models act like
entities.  I do quite like it though.

I have a counter-proposal, see below.



 I like the @DomainService name, as it can act as a DDD Factory and/or
 Repository.


 As currently there's no special support for AggregateRoots or
 ValueObjects, no more annotations are needed.


Sounds like a vote to deprecate.  Jeroen has said the same thing.  Perhaps
they should be deleted in v2.0 and reappear, if we want them back, in v3.0.



 So the proposed set would be:
 • @ViewModel and @ViewModelLayout
 • @DomainService and @DomainServiceLayout
 • @DomainEntity and @DomainEntityLayout
 • @Property and @PropertyLayout
 • @Collection and @CollectionLayout
 • @Action and @ActionLayout
 • @Parameter and @ParameterLayout



Here's my counter-proposal.  It's not as symmetrical as before, but perhaps
is less confusing overall:

* replace @DomainObject(viewModel=false)  with
@DomainEntity(persistence=JDO)
  ... this would be the default
* replace @DomainObject(viewModel=true)    with
@DomainEntity(persistence=EXTERNAL)
  ... for view models representing externally-persisted entities.  In the
Javadoc, say that auditing, publishing and bounded are not supported for
these
* keep @ViewModel
 ... extend to include the non-entity stuff from @DomainObject that does
apply (basically, I think that's just objectType )
  ... the intention being that this is used for application-layer views.

keep @DomainObjectLayout, because everything in it applies equally to both
view models (either variety) and JDO entities.


I'll reply on your points on @Property and @Parameter separately.

Thx
Dan




   

Re: ISIS-970 ... (new annotations) please review if you get a chance...

[David Tildesley]

Hi Devs, 
I'm not a contributor but I think option 3 would be a mistake - it will 
contribute to poor separation of concerns through obfuscation. Option 1 is the 
best choice of the three presented.
Regards,David. 

 On Tuesday, 30 December 2014 4:13 AM, Dan Haywood 
d...@haywood-associates.co.uk wrote:
   

 OK, so it comes down to either:

option 1:
@DomainEntity(persistence=JDO|EXTERNAL)@ViewModel
with
@DomainEntityLayout@ViewModelLayout

where:* is symmetrical* some attributes of @DomainEntity don't apply if 
persistence=EXTERNAL* the two layouts are basically identical to each other

--- or ---
option 2:

@DomainEntity(persistence=JDO|EXTERNAL)@ViewModel
with
@DomainObjectLayout

where:* not symmetrical* some attributes of @DomainEntity don't apply if 
persistence=EXTERNAL

--- or ---
option 3:
@DomainObject(persistence=JDO|EXTERNAL|VIEW_MODEL)
with
@DomainObjectLayout

where:* is symmetrical* some attributes of @DomainEntity don't apply if 
persistence=EXTERNAL or VIEW_MODEL* concept of view model is less visible


Cast your votes, please!
Dan


On 29 December 2014 at 15:02, GESCONSULTOR - Óscar Bou o@gesconsultor.com 
wrote:





As currently there's no special support for AggregateRoots or
ValueObjects, no more annotations are needed.



Sounds like a vote to deprecate.  Jeroen has said the same thing.  Perhaps
they should be deleted in v2.0 and reappear, if we want them back, in v3.0.


I agree with Jeroen.
Currently there's nothing specific about Aggregate Roots on Apache Isis, at 
least on the most used modules, AFAK.



* replace @DomainObject(viewModel=false)   with
@DomainEntity(persistence=JDO)
  ... this would be the default


I like it :)


* replace @DomainObject(viewModel=true)    with
@DomainEntity(persistence=EXTERNAL)


This one also!

  ... for view models representing externally-persisted entities.  In the
Javadoc, say that auditing, publishing and bounded are not supported for
these
* keep @ViewModel
... extend to include the non-entity stuff from @DomainObject that does
apply (basically, I think that's just objectType )
 ... the intention being that this is used for application-layer views.


I agree. It should be kept for those use cases.



keep @DomainObjectLayout, because everything in it applies equally to both
view models (either variety) and JDO entities.



M I would prefer to keep symmetry... I know it introduces some 
redundant checks on implementation but, from the user's perspective, is a 
clearer model ...



I'll reply on your points on @Property and @Parameter separately.

Thx
Dan








Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 2, ITIL-F

   902 900 231 / 620 267 520
   http://www.twitter.com/oscarbou
   http://es.linkedin.com/in/oscarbou
   http://www.GesConsultor.com 



Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen 
información reservada que no puede ser difundida. Si usted ha recibido este 
correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al 
remitente mediante reenvío a su dirección electrónica; no deberá copiar el 
mensaje ni divulgar su contenido a ninguna persona.Su dirección de correo 
electrónico junto a sus datos personales constan en un fichero titularidad de 
Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si 
quiere saber de qué información disponemos de Ud., modificarla, y en su caso, 
cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una 
fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , 
Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas 
num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que 
este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso 
que los tuvieran eliminarlos.








   

[jira] [Commented] (ISIS-800) Wizard-like form for Wicket viewer

[David Tildesley (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14021768#comment-14021768
 ] 

David Tildesley commented on ISIS-800:
--

Just thought I would remind of this of 781

 Wizard-like form for Wicket viewer
 --

 Key: ISIS-800
 URL: https://issues.apache.org/jira/browse/ISIS-800
 Project: Isis
  Issue Type: New Feature
  Components: Core, Viewer: Wicket
Affects Versions: viewer-wicket-1.5.0, core-1.5.0
Reporter: Dan Haywood
Assignee: Dan Haywood
Priority: Minor
 Fix For: viewer-wicket-1.6.0, core-1.6.0


 Erik Hair on users@i.a.o:
 Is it in some way possible to create a wizard like form or open an action 
 with an action? I tried to return a not yet persisted object from an action 
 and hoped I could edit some properties and add some elements to collections 
 of the object before persisting it to the database...
 ~~
 Dan:
 Short answer is that we don't really (properly) support this.  And we should.
 I agree that @NotPersistable is confusing and its not clear what to use; the 
 right solution would be to implement a view model (currently: implement the 
 ViewModel interface), and then - optionally - write a custom ComponentFactory 
 for the Wicket viewer to render the wizard appropriately.
 But the snag even with the above is that (currently) view models are 
 immutable; they support actions but their properties cannot be edited.
 I can see the way forward on this; I don't think it's difficult, but it will 
 require a change in core and probably the wicket viewer also.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [ANN] Apache Isis version 1.5.0 and related components Released

[David Tildesley]

Well done on 1.5 release. Hope the conference goes well. 
David.


On Sunday, 8 June 2014 6:40 AM, GESCONSULTOR o@gesconsultor.com wrote:
 



Really nice way to celebrate the success of the first IsisCon !!!

This development platform has a great potential for the years to come.

It's been fantastic to share experiences and the roadmap promises a brilliant 
future.

To all mail list readers, we count with you for the next IsisCon !!!

Cheers!


 El 07/06/2014, a las 20:14, Dan Haywood d...@haywood-associates.co.uk 
 escribió:
 
 The Isis team is pleased to announce the release of:
 - Apache Isis Core version 1.5.0
 - Wicket Viewer 1.5.0
 - Restful Objects Viewer 2.3.0
 - JDO Object Store 1.5.0
 - Shiro Security 1.5.0
 - Simple Archetype 1.5.0
 - Quickstart Archetype 1.5.0
 
 New features and improvements in this release include:
 - Additional EventBus service events, ability to programmatically trigger
 events, vetoing subscribers (ISIS-550, ISIS-786)
 - Integration testing improvements, most notably the new FixtureScript API
 and auto-injection of services into integration tests (ISIS-776, ISIS-782,
 ISIS-783)
 - Better handling of multiple realms in Shiro security (ISIS-746)
 - Better default column sizes for applib services (command, auditing,
 pubsub) (ISIS-744, ISIS-750)
 - Precommit phase to flush pending updates for applib services (ISIS-769)
 - Preparatory work for move to Java 7 (ISIS-569, ISIS-770, ISIS-772)
 - Improved support for JRebel in Maven and various IDEs (ISIS-756)
 
 Notable bug fixes include:
 - Fixed blob/clob mapping in JDO Objectstore (ISIS-714)
 - Fixed handling of mandatory boolean parameters in Wicket viewer (ISIS-431)
 - RO not threadsafe when buiding metamodel (ISIS-777)
 
 Full release notes are available at [1,2,3,4,5,6,7] on the Isis website.
 
 You can access this release directly from the Maven central repo [8],
 or download the release and build it from source [9].
 
 Enjoy!
 
 -The Isis team
 
 [1] http://isis.apache.org/core/release-notes/isis-1.5.0.html
 [2]
 http://isis.apache.org/components/viewers/wicket/release-notes/isis-viewer-wicket-1.5.0.html
 [3]
 http://isis.apache.org/components/viewers/restfulobjects/release-notes/isis-viewer-restfulobjects-2.3.0.html
 [4]
 http://isis.apache.org/components/objectstores/jdo/release-notes/isis-objectstore-jdo-1.5.0.html
 [5]
 http://isis.apache.org/components/security/shiro/release-notes/isis-security-shiro-1.5.0.html
 [6]
 http://isis.apache.org/getting-started/release-notes/quickstart_wrj-archetype-1.5.0.html
 [7]
 http://isis.apache.org/getting-started/release-notes/simple_wrj-archetype-1.5.0.html
 [8] http://search.maven.org
 [9] http://isis.apache.org/download.html

[jira] [Created] (ISIS-781) Add edit capability to view objects

[David Tildesley (JIRA)]

David Tildesley created ISIS-781:


 Summary: Add edit capability to view objects
 Key: ISIS-781
 URL: https://issues.apache.org/jira/browse/ISIS-781
 Project: Isis
  Issue Type: Improvement
  Components: Core
Affects Versions: core-1.4.0
Reporter: David Tildesley
Assignee: Dan Haywood
 Fix For: core-1.4.2


View object should have the same capability as domain object in the viewer. 
Currently it does not support edit. Without this capability, actions must be 
employed and state management becomes more of an issue on the server side.
The view object should support all of the viewer specific semantics that the 
domain objects support via the viewer generation. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Comments on GSOC2014 ReputationBox proposal

[David Tildesley]

Well done Dileepa. 


On Tuesday, 22 April 2014 5:14 PM, Dileepa Jayakody dileepajayak...@gmail.com 
wrote:
 
Hi All,

I'm pleased to inform you all that my gsoc proposal on ReputationBox has been 
accepted. I'm thankful to all of you, specially Dan, Oscar and David for the 
continuous support and feedback given about my project idea. I hope to do my 
best for my Gsoc project in Isis and hope you will continue your kind support 
throughout the project.

Thanks,
Dileepa

Re: Comments on GSOC2014 ReputationBox proposal

[David Tildesley]

Hi Oscar,Thanks - I want to have a go at using the BDD integration - good to know that someone is using it and is pleased with it. If we were all in a room doing consensus based domain modelling together we probably wouldn't need to do sequence diagrams - we would already be familiar with the behaviour on the model and we would have the significant behaviour on the model itself in terms of methods including signatures - in which case it's easy to visualise the call sequence. All so if using the Coad's DNC model archetype shape then there is an inherent call flow direction.Regards,David. On Wednesday, 9 April 2014 5:13 AM, GESCONSULTOR - Óscar Bou o@gesconsultor.com wrote:Hi, David.Nice addition.A complementary approach (or currently the alternative to us) to sequence diagrams would be to define different features and scenarios on BDD [1].From those BDD scenarios Dileepa can directly implement them thanks to the excellent Isis BDD support (it has greatly changed our dev process; we have a programmer here that says he currently talks Spanish, Catalan and a bit of English and Gherkin), or perhaps do a fine-grained analysis through sequence diagrams.HTH,Oscar[1]http://isis.apache.org/core/specsupport-and-integtestsupport.htmlEl 08/04/2014, a las 02:58, David Tildesley davo...@yahoo.co.nz escribió:I should add that I didn't show parameters and return types on the methods. The best thing to do next is to validate your domain model by sequence diagram for a key scenario (but following Demeters Law - "Only talk to your immediatefriends" so that the model remains
 loosely coupled).Regards,David.On Tuesday, 8 April 2014 8:55 AM, David Tildesley davo...@yahoo.co.nz wrote:Hi Dileepa,ContactedParty is useful when you have more than one user inbox for the same user and you want to consolidate Contacts across multiple inboxes. If there is always just one inbox (one account) or you don't need or want Contactconsolidation, then you don't need it and you shift the attributes down to the "...Inbox".Yes, CriteriaReputation is the most granular from what I picking up from your explanations and diagram - the other reputations are computed from multiple CriteriaReputation
 using some algorithm (maybe just a weighted average -whatever you decide).Regards,David.Óscar Bou BouResponsable de ProductoAuditor Jefe de Certificación ISO 27001 en BSICISA, CRISC, APMG ISO 2, ITIL-F902 900 231 / 620 267 520http://www.twitter.com/oscarbouhttp://es.linkedin.com/in/oscarbouhttp://www.GesConsultor.comEste mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.Su dirección de
 correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. ,Paseode laCastellana, 153 bajo - 28046 (Madrid), yAvda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.

  

Re: Comments on GSOC2014 ReputationBox proposal

[David Tildesley]

Hi Dileepa,

ContactedParty is useful when you have more than one user inbox for the same 
user and you want to consolidate Contacts across multiple inboxes. If there is 
always just one inbox (one account) or you don't need or want Contact 
consolidation, then you don't need it and you shift the attributes down to the 
...Inbox.

Yes, CriteriaReputation is the most granular from what I picking up from your 
explanations and diagram - the other reputations are computed from multiple 
CriteriaReputation using some algorithm (maybe just a weighted average - 
whatever you decide).


Regards,
David.

On Tuesday, 8 April 2014 8:05 AM, Dileepa Jayakody dileepajayak...@gmail.com 
wrote:
 
Hi David, Dan and All,

Thanks a lot for your help in shaping up the domain model. I think David's 
model covers most aspects of the domain I plan to cover. 

@David,
One entity I'm not clear about is ContactedParty. What is the reason that 
this is abstracted out from EmailContact?
Also I assume the CriteriaReputation class is as same as Reputation class in my 
diagram? 


Thanks again for all your help.

Regards,
Dileepa  



On Sun, Apr 6, 2014 at 3:03 PM, David Tildesley davo...@yahoo.co.nz wrote:

Hi Dan, Dileepa,

Yes - sorry should have read all the trails and also had a brain fade on the 
uml violation thing as well. 
Unfortunately this is proving really hard to do by email (as I suspected it 
would be). 

I've drawn a domain model based on what I think I understand and attached to 
the Jira (1) as an image.

[1] https://issues.apache.org/jira/browse/ISIS-736



On Saturday, 5 April 2014 9:24 PM, Dan Haywood d...@haywood-associates.co.uk 
wrote:

Hi David,
I think you've raised one or two points I did already (eg Entity as a
name), which Dileepa already addressed in the latest iteration; the most
recent is [1].  But I really appreciate you taking the time to help develop
Dileepa's model here; great points being raised.

Hi Dileepa,
Not sure if David or I mentioned it already, but the description,
thing, role and moment-interval archetypes are from the Coad
modelling in color approach [2,3] that David and I have both
(independently) used in the past, and which I've described in my previous
books.  Could be worthwhile adding these archetypes to the model, make it
more expressive.

Cheers
Dan

[1] http://yuml.me/17514278
[2] http://en.wikipedia.org/wiki/UML_colors
[3] http://www.step-10.com/SoftwareDesign/ModellingInColour/





On 4 April 2014 22:33, David Tildesley davo...@yahoo.co.nz wrote:

 Hi Dileepa,

 Whenever I see a 1:1 relationship between two object/classes I am thinking
 that they should be collapsed together unless there is some future reason
 you might want to keep them separate.  i.e. Reputation - Context.
 ReputationObject, ComputationalAlgorithm appears to have no meaning or
 place on the domain model except perhaps as concrete implementation via
 plugin point.
 Entity (as with object) as a name is just wrong - you should regard it as
 if it were a reserved word and come up with a proper domain specific name.
 Your compositions on Entity break the uml semantics - it would have to be
 an aggregation relationship to be shared.

 Maybe we can improve the model by you telling us what object is the
 highest business value in the domain.

 I'm thinking you have a moment-interval archetype called Reputation that
 is point in time and it has behaviour that is effectively
 calculateReputation. It may have some MI-details (as composition)  that
 participate in the calculation.

 I'm thinking Criteria is actually a description archetype which has a
 plugin point (strategy pattern) for the computation algorithm.

 UserInbox looks like a thing archetype and it looks like you have chosen
 to collapse the user (Party) onto that - which may be fine if all you want
 to know about the user is say an identifier and name so that you can locate
 the logged in principal's UserInbox.

 If it were an email client app domain then Email would be a
 moment-interval and EmailContact a party archetype. Maybe it is true in
 this domain as well.


 David.
 On Saturday, 5 April 2014 8:56 AM, Dileepa Jayakody 
 dileepajayak...@gmail.com wrote:

 Hi All,


 On Fri, Apr 4, 2014 at 11:11 PM, Dan Haywood
 d...@haywood-associates.co.ukwrote:

  I think I like Oscar's a bit more, also.
 
  Qn: Why is there a 1:1 relationship between Reputation and
 ReputationValue?
 
  ReputationValue entity encapsulates the result of the reputation analysis
 process.
 It can simply be a value type (a reputation score). And I think each
 Reputation object should have a corresponding reputation value, that's why
 I added it as a 1:1 relationship. Any ideas for a better model?


 
 
 
 
  On 4 April 2014 17:08, GESCONSULTOR - Óscar Bou o@gesconsultor.com
 wrote:
 
  Hi Dileepa.
 
  Not sure about this, but seems a little strange the cycle on your
  model between the Context, Criteria and Reputation entities.
 
  Perhaps the Context is a more generic entity

Re: Comments on GSOC2014 ReputationBox proposal

[David Tildesley]

I should add that I didn't show parameters and return types on the methods. The 
best thing to do next is to validate your domain model by sequence diagram for 
a key scenario (but following Demeters Law - Only talk to your immediate 
friends so that the model remains loosely coupled).


Regards,
David.


On Tuesday, 8 April 2014 8:55 AM, David Tildesley davo...@yahoo.co.nz wrote:
 
Hi Dileepa,

ContactedParty is useful when you have more than one user inbox for the same 
user and you want to consolidate Contacts across multiple inboxes. If there is 
always just one inbox (one account) or you don't need or want Contact 
consolidation, then you don't need it and you shift the attributes down to the 
...Inbox.

Yes, CriteriaReputation is the most granular from what I picking up from your 
explanations and diagram - the other reputations are computed from multiple 
CriteriaReputation using some algorithm (maybe just a weighted average - 
whatever you decide).


Regards,
David.

[jira] [Updated] (ISIS-736) For GSOC, - build a real-life app in some suitable domain, along with a semi-academic write-up of their learnings

[David Tildesley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ISIS-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Tildesley updated ISIS-736:
-

Attachment: ReputationBox Domain Model-DT.png

 For GSOC, - build a real-life app in some suitable domain, along with a 
 semi-academic write-up of their learnings
 ---

 Key: ISIS-736
 URL: https://issues.apache.org/jira/browse/ISIS-736
 Project: Isis
  Issue Type: Wish
Reporter: Dan Haywood
  Labels: gsoc, gsoc2014
 Attachments: EmailReputationSystem_v2.png, ReputationBox Domain 
 Model-DT.png


 - to would give us another substantial example app, along with some marketing 
 material about how learnable Isis



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Comments on GSOC2014 ReputationBox proposal

[David Tildesley]

Hi Dan, Dileepa,

Yes - sorry should have read all the trails and also had a brain fade on the 
uml violation thing as well. 
Unfortunately this is proving really hard to do by email (as I suspected it 
would be). 

I've drawn a domain model based on what I think I understand and attached to 
the Jira (1) as an image.

[1] https://issues.apache.org/jira/browse/ISIS-736


On Saturday, 5 April 2014 9:24 PM, Dan Haywood d...@haywood-associates.co.uk 
wrote:
 
Hi David,
I think you've raised one or two points I did already (eg Entity as a
name), which Dileepa already addressed in the latest iteration; the most
recent is [1].  But I really appreciate you taking the time to help develop
Dileepa's model here; great points being raised.

Hi Dileepa,
Not sure if David or I mentioned it already, but the description,
thing, role and moment-interval archetypes are from the Coad
modelling in color approach [2,3] that David and I have both
(independently) used in the past, and which I've described in my previous
books.  Could be worthwhile adding these archetypes to the model, make it
more expressive.

Cheers
Dan

[1] http://yuml.me/17514278
[2] http://en.wikipedia.org/wiki/UML_colors
[3] http://www.step-10.com/SoftwareDesign/ModellingInColour/





On 4 April 2014 22:33, David Tildesley davo...@yahoo.co.nz wrote:

 Hi Dileepa,

 Whenever I see a 1:1 relationship between two object/classes I am thinking
 that they should be collapsed together unless there is some future reason
 you might want to keep them separate.  i.e. Reputation - Context.
 ReputationObject, ComputationalAlgorithm appears to have no meaning or
 place on the domain model except perhaps as concrete implementation via
 plugin point.
 Entity (as with object) as a name is just wrong - you should regard it as
 if it were a reserved word and come up with a proper domain specific name.
 Your compositions on Entity break the uml semantics - it would have to be
 an aggregation relationship to be shared.

 Maybe we can improve the model by you telling us what object is the
 highest business value in the domain.

 I'm thinking you have a moment-interval archetype called Reputation that
 is point in time and it has behaviour that is effectively
 calculateReputation. It may have some MI-details (as composition)  that
 participate in the calculation.

 I'm thinking Criteria is actually a description archetype which has a
 plugin point (strategy pattern) for the computation algorithm.

 UserInbox looks like a thing archetype and it looks like you have chosen
 to collapse the user (Party) onto that - which may be fine if all you want
 to know about the user is say an identifier and name so that you can locate
 the logged in principal's UserInbox.

 If it were an email client app domain then Email would be a
 moment-interval and EmailContact a party archetype. Maybe it is true in
 this domain as well.


 David.
 On Saturday, 5 April 2014 8:56 AM, Dileepa Jayakody 
 dileepajayak...@gmail.com wrote:

 Hi All,


 On Fri, Apr 4, 2014 at 11:11 PM, Dan Haywood
 d...@haywood-associates.co.ukwrote:

  I think I like Oscar's a bit more, also.
 
  Qn: Why is there a 1:1 relationship between Reputation and
 ReputationValue?
 
  ReputationValue entity encapsulates the result of the reputation analysis
 process.
 It can simply be a value type (a reputation score). And I think each
 Reputation object should have a corresponding reputation value, that's why
 I added it as a 1:1 relationship. Any ideas for a better model?


 
 
 
 
  On 4 April 2014 17:08, GESCONSULTOR - Óscar Bou o@gesconsultor.com
 wrote:
 
  Hi Dileepa.
 
  Not sure about this, but seems a little strange the cycle on your
  model between the Context, Criteria and Reputation entities.
 
  Perhaps the Context is a more generic entity than Criteria, and it's the
  Criteria what should have a relationship with a Context, and also with
  Reputation?
 
  I agree with you on the cyclic model being bit strange. I also adjusted
 the association between ReputationValue and Criteria entitys as
 [ReputationValue]0..*-1[Criteria] so that now ReputationValue has a
 uni-direction association to the criteria used for the computation.

 See : http://yuml.me/17514278

 Something like this:
 
  http://yuml.me/3aa65a6f
 
  HTH,
 
  Oscar
 
 
 
  El 04/04/2014, a las 17:56, Dileepa Jayakody dileepajayak...@gmail.com
 
  escribió:
 
  Hi Oscar and all,
 
  On Thu, Apr 3, 2014 at 1:52 PM, GESCONSULTOR - Óscar Bou 
  o@gesconsultor.com wrote:
 
  Hi Deleepa,
 
  Seeing at your last diagram, shouldn't the Criteria be related with (is
  specific to) a Context? If so, a relationship would also be needed.
 
 
  Yes, I agree. The criteria to calculate reputation depends on the
  context. Therefore there should be a relationship
  [Context]1-1..*[Criteria].
  I have modified the diagram like this : http://yuml.me/26953ad7
 
 
  Perhaps the Computation Algorithm could also be specific for one or
 more
  Contexts. In that case

Re: Comments on GSOC2014 ReputationBox proposal

[David Tildesley]

Hi Dileepa,

Whenever I see a 1:1 relationship between two object/classes I am thinking that 
they should be collapsed together unless there is some future reason you might 
want to keep them separate.  i.e. Reputation - Context. 
ReputationObject, ComputationalAlgorithm appears to have no meaning or place on 
the domain model except perhaps as concrete implementation via plugin point. 
Entity (as with object) as a name is just wrong - you should regard it as if it 
were a reserved word and come up with a proper domain specific name. Your 
compositions on Entity break the uml semantics - it would have to be an 
aggregation relationship to be shared. 

Maybe we can improve the model by you telling us what object is the highest 
business value in the domain.

I'm thinking you have a moment-interval archetype called Reputation that is 
point in time and it has behaviour that is effectively calculateReputation. 
It may have some MI-details (as composition)  that participate in the 
calculation. 

I'm thinking Criteria is actually a description archetype which has a plugin 
point (strategy pattern) for the computation algorithm.

UserInbox looks like a thing archetype and it looks like you have chosen to 
collapse the user (Party) onto that - which may be fine if all you want to know 
about the user is say an identifier and name so that you can locate the logged 
in principal's UserInbox.

If it were an email client app domain then Email would be a moment-interval and 
EmailContact a party archetype. Maybe it is true in this domain as well.


David.
On Saturday, 5 April 2014 8:56 AM, Dileepa Jayakody dileepajayak...@gmail.com 
wrote:
 
Hi All,


On Fri, Apr 4, 2014 at 11:11 PM, Dan Haywood
d...@haywood-associates.co.ukwrote:

 I think I like Oscar's a bit more, also.

 Qn: Why is there a 1:1 relationship between Reputation and ReputationValue?

 ReputationValue entity encapsulates the result of the reputation analysis
process.
It can simply be a value type (a reputation score). And I think each
Reputation object should have a corresponding reputation value, that's why
I added it as a 1:1 relationship. Any ideas for a better model?






 On 4 April 2014 17:08, GESCONSULTOR - Óscar Bou o@gesconsultor.comwrote:

 Hi Dileepa.

 Not sure about this, but seems a little strange the cycle on your
 model between the Context, Criteria and Reputation entities.

 Perhaps the Context is a more generic entity than Criteria, and it's the
 Criteria what should have a relationship with a Context, and also with
 Reputation?

 I agree with you on the cyclic model being bit strange. I also adjusted
the association between ReputationValue and Criteria entitys as
[ReputationValue]0..*-1[Criteria] so that now ReputationValue has a
uni-direction association to the criteria used for the computation.

See : http://yuml.me/17514278

Something like this:

 http://yuml.me/3aa65a6f

 HTH,

 Oscar



 El 04/04/2014, a las 17:56, Dileepa Jayakody dileepajayak...@gmail.com
 escribió:

 Hi Oscar and all,

 On Thu, Apr 3, 2014 at 1:52 PM, GESCONSULTOR - Óscar Bou 
 o@gesconsultor.com wrote:

 Hi Deleepa,

 Seeing at your last diagram, shouldn't the Criteria be related with (is
 specific to) a Context? If so, a relationship would also be needed.


 Yes, I agree. The criteria to calculate reputation depends on the
 context. Therefore there should be a relationship
 [Context]1-1..*[Criteria].
 I have modified the diagram like this : http://yuml.me/26953ad7


 Perhaps the Computation Algorithm could also be specific for one or more
 Contexts. In that case, a relationship is also needed.


 I think, now that Context has a relationship with Criteria, the
 relationship between the ComputationAlgo and Context could be derived
 through the Criteria entity.


 Also, perhaps the relationship between Reputation and Criteria is
 redundant, as it can be obtained through the ReputationValue. It could be
 modeled as a derived relationship in Isis.

 Yes, Thanks for pointing out. Removed this relationship between
 Reputation and Criteria

 HTH,

 Oscar



 El 03/04/2014, a las 09:59, Dileepa Jayakody dileepajayak...@gmail.com
 escribió:


 Hi Dan and all,

 I modified the diagram and the latest is : http://yuml.me/75c87f26


 On Thu, Apr 3, 2014 at 12:50 PM, Dileepa Jayakody 
 dileepajayak...@gmail.com

 wrote:


 Thanks Dan,

 I will modify the diagram with proper notations and reply with
 explanations..


 On Thu, Apr 3, 2014 at 12:31 PM, Dan Haywood 
 d...@haywood-associates.co.uk

 wrote:


 On 2 April 2014 08:09, Dileepa Jayakody dileepajayak...@gmail.com
 wrote:

 Hi All,

 After doing some background reading on Reputation object modeling [1],



 (good to hear)


 I
 have extended my class diagram to describe the reputation analysis

 model in

 my application : http://yuml.me/c97453ec


 There are some discrepancies between this diagram and the description
 below...



 An entity



 Not sure if having an entity called entity is a particularly 

Re: Comments on GSOC2014 ReputationBox proposal

[David Tildesley]

On Wednesday, 26 March 2014 8:49 PM, Dileepa Jayakody 
dileepajayak...@gmail.com wrote:
 
 Hi Dan, David and all,

 Above class diagram only contains the domain entities. Perhaps David's
 question on the domain requirements could be clarified if domain service
 classes are also included in the diagram. Shall I do so?

No. Please don't do that. Stick to the domain object model (leave out any view 
objects also). Key attributes and methods will aid in understanding it.

So .. you are saying that the reputation analysis/scoring is not part of the 
domain for the application but is a separate component? In that case I am 
correct in saying it is an external service (whether it runs in the same 
processor space or accessed via a web-service is irrelevant - the fact is that 
it is not part of the domain of the ISIS based application).

I must say that this is an ambitious project with a lot of integration - what 
is the overall objective? Just to prove that ISIS is a rapid prototyping tool? 
In which case I would stub out all the integration points and have some fake 
random reputation scoring code sitting behind the service otherwise all your 
effort will go into writing the SI layer and the reputation analysis/scoring 
and ISIS does not help you one jot with that.

Regards,
David.

Re: Comments on GSOC2014 ReputationBox proposal

[David Tildesley]

Now we are getting somewhere. Why do you want the domain to supply the keywords 
to the reputation analysis component? Do you allow the end user to define these 
 keywords? If not then do they change all the time and you need an admin role 
to be constantly updating them? If not then why not load them as a static 
property file when Mahout starts? And if the keywords are allowed to change 
does that mean that all emails and contacts must be rescored?

If the score for a contact is based on a history of their email scores then 
what holds this history? (hopefully you are going to tell me that 
Mahout/Hadoop) does and therefore the domain does not care.

David.






On Thursday, 27 March 2014 12:24 AM, Dileepa Jayakody 
dileepajayak...@gmail.com wrote:
 
Hi David,

On Wed, Mar 26, 2014 at 4:03 PM, David Tildesley davo...@yahoo.co.nz wrote:

Hi Dileepa,

I see. Then the domain will perhaps have some object representing 
ReputationScore with a method such as calculateEmailReputationScore and 
calculateEmailContactReputationScore with the implementation of the methods 
based on Mahout and injected via a domain service. So it's the same deal no 
matter how you want to reword it - the complexity of the score calculation is 
not in the ISIS domain but in the Mahout implementation.


Yes, the domain service (ReputationAnalysisService) will call out a Mahout 
recommender process  to give the reputation score of the new email.

So what information do you need to feed these two methods in order to do the 
calculation?


I'm planning to feed  people (to, cc, from), topic and actions (keywords such 
as meeting, project, important etc) mentioned in the email to perform 
reputation calculation.
 
David.




On Wednesday, 26 March 2014 11:09 PM, Dileepa Jayakody 
dileepajayak...@gmail.com wrote:

Hi David,

On Wed, Mar 26, 2014 at 3:22 PM, David Tildesley davo...@yahoo.co.nzwrote:


 Hi David,

 On Wednesday, 26 March 2014 8:49 PM, Dileepa Jayakody 
 dileepajayak...@gmail.com wrote:

  Hi Dan, David and all,

  Above class diagram only contains the domain entities. Perhaps David's
  question on the domain requirements could be clarified if domain service
  classes are also included in the diagram. Shall I do so?

 No. Please don't do that. Stick to the domain object model (leave out any
 view objects also). Key attributes and methods will aid in understanding it.

 So .. you are saying that the reputation analysis/scoring is not part of
 the domain for the application but is a separate component? In that case I
 am correct in saying it is an external service (whether it runs in the same
 processor space or accessed via a web-service is irrelevant - the fact is
 that it is not part of the domain of the ISIS based application).


Perhaps I haven't yet understood the Isis programming model as much as I
should have. But as I see, RB server component is also within the Isis
application domain. Implementing the RB application in Isis requires
implementing both RB client webapp and RB server components.

I have stated  reputation scoring is not done by some other system, it's
done in the reputation-box server component of my application. and by that
I wanted to convey that I see implementing the ReputationAnalysisService is
within the domain of the Isis based application. I will integrate a Mahout
recommendation process in the above domain service to generate the
reputation-scores but still it will be within the Isis domain AFAIU. Please
correct me if I'm wrong.


 I must say that this is an ambitious project with a lot of integration -
 what is the overall objective? Just to prove that ISIS is a rapid
 prototyping tool? In which case I would stub out all the integration
 points and have some fake random reputation scoring code sitting behind the
 service otherwise all your effort will go into writing the SI layer and the
 reputation analysis/scoring and ISIS does not help you one jot with that.


The objective is to develop a real world application in the email domain
using Isis as a framework to rapidly develop domain driven applications. I
will utilize Isis features to develop my domain model and generate other
layers such as persistence, presentation etc. And as a sub-task of the
project Oauth2 client support will also be implemented (for authorizing RB
app to connect to user mailboxes). Further I intend to write an academic
paper on my project and explain how it was developed using Isis features.





 Regards,
 David.

Re: Comments on GSOC2014 ReputationBox proposal

[David Tildesley]

Hi Dileepa,

Regardless of the implementation of the service, you should be able to 
determine the service contract which would allow you to model the domain. At 
the end of the day, the biggest influencer on domain shape is behaviour. 

Regards,
David.


On Thursday, 27 March 2014 9:15 AM, Dileepa Jayakody 
dileepajayak...@gmail.com wrote:
 
Hi David,

On Thu, Mar 27, 2014 at 1:13 AM, David Tildesley davo...@yahoo.co.nzwrote:

 Now we are getting somewhere. Why do you want the domain to supply the
 keywords to the reputation analysis component? Do you allow the end user to
 define these  keywords? If not then do they change all the time and you
 need an admin role to be constantly updating them? If not then why not load
 them as a static property file when Mahout starts? And if the keywords are
 allowed to change does that mean that all emails and contacts must be
 rescored?


Thanks for your suggestions.

I haven't yet designed the ReputationAnalysisService functions. I will have
to do some background research on Mahout/weka and Drools expert [1] (as
Oscar suggested I will also consider Drools expert for this component) to
answer your queries precisely. At the moment, I have the idea to perform
the email analysis process as below;
1. An initial email analysis process will be carried out to process past
emails in the user's inbox and build up a reputation index (a regression
model to rate each email based on reputation).
2. Then using that regression model predict reputation of new emails.

I'm currently doing some reading on available ML libraries like Mahout,
weka and also RulesEngines like Drools in order to design this component.
Your suggestions are also welcome..

[1] https://www.jboss.org/drools/drools-expert



 If the score for a contact is based on a history of their email scores
 then what holds this history? (hopefully you are going to tell me that
 Mahout/Hadoop) does and therefore the domain does not care.

 David.




   On Thursday, 27 March 2014 12:24 AM, Dileepa Jayakody 
 dileepajayak...@gmail.com wrote:
  Hi David,

 On Wed, Mar 26, 2014 at 4:03 PM, David Tildesley davo...@yahoo.co.nzwrote:

 Hi Dileepa,

 I see. Then the domain will perhaps have some object representing
 ReputationScore with a method such as calculateEmailReputationScore and
 calculateEmailContactReputationScore with the implementation of the
 methods based on Mahout and injected via a domain service. So it's the same
 deal no matter how you want to reword it - the complexity of the score
 calculation is not in the ISIS domain but in the Mahout implementation.


 Yes, the domain service (ReputationAnalysisService) will call out a Mahout
 recommender process  to give the reputation score of the new email.

 So what information do you need to feed these two methods in order to do
 the calculation?

 I'm planning to feed  people (to, cc, from), topic and actions (keywords
 such as meeting, project, important etc) mentioned in the email to perform
 reputation calculation.


 David.



 On Wednesday, 26 March 2014 11:09 PM, Dileepa Jayakody 
 dileepajayak...@gmail.com wrote:

 Hi David,

 On Wed, Mar 26, 2014 at 3:22 PM, David Tildesley davo...@yahoo.co.nz
 wrote:

 
  Hi David,
 
  On Wednesday, 26 March 2014 8:49 PM, Dileepa Jayakody 
  dileepajayak...@gmail.com wrote:
 
   Hi Dan, David and all,
 
   Above class diagram only contains the domain entities. Perhaps David's
   question on the domain requirements could be clarified if domain
 service
   classes are also included in the diagram. Shall I do so?
 
  No. Please don't do that. Stick to the domain object model (leave out any
  view objects also). Key attributes and methods will aid in understanding
 it.
 
  So .. you are saying that the reputation analysis/scoring is not part of
  the domain for the application but is a separate component? In that case
 I
  am correct in saying it is an external service (whether it runs in the
 same
  processor space or accessed via a web-service is irrelevant - the fact is
  that it is not part of the domain of the ISIS based application).
 
 
 Perhaps I haven't yet understood the Isis programming model as much as I
 should have. But as I see, RB server component is also within the Isis
 application domain. Implementing the RB application in Isis requires
 implementing both RB client webapp and RB server components.

 I have stated  reputation scoring is not done by some other system, it's
 done in the reputation-box server component of my application. and by that
 I wanted to convey that I see implementing the ReputationAnalysisService is
 within the domain of the Isis based application. I will integrate a Mahout
 recommendation process in the above domain service to generate the
 reputation-scores but still it will be within the Isis domain AFAIU. Please
 correct me if I'm wrong.


  I must say that this is an ambitious project with a lot of integration -
  what is the overall objective? Just to prove that ISIS is a rapid

Re: [jira] [Commented] (ISIS-743) Remove the concept of transient objects and of @NotPersistable; instead we have view models.

[David Tildesley]

Hi Dan,

Yes, I read your DDD book - the recognition and use of color modelling 
archetypes was very appropriate in that context - it's what led me to NO/ISIS 
in the first place.

I had no idea this (ISIS) domain object limitation existed in the first place 
until now - I'll admit I've pushed this discussion to find out why it is a 
problem for the framework - the only clue I had there may be a problem was the 
ISIS-743 - admittedly I am still none the wiser as to why but that's my fault 
for not taking more time to understand the framework.

I guess the first thing to do is for me to understand the problem better so I 
will withdraw from the conversation now and return to it later.

Good work on 1.4 release  - we hope to upgrade our 1.3 based app in the very 
near future. Just started using view objects and json layouts - nice and very 
necessary. 

Hope I wasn't coming across as overly critical or pessimistic or pedagogue 
like. If so, I apologize.

Regards,
David.



On Friday, 21 March 2014 8:48 PM, Dan Haywood d...@haywood-associates.co.uk 
wrote:
 
Hi David,
Nice to read about the old FDD stuff again.  I remember introducing color
modelling archetypes to Richard Pawson, and I think they an appearance in
his original NO book.  I certainly wrote about them myself in my two books
on TogetherJ and DDD.

So yes, I do get that the domain entities are part of the PD layer, not the
UI layer.  And I agree that Isis must support the ability to handle domain
objects that have no local persistence.

But since the two approaches I've suggested aren't palatable, I guess I'm
out of ideas...  Do you (or anyone else) have any suggestions on how to
accomplish this objective?


Dan

Re: [jira] [Commented] (ISIS-743) Remove the concept of transient objects and of @NotPersistable; instead we have view models.

[David Tildesley]

I'll raise a jira with the requirements so that it is tracked. We have now 
established ISIS-743 is really a separate issue to this discussion.

Sent from Yahoo Mail on Android

[jira] [Created] (ISIS-755) Allow external system data to be integrated and managed with an ISIS domain object

[David Tildesley (JIRA)]

David Tildesley created ISIS-755:


 Summary: Allow external system data to be integrated and managed 
with an ISIS domain object 
 Key: ISIS-755
 URL: https://issues.apache.org/jira/browse/ISIS-755
 Project: Isis
  Issue Type: Improvement
  Components: Core
Affects Versions: core-1.4.0
Reporter: David Tildesley
Assignee: Dan Haywood
 Fix For: core-1.4.2


Problem statement: The framework currently offers no lifecycle support for 
domain objects that get their data from and to external systems.

Requirements:

1. Manage domain object state lifecycle consistent with a locally persisted 
domain object.
2. Treat the domain object as a peer with all other domain objects for viewer 
generation and integration.
3. Integrate with standard OTB domain services such as audit service.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [jira] [Commented] (ISIS-743) Remove the concept of transient objects and of @NotPersistable; instead we have view models.

[David Tildesley]

Please see (1) for requirements and suggested solution 

[1] https://issues.apache.org/jira/browse/ISIS-755



On Saturday, 22 March 2014 9:50 AM, David Tildesley davo...@yahoo.co.nz wrote:
 
I'll raise a jira with the requirements so that it is tracked. We have now 
established ISIS-743 is really a separate issue to this discussion.

Sent from Yahoo Mail on Android

Re: [jira] [Commented] (ISIS-743) Remove the concept of transient objects and of @NotPersistable; instead we have view models.

[David Tildesley]

Hi Dan,

Lets get back to a basic foundation for the discussion.

I would like to use the terminology from the FDD (1) guys because it is clear 
and a very handy shortcut.  


to quote Paul Szego from (1)  ... The DM layer we tend not to talk about much 
anymore as we buy a persistence 
solution here rather than build our own. Thus, we're really only focusing this 
article on UI, PD and SI.     UI--| PD |-- SI (this is what we want)

All we need to understand here is that the only thing worth protecting as an 
enduring business asset is the Problem Domain (PD) layer and it must be 
independent of all other layers and be a rich domain (as understood by Martin 
Fowler's discussion on the Anemic Domain anti-pattern). In fact it needs to be 
independent from frameworks like ISIS.

When View Model arrived in ISIS, I understood exactly the intention - it was 
to allow us to create a more user friendly human oriented UI and as a bonus it 
allowed us to create a coarse-grained service oriented UI generated 
automatically by the RO viewer.  The View Model allowed us to aggregate 
information from the PD layer (from the a domain object graph) but it should 
never cause business logic to bled out of the the PD layer.

I will acknowledge here and now there are some very exceptional circumstances 
where you would allow the UI layer to bypass the PD layer. But they are 
exceptional and irrelevant to this discussion.

I have been involved in projects taking the UI--PD--SI layer approach 
(happened to use the Struts MVC in the UI layer but that's irrelevant, where 
none of the PD objects were locally persisted In fact the entire information 
set either came from users via the UI or from interaction with a mainframe over 
JMS via the SI layer. This was at a Bank and the applications were very 
significant (not trivial). We used color domain modelling techniques (the first 
step in FDD) in workshops to produce the just-enough domain model that the 
developers then implemented.

David.

[1] http://www.featuredrivendevelopment.com/node/582


On Friday, 21 March 2014 5:00 AM, Dan Haywood d...@haywood-associates.co.uk 
wrote:
 
David said:

Some more thoughts/assumptions on transient domain objects:
 1. oid - annotate an attribute or use attribute naming pattern
 2. Restful remoting mean client maintains required state - client doesn't
 care whether domain object is transient or not.
 3. Restful remoting means the server trashes the domain object instance
 after the response. However domain behaviour is not transferred and
 everytime a behaviour is invoked on a domain object graph, the domain graph
 has to re-instantiated  at the server - big performance hit unless
 developer uses a cache (ehcache or similar).
 Am I wide of the mark with any of the above?



Jeroen said:

I do agree with David that there are plenty of use cases to think of where
 having a transient domain object on the server can be useful. I am
 wondering how comparable architectures deal with transient objects, perhaps
 an analogy with a Stateful Session Bean can be made? [1]. This would make a
 good topic of conversation on the IsisCon conference too.
 [1] http://www.jguru.com/faq/view.jsp?EID=917



And on 19 March 2014 21:29, David Tildesley davo...@yahoo.co.nz also
said:

 Maybe transient is misleading in my side of the discussion. Essentially
 a viewer should be able to instantiate an ISIS domain object that has no
 connection to DataNucleus, repository as such but can still have a domain
 service implementation fetch and put data from an external source (via,
 web-service, jms, whatever) and inject into the domain object. That keeps
 my domain layer intact and doesn't result in bleeding any domain behaviour
 out to other layers (e.g. view objects which are logically in the UI layer).


 However as Dan points out, this doesn't sit well with RESTful style. In a
 traditional app, UI layer (usually using a MVC model)  will make several
 invocations on domain object graph behaviour (fine grained method level
 calls) with state being maintained in the session for as long as needed
 over a series of client requests. This is not the case with RESTful style.
 Client is responsible for maintaining state with the server having no
 obligations in this regard. This does not sit well with a fine-grained
 method invocation on the domain layer - you would normally go for those big
 coarse grained calls and end up re-implementing a domain layer in the
 client that replicates domain behaviour. This is where the RESTful model
 falls into a heap (in my opinion) as the tradeoff is very significant. To
 retain the finegrained domain layer invocation on the server side in the
 RESTful style would necessitate rebuilding the relevant domain object graph
 with every call
  and trashing it afterwards. This rebuilding hit could be mitigated by
 careful use of caching on the domain service layer, however the lifecycle
 of the domain object graph has to be completed on every

Re: [jira] [Commented] (ISIS-743) Remove the concept of transient objects and of @NotPersistable; instead we have view models.

[David Tildesley]

So ... continuing on from the foundation for the discussion:

1. Using ViewModel object as a standin domain model object is just not right 
for several reasons:
   a. It's a ViewModel object - it has only one role.
   b. To be part of a domain object graph it would most likely be referred 
to by a domain object and therefore there is now a dependency from the PD 
(domain) package to the UI (viewmodel) package.
   c. Any subsequent developer looking at the code would be confused.
   d. It's overloading the use of View Model and hence muddying the 
separation of concerns.

2. Rolling your own datastore in DataNucleus would be difficult I think - every 
integration will require yet another custom datastore added to DataNucleus. And 
now there is a dependency on DataNucleus that is not at the standards based JDO 
API level but at the DataNucleus specific API level.

There is only one logical outcome from this discussion: ISIS must allow me to 
create a domain object that has no local persistence but still enjoys all the 
other benefits of ISIS domain object and allows me to inject dependency (either 
by ISIS domain service or some other DI library). I should be able to choose 
what data attribute (or composite of data atributes) acts as the oid by 
annotation or naming pattern.

Regards,
David.





On Friday, 21 March 2014 9:31 AM, David Tildesley davo...@yahoo.co.nz wrote:
 
Hi Dan,

Lets get back to a basic foundation for the discussion.

I would like to use the terminology from the FDD (1) guys because it is clear 
and a very handy shortcut.  


to quote Paul Szego from (1)  ... The DM layer we tend not to talk about much 
anymore as we buy a persistence 
solution here rather than build our own. Thus, we're really only focusing this 
article on UI, PD and SI.     UI--| PD |-- SI (this is what we want)

All we need to understand here is that the only thing worth protecting as an 
enduring business asset is the Problem Domain (PD) layer and it must be 
independent of all other layers and be a rich domain (as understood by Martin 
Fowler's discussion on the Anemic Domain anti-pattern). In fact it needs to be 
independent from frameworks like ISIS.

When View Model arrived in ISIS, I understood exactly the intention - it was 
to allow us to create a more user friendly human oriented UI and as a bonus it 
allowed us to create a coarse-grained service oriented UI generated 
automatically by the RO viewer.  The View Model allowed us to aggregate 
information from the PD layer (from the a domain object graph) but it should 
never cause business logic to bled out of the the PD layer.

I will acknowledge here and now there are some very exceptional circumstances 
where you would allow the UI layer to bypass the PD layer. But they are 
exceptional and irrelevant to this discussion.

I have been involved in projects taking the UI--PD--SI layer approach 
(happened to use the Struts MVC in the UI layer but that's irrelevant, where 
none of the PD objects were locally persisted In fact the entire information 
set either came from users via the UI or from interaction with a mainframe over 
JMS via the SI layer. This was at a Bank and the applications were very 
significant (not trivial). We used color domain modelling techniques (the first 
step in FDD) in workshops to produce the just-enough domain model that the 
developers then implemented.

David.

[1] http://www.featuredrivendevelopment.com/node/582



On Friday, 21 March 2014 5:00 AM, Dan Haywood d...@haywood-associates.co.uk 
wrote:

David said:

Some more thoughts/assumptions on transient domain objects:
 1. oid - annotate an attribute or use attribute naming pattern
 2. Restful remoting mean client maintains required state - client doesn't
 care whether domain object is transient or not.
 3. Restful remoting means the server trashes the domain object instance
 after the response. However domain behaviour is not transferred and
 everytime a behaviour is invoked on a domain object graph, the domain graph
 has to re-instantiated  at the server - big performance hit unless
 developer uses a cache (ehcache or similar).
 Am I wide of the mark with any of the above?



Jeroen said:

I do agree with David that there are plenty of use cases to think of where
 having a transient domain object on the server can be useful. I am
 wondering how comparable architectures deal with transient objects, perhaps
 an analogy with a Stateful Session Bean can be made? [1]. This would make a
 good topic of conversation on the IsisCon conference too.
 [1] http://www.jguru.com/faq/view.jsp?EID=917



And on 19 March 2014 21:29, David Tildesley davo...@yahoo.co.nz also
said:

 Maybe transient is misleading in my side of the discussion. Essentially
 a viewer should be able to instantiate an ISIS domain object that has no
 connection to DataNucleus, repository as such but can still have a domain
 service implementation fetch and put data from an external source (via,
 web

[jira] [Commented] (ISIS-743) Remove the concept of transient objects and of @NotPersistable; instead we have view models.

[David Tildesley (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13940288#comment-13940288
 ] 

David Tildesley commented on ISIS-743:
--

Not really (fears remain). Anything can be an oid for a domain object - it 
doesn't have to be a persisted object identifier (that you would get 
automatically via the DM). e.g it could be an employee number, social security 
number, acccount number ... which would typically be the case of the 
information was coming from an external service. I can see you would have an 
immediate problem with this with a generated viewer - so I would need to give 
it some thought. 

Using JDO with a custom plugged in persistence implementation appears way too 
complex to me. Bypassing the PD layer ( i.e. UI -- SI) is promoting shifting 
business logic into the UI layer. Both unpalatable.  By the way I am assuming 
the domain service is pretty much the equivalent of a System Integration layer 
(takes care of the marshalling and unmarshalling of data to and from some 
service integration and connected to the domain object via DI.

This old but relevant thread is worth reading [1]

[1] http://www.featuredrivendevelopment.com/node/582


 Remove the concept of transient objects and of @NotPersistable; instead we 
 have view models.
 

 Key: ISIS-743
 URL: https://issues.apache.org/jira/browse/ISIS-743
 Project: Isis
  Issue Type: Wish
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: core-2.0.0

 Attachments: Design-1.PNG, Design-2.PNG


 For discussion; but think that view models supercede our earlier ideas of 
 transient objects etc.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (ISIS-743) Remove the concept of transient objects and of @NotPersistable; instead we have view models.

[David Tildesley (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13940288#comment-13940288
 ] 

David Tildesley edited comment on ISIS-743 at 3/19/14 8:25 AM:
---

Not really (fears remain). Anything can be an oid for a domain object - it 
doesn't have to be a persisted object identifier (that you would get 
automatically via the DM). e.g it could be an employee number, social security 
number, acccount number ... which would typically be the case if the 
information was coming from an external service. I can see you would have an 
immediate problem with this with a generated viewer - so I would need to give 
it some thought. 

Using JDO with a custom plugged in persistence implementation appears way too 
complex to me. Bypassing the PD layer ( i.e. UI -- SI) is promoting shifting 
business logic into the UI layer. Both unpalatable.  By the way I am assuming 
the domain service is pretty much the equivalent of a System Integration layer 
(takes care of the marshalling and unmarshalling of data to and from some 
service integration and connected to the domain object via DI.

This old but relevant thread is worth reading [1]

[1] http://www.featuredrivendevelopment.com/node/582



was (Author: davotnz):
Not really (fears remain). Anything can be an oid for a domain object - it 
doesn't have to be a persisted object identifier (that you would get 
automatically via the DM). e.g it could be an employee number, social security 
number, acccount number ... which would typically be the case of the 
information was coming from an external service. I can see you would have an 
immediate problem with this with a generated viewer - so I would need to give 
it some thought. 

Using JDO with a custom plugged in persistence implementation appears way too 
complex to me. Bypassing the PD layer ( i.e. UI -- SI) is promoting shifting 
business logic into the UI layer. Both unpalatable.  By the way I am assuming 
the domain service is pretty much the equivalent of a System Integration layer 
(takes care of the marshalling and unmarshalling of data to and from some 
service integration and connected to the domain object via DI.

This old but relevant thread is worth reading [1]

[1] http://www.featuredrivendevelopment.com/node/582


 Remove the concept of transient objects and of @NotPersistable; instead we 
 have view models.
 

 Key: ISIS-743
 URL: https://issues.apache.org/jira/browse/ISIS-743
 Project: Isis
  Issue Type: Wish
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: core-2.0.0

 Attachments: Design-1.PNG, Design-2.PNG


 For discussion; but think that view models supercede our earlier ideas of 
 transient objects etc.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (ISIS-743) Remove the concept of transient objects and of @NotPersistable; instead we have view models.

[David Tildesley (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13940851#comment-13940851
 ] 

David Tildesley commented on ISIS-743:
--

Some more thoughts/assumptions on transient domain objects:

1. oid - annotate an attribute or use attribute naming pattern
2. Restful remoting mean client maintains required state - client doesn't care 
whether domain object is transient or not.
3. Restful remoting means the server trashes the domain object instance after 
the response. However domain behaviour is not transferred and everytime a 
behaviour is invoked on a domain object graph, the domain graph has to 
re-instantiated  at the server - big performance hit unless developer uses a 
cache (ehcache or similar). 

Am I wide of the mark with any of the above?

 Remove the concept of transient objects and of @NotPersistable; instead we 
 have view models.
 

 Key: ISIS-743
 URL: https://issues.apache.org/jira/browse/ISIS-743
 Project: Isis
  Issue Type: Wish
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: core-2.0.0

 Attachments: Design-1.PNG, Design-2.PNG


 For discussion; but think that view models supercede our earlier ideas of 
 transient objects etc.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [jira] [Commented] (ISIS-743) Remove the concept of transient objects and of @NotPersistable; instead we have view models.

[David Tildesley]

Maybe transient is misleading in my side of the discussion. Essentially a 
viewer should be able to instantiate an ISIS domain object that has no 
connection to DataNucleus, repository as such but can still have a domain 
service implementation fetch and put data from an external source (via, 
web-service, jms, whatever) and inject into the domain object. That keeps my 
domain layer intact and doesn't result in bleeding any domain behaviour out to 
other layers (e.g. view objects which are logically in the UI layer).


However as Dan points out, this doesn't sit well with RESTful style. In a 
traditional app, UI layer (usually using a MVC model)  will make several 
invocations on domain object graph behaviour (fine grained method level calls) 
with state being maintained in the session for as long as needed over a series 
of client requests. This is not the case with RESTful style. Client is 
responsible for maintaining state with the server having no obligations in this 
regard. This does not sit well with a fine-grained method invocation on the 
domain layer - you would normally go for those big coarse grained calls and end 
up re-implementing a domain layer in the client that replicates domain 
behaviour. This is where the RESTful model falls into a heap (in my opinion) as 
the tradeoff is very significant. To retain the finegrained domain layer 
invocation on the server side in the RESTful style would necessitate rebuilding 
the relevant domain object graph with every call
 and trashing it afterwards. This rebuilding hit could be mitigated by 
careful use of caching on the domain service layer, however the lifecycle of 
the domain object graph has to be completed on every RESTful invocation.


Regards,
David.




On Thursday, 20 March 2014 9:06 AM, Jeroen van der Wal jer...@stromboli.it 
wrote:
 
I do agree with David that there are plenty of use cases to think of where
having a transient domain object on the server can be useful. I am
wondering how comparable architectures deal with transient objects, perhaps
an analogy with a Stateful Session Bean can be made? [1]. This would make a
good topic of conversation on the IsisCon conference too.


[1] http://www.jguru.com/faq/view.jsp?EID=917

[jira] [Commented] (ISIS-743) Remove the concept of transient objects and of @NotPersistable; instead we have view models.

[David Tildesley (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13940114#comment-13940114
 ] 

David Tildesley commented on ISIS-743:
--

I don't see the link between view models and transient objects (which I 
assume is referring to domain objects).

If by transient is meant non-persisted then there is a problem. Many business 
applications have been built that do not rely on their own persistence store. 
They fetch and send information to external services and those external 
services take care of any persistence required. However these business 
applications have a full domain model for their problem domain. 

if the only type of domain object I can create in ISIS is a persisted object 
then I can't use ISIS in the future.

Hopefully I am misinterpreting the intention of this ticket.



 Remove the concept of transient objects and of @NotPersistable; instead we 
 have view models.
 

 Key: ISIS-743
 URL: https://issues.apache.org/jira/browse/ISIS-743
 Project: Isis
  Issue Type: Wish
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: core-2.0.0


 For discussion; but think that view models supercede our earlier ideas of 
 transient objects etc.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [jira] [Created] (ISIS-705) Support actions accepting parameters, and also bulk actions, that return Blobs/Clobs

[David Tildesley]

Hi Dan,

Speaking of blobs, we noticed that somehow ISIS is persisting metadata with the 
uploaded blob (e.g. filename and maybe mimetype?). We were just wondering how 
this is done as we have to migrate an existing database table with a blob 
column (jpg photo) to our ISIS based app and we think we may have to bulk load 
through the framework rather than direct to the dom entity table. Or any other 
suggested approach for this once off migration?

Regards,
David.





On Thursday, 20 February 2014 4:27 PM, Dan Haywood (JIRA) j...@apache.org 
wrote:
 
Dan Haywood created ISIS-705:


             Summary: Support actions accepting parameters, and also bulk 
actions, that return Blobs/Clobs
                 Key: ISIS-705
                 URL: https://issues.apache.org/jira/browse/ISIS-705
             Project: Isis
          Issue Type: Improvement
          Components: Viewer: Wicket
    Affects Versions: viewer-wicket-1.3.1
            Reporter: Dan Haywood
            Assignee: Dan Haywood
            Priority: Minor
             Fix For: viewer-wicket-1.5.0


The issue here is that the returned Blob/Clob must be handled with a scheduled 
handler (see ActionResultResponseHandlingStrategy class) but it is also 
necessary to refresh the page by redirecting to a new page.  (In the case of an 
action accepting parameters, want to remove the dialog.  In the case of a bulk 
action, want to clear the toggles and refresh the list).

Haven't yet figured out how to do that ... :-(



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: [ANN] Apache Isis Wicket viewer 1.3.1 Released and updated archetypes

[David Tildesley]

Many thanks to the ISIS team for this bug fix. 

Cheers,
David.



On Thursday, 14 November 2013 8:59 PM, Dan Haywood 
d...@haywood-associates.co.uk wrote:
 
The Isis team is pleased to announce the release of:
- Wicket Viewer 1.3.1
- Simple Archetype 1.3.1
- Quickstart Archetype 1.3.1

This is primarily a bug patch of Wicket viewer; the only changes to the
archetypes are to update the dependency on the Wicket viewer.  Full release
are available at [1][2][3] on the Isis website.

You can access this release directly from the Maven central repo [4],
or download the release and build it from source [5].

Enjoy!

-The Isis team

[1]
http://isis.apache.org/components/viewers/wicket/release-notes/isis-viewer-wicket-1.3.1.html
[2]
http://isis.apache.org/getting-started/release-notes/quickstart_wrj-archetype-1.3.1.html
[3]
http://isis.apache.org/getting-started/release-notes/simple_wrj-archetype-1.3.1.html
[4] http://search.maven.org
[5] http://isis.apache.org/download.html

[jira] [Commented] (ISIS-561) Now we have support for view models, we could simplify matters elsewhere by removing support for transient objects.

[David Tildesley (JIRA)]

[ 
https://issues.apache.org/jira/browse/ISIS-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801074#comment-13801074
 ] 

David Tildesley commented on ISIS-561:
--

view objects belong in the UI layer. domain layer should be independent of UI 
layer. There is a requirement to have non-persisted domain objects. Persistance 
is just an injected behaviour to the domain object (save me). Many times a 
domain graph is created from a system to system interaction (i.e. calling  an 
external service to get information or put information).

 Now we have support for view models, we could simplify matters elsewhere by 
 removing support for transient objects.
 ---

 Key: ISIS-561
 URL: https://issues.apache.org/jira/browse/ISIS-561
 Project: Isis
  Issue Type: Improvement
  Components: Core
Affects Versions: viewer-wicket-1.2.0, viewer-restfulobjects-2.0.0, 
 core-1.2.0
Reporter: Dan Haywood
Assignee: Dan Haywood
 Fix For: viewer-wicket-2.0.0, viewer-restfulobjects-2.2.0, 
 core-2.0.0


 Some discussion is required before going ahead with this.  But it'd be nice 
 to delete a bunch of code... :-)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: [DISCUSSION] next gen viewer

[David Tildesley]

Hi Oscar,

+1 


Can I just check with you that adding bootstrap will provide a master html 
template for the site? This would be really useful for including e.g header 
meta info in one place (please correct me if this is already possible now).

Regards,

David.

Oscar wrote:

 Perhaps, in the meantime, we could consider the addition of Bootstrap to

 the Wicket viewer.
 That seemed a really good solution until the new viewer debate started,
 and also that it was feasible to accomplish it on Christmas.
 There were also some contributors interested, and it can be a way to learn
 about bootstrap in the meanwhile.

 The end-result would be a really good (stateful) customizable viewer for
 2014 (including some navigation improvements like those transient entities
 used only for navigation, and, perhaps, modal action dialogs) and a really
 scalable and customizable viewer from 2015 on.

Re: Isis session and transaction management on a custom viewer

[David Tildesley]

Hi Oscar,

That's good (CAS) where Shiro has a plugin. We (it's not my money) weren't 
prepared to invest in writing a Kerberos authentication plugin for Shiro when 
Weblogic already does Kerberos authentication and it's already got the tick 
from Ent architecture.

I'll let you know what conclusions we come to on the session timeout and 
logout - it's all about giving the user a good experience as SSO can confuse 
them when it seamlessly logs them back in but they get a different session. I 
guess if you don't have desktop (kerberos)  SSO to the CAS sts then you haven't 
got the same issue as us if you keep the cas token timeout less than the http 
session timeout.

Cheers,
David.



 From: GESCONSULTOR - Óscar Bou o@gesconsultor.com
To: us...@isis.apache.org; David Tildesley davo...@yahoo.co.nz 
Cc: dev dev@isis.apache.org 
Sent: Saturday, 7 September 2013 3:17 AM
Subject: Re: Isis session and transaction management on a custom viewer
 

Hi, David.

Really interesting. This second  we plan to integrate with the CAS SSO platform 
the Isis domain, as detailed in [1]. 

Authentication in CAS, authorization in Domain, thanks to Shiro (and also on 
CAS on ). 

It would be helpful to know about your approach to logout and session timeout 
when you implement it. But in our case seems that CAS will manage that 
functionality, instead of Shiro.

Thanks,

Oscar



[1] http://shiro.apache.org/cas.html

El 06/09/2013, a las 12:52, David Tildesley davo...@yahoo.co.nz escribió:

 Hi Dan,
 
 Dan wrote:
 
 If using Isis' Shiro integration for authenticaiotn/authorizatino, then
 there are also Shiros session management to consider [4].  I am pretty sure
 the default for that is also HttpSession, but it would seem to be pluggable
 and they say it supports clusters [5].
 
 You're right. Played with this by co-incidence today. I think this default 
 causes some loss of useful Shiro features (deferring to the container). 
 Turned on Shiro native session manager today by simple property in 
 Shiro.ini as per Shiro documentation[4]. Works ok and adds more capability 
 (e.g. ability to define Shiro session event listener,define Shiro session 
 timeout, ...). We are leaning towards form based container based 
 authentication (already hooked Shiro into trusting container authentication 
 and leaving Shiro to do authorisation). Reason is that we are using container 
 authentication for NegotiateAssertion for enterprise desktop SSO (Kerberos) 
 and we make this a permanent feature and also  have a fall through 
 (SUFFICIENT)  AD ldap authenticator defined as next container 
 authentication provider - simply to make life easy for the testers. We hope 
 to log events off the Shiro session events (start, stop, ...) . But we've 
 still got work to do
 around this and the side affects (e.g. session timeout and logout 
 behaviour). 
 
 If  using native session manager then need to name the Shiro session cookie 
 something other than the default JSESSIONID because it causes weirdness when 
 the container also produces a session cookie of the same name.
 
 David.
 
 
 [2] http://wicket.apache.org/meet/introduction.html
 [3] http://www.jtict.com/blog/wicket-isnt-suited-for-websites/
 [4] http://shiro.apache.org/session-management.html
 [5] http://shiro.apache.org/web.html#Web-ServletContainerSessions
 [6] https://issues.apache.org/jira/browse/ISIS-299
 [7]
 https://github.com/apache/isis/blob/master/core/src/docbkx/guide-runtime-to-incorporate/images/architecture.png

Re: [DISCUSSION] next gen viewer

[David Tildesley]

Hi Dan,

Sounds good (for internet facing apps).

In my opinion, web UI's for internal applications were a big step backwards for 
enterprises - clumsy for users and expensive to build (at least before ISIS 
came along) compared to rich clients. I guess web technology has advanced to a 
point where it has almost caught up with rich client technology of 15 years ago 
but that's hardly something to crow about. The argument put forward for web 
UI's in the enterprise was zero maintenance in terms of the desktop (all the 
difficulties of packaging and distribution of rich clients eliminated) but then 
rich clients caught up in that area (at least for Java). But then comes along 
smart phones and tablets and html5 that potentially changes the game again. Or 
maybe not - html5 turns out to not be the panacea it was touted to be and now 
we are back to the future with the horrible incompatibilities of vendors 
implementations and versions. Facebook recently publicly vented on this subject 
and have declared the end of
 their romp with html5 and a return to native.

With ISIS able to generate many viewers, then perhaps we are looking at the 
real game changer in the enterprise being ISIS.

The DnD viewer I understood was a highly productive desktop UI for DSW? of 
Ireland. Should it not live on in the form of a JFX based viewer? Then the 
alternative jscript based viewer(s) could deliver to a variety of portable 
devices or instead  a native iOS and Android ISIS and Metro? app generated 
viewer.

The wicket viewer is good. However, bouncing around different objects to get a 
view of information in a graph can be frustrating even with the sliding 
bookmark bar when you want to go back a few steps but I guess less frustrating 
than one of those damn wizards that forces you along a particular process.

Sometimes (maybe often) it is preferable to present an aggregated view of 
information in the UI from an object graph instance. One could achieve this 
with a custom UI (e.g. calling the ISIS domain RO viewer) however I'm thinking 
why not simply use a (transient) ISIS object instead and treat it as a UI model 
component which from my point of view simply amounts to making it transient and 
putting it in a package that indicates that it is not part of the domain layer 
and ensure that this UI object has a dependency on the domain layer but never 
the other way around ( no dom object should depend on the UI). To give you an 
example: Say I have a Human Resource domain (with 
Person---Employment---PositionAssigment---Position---OrgUnit---Organisation)
 but I want to implement an easy to enterprise resource directory so that users 
could quickly search for people in the organisation and once found display all 
the relevant and permitted information about the
 person on a single page so that the user doesn't have to bounce around the dom 
graph to get this information. So I have a StaffDetails aggregating object in 
the UI that dynamically aggregates the relevant information from the dom object 
graph by calling dom behaviour. Similarly I might want to implement a MyDetails 
UI object for the same reason. Does that make sense? To me, taking this 
approach makes the wicket viewer a lot more acceptable to users.

Regards,
David.









 From: Dan Haywood d...@haywood-associates.co.uk
To: users us...@isis.apache.org 
Cc: dev dev@isis.apache.org 
Sent: Saturday, 7 September 2013 8:25 PM
Subject: [DISCUSSION] next gen viewer
 

Breaking this out to a new thread...

~~~
Over the last few days I've (coincidentally) been having off-list
discussions with both Maurizio and Jeroen, thinking about what the next gen
viewer should be implemented and might look like.

We're all agreed, I think, that it should be a stateless RO-based viewer,
and that it should build on Spiro [1].

In other words, the next gen viewer will be an SPA app, with AngularJS
underneath, making RESTful calls to the Isis-provided backend.  The SPA app
would (as they all do) use some sort of templating framework and widget
framework for generate the GUI.  For the latter, I think that Bootstrap is
a candidate (though Jeroen didn't agree, I think).

Although (hopefully) scalable to the internet, the intent should still
primarily be for problem solvers, not process followers, ie for those who
are familiar with the domain.

What that implies is solving the modality problem; allowing the user to
switch context and to associate different contexts.  The original DnD
viewer - whatever other faults it might have had - was very good at
supporting this, with its desktop (windowed) metaphor.  Adam Howard's
(currently stagnant) AROW viewer [2] also adopts a desktop metaphor.

At the other end of the spectrum, my Wicket viewer is very page oriented.
This means that the user looks only at one object at a time.  The
autocomplete stuff makes it easier to associate stuff, and the bookmarks
panel helps provide some sense of context, but I'm the first 

Re: Isis session and transaction management on a custom viewer

[David Tildesley]

Hi Dan,

Dan wrote:

If using Isis' Shiro integration for authenticaiotn/authorizatino, then
there are also Shiros session management to consider [4].  I am pretty sure
the default for that is also HttpSession, but it would seem to be pluggable
and they say it supports clusters [5].

You're right. Played with this by co-incidence today. I think this default 
causes some loss of useful Shiro features (deferring to the container). Turned 
on Shiro native session manager today by simple property in Shiro.ini as per 
Shiro documentation[4]. Works ok and adds more capability (e.g. ability to 
define Shiro session event listener,define Shiro session timeout, ...). We are 
leaning towards form based container based authentication (already hooked Shiro 
into trusting container authentication and leaving Shiro to do authorisation). 
Reason is that we are using container authentication for NegotiateAssertion 
for enterprise desktop SSO (Kerberos) and we make this a permanent feature 
and also  have a fall through (SUFFICIENT)  AD ldap authenticator defined as 
next container authentication provider - simply to make life easy for the 
testers. We hope to log events off the Shiro session events (start, stop, ...) 
. But we've still got work to do
 around this and the side affects (e.g. session timeout and logout 
behaviour). 

If  using native session manager then need to name the Shiro session cookie 
something other than the default JSESSIONID because it causes weirdness when 
the container also produces a session cookie of the same name.

David.


[2] http://wicket.apache.org/meet/introduction.html
[3] http://www.jtict.com/blog/wicket-isnt-suited-for-websites/
[4] http://shiro.apache.org/session-management.html
[5] http://shiro.apache.org/web.html#Web-ServletContainerSessions
[6] https://issues.apache.org/jira/browse/ISIS-299
[7]
https://github.com/apache/isis/blob/master/core/src/docbkx/guide-runtime-to-incorporate/images/architecture.png

Re: Isis session and transaction management on a custom viewer

[David Tildesley]

Hi Oscar,

David (me) wrote:

I guess if you don't have desktop (kerberos)  SSO to the CAS sts then you 
haven't got the same issue as us if you keep the cas token timeout less than 
the http session timeout.

Scrub that previous assumption - you will have the same problem if the user is 
accessing other services and therefore keeping the CAS SSO token alive - they 
will arrive back at the application with the http session expired but with a 
valid CAS token and Shiro will dutifully authenticate them and pass them to a 
resource with a brand new session - same potential for a bad user experience. 
Our solution (when we figure it all out) should work for your scenarios also.

David.



 From: David Tildesley davo...@yahoo.co.nz
To: us...@isis.apache.org us...@isis.apache.org 
Cc: dev dev@isis.apache.org 
Sent: Saturday, 7 September 2013 9:37 AM
Subject: Re: Isis session and transaction management on a custom viewer
 

Hi Oscar,

That's good (CAS) where Shiro has a plugin. We (it's not my money) weren't 
prepared to invest in writing a Kerberos authentication plugin for Shiro when 
Weblogic already does Kerberos authentication and it's already got the tick 
from Ent architecture.

I'll let you know what conclusions we come to on the session timeout and 
logout - it's all about giving the user a good experience as SSO can confuse 
them when it seamlessly logs them back in but they get a different session. 

Cheers,
David.



From: GESCONSULTOR - Óscar Bou o@gesconsultor.com
To: us...@isis.apache.org; David Tildesley davo...@yahoo.co.nz 
Cc: dev dev@isis.apache.org 
Sent: Saturday, 7 September 2013 3:17 AM
Subject: Re: Isis session and transaction management on a custom viewer


Hi, David.

Really interesting. This second  we plan to integrate with the CAS SSO platform 
the Isis domain, as detailed in [1]. 

Authentication in CAS, authorization in Domain, thanks to Shiro (and also on 
CAS on ). 

It would be helpful to know about your approach to logout and session timeout 
when you implement it. But in our case seems that CAS will manage that 
functionality, instead of Shiro.

Thanks,

Oscar



[1] http://shiro.apache.org/cas.html

El 06/09/2013, a las 12:52, David Tildesley davo...@yahoo.co.nz escribió:

 Hi Dan,
 
 Dan wrote:
 
 If using Isis' Shiro integration for authenticaiotn/authorizatino, then
 there are also Shiros session management to consider [4].  I am pretty sure
 the default for that is also HttpSession, but it would seem to be pluggable
 and they say it supports clusters [5].
 
 You're right. Played with this by co-incidence today. I think this default 
 causes some loss of useful Shiro features (deferring to the container). 
 Turned on Shiro native session manager today by simple property in 
 Shiro.ini as per Shiro documentation[4]. Works ok and adds more capability 
 (e.g. ability to define Shiro session event listener,define Shiro session 
 timeout, ...). We are leaning towards form based container based 
 authentication (already hooked Shiro into trusting container authentication 
 and leaving Shiro to do authorisation). Reason is that we are using container 
 authentication for NegotiateAssertion for enterprise desktop SSO (Kerberos) 
 and we make this a permanent feature and also  have a fall through 
 (SUFFICIENT)  AD ldap authenticator defined as next container 
 authentication provider - simply to make life easy for the testers. We hope 
 to log events off the Shiro session events (start, stop, ...) . But we've 
 still got work to do
 around this and the side affects (e.g. session timeout and logout 
 behaviour). 
 
 If  using native session manager then need to name the Shiro session cookie 
 something other than the default JSESSIONID because it causes weirdness when 
 the container also produces a session cookie of the same name.
 
 David.
 
 
 [2] http://wicket.apache.org/meet/introduction.html
 [3] http://www.jtict.com/blog/wicket-isnt-suited-for-websites/
 [4] http://shiro.apache.org/session-management.html
 [5] http://shiro.apache.org/web.html#Web-ServletContainerSessions
 [6] https://issues.apache.org/jira/browse/ISIS-299
 [7]
 https://github.com/apache/isis/blob/master/core/src/docbkx/guide-runtime-to-incorporate/images/architecture.png

Re: [ANNOUNCE] New committer - Oscar Bou

[David Tildesley]

Good stuff Oscar. 

A few comments:

I think there needs to be a continued and strong focus on the generated UI(s) 
which is frankly the sweet spot for NO/ISIS that is unmatched in any other 
system. DDD is easily achieved without NO/ISIS. For us ISIS is going to live or 
die based on what we can achieve with the generated UI.

JDO is good - not sure why we would want to swap to JPA which only supports 
relational databases. 

Regards,
David.





 From: GESCONSULTOR - Óscar Bou o@gesconsultor.com
To: us...@isis.apache.org 
Cc: dev dev@isis.apache.org 
Sent: Tuesday, 13 August 2013 2:12 AM
Subject: Re: [ANNOUNCE] New committer - Oscar Bou
 


First of all, excuse for this quite long email, but I'm really grateful for 
being accepted as a committer to Apache Isis, and I would like to express the 
reasons behind this commitment in the hope it helps other list subscribers to 
move to Apache Isis, and also to contrast my thoughts.

Our first driver towards moving to Apache Isis was not its automatic UI 
generation through its viewer technology (which could be seen as its main 
advantage by some developers). We already had a working app and our own User 
Interface.
It was due to the support of a shared vision about the capability to translate 
the business rules implemented in the domain to all related technologies 
working with it, including (but not only) the User Interface. It should help a 
lot in the support of the  Hexagonal architecture pattern ([1], [2]). The 
Apache Isis meta-model has allowed to directly support distinct viewers 
implemented with different technologies, including the support of a full 
specification of a REST interface to the core domain [3] (which can ease a lot 
of internal teams to implement further Hexagonal architecture adapters, such as 
custom interfaces in different technologies for external teams, in a fully 
automated and supported manner).


I envision Apache Isis as the least risky approach to DDD in common business 
domains due to the following strengths:

1. It allows to start focused on the highest risk, the domain:
- With Apache Isis you just have to concentrate on the domain and a custom User 
Interface and REST API are automatically generated and updated, allowing really 
fast inputs about the current domain implementation. Work on less-risky areas 
(such as the UI) can be easily postponed.

2. It allows to start easy when the expectations about the domain complexity 
are not high, or, at least, not as clear to decide to invest on a full DDD 
approach: 
- Implementing a basic domain can be nearly as easy as on Microsoft Access by 
using the current Archetype, the Eclipse templates and the available Viewers 
(as the Apache Wicket viewer for automating the webapp implementation).
- As new business rules are discovered, they can be incorporated to the Apache 
Isis domain, and are automatically propagated to (used by) the viewers.
- Unlike scaffolding technologies, the user interface and other architectural 
adapters behave dynamically and adapt intelligently to the current domain 
implementation by means of the Apache Isis meta-model, which eases a lot the 
domain improvements, application maintenance and technology upgrades. 

3. It eases to start, explore and evolve the domain with full domain 
testability, through the new support for Behavior-Driven Development:
- The business expert and the developer can work together on defining features 
and business scenarios that can be implemented and tested with Apache Isis.
- And as the user interface, the BDD behavior, the fixtures, etc. are supported 
by Isis, it allows really rapid iteration cycles focusing on the domain, so the 
project risk is rapidly detected and minimized by the experts and developers.


As in all software projects, there is space for improvement, and it could be 
among others in the following areas:

* Improved domain business rules support. It must be the core strength of 
Apache Isis (where the viewer and other related technologies are a derivative 
work). And it could include:
- domain objects that behave by default conforming to all business rules 
defined (i.e., wrapped by default, a controversial point, I'm sure), 
- direct JSR-349 supporting facets, etc.

* Support for migrating existing projects to Apache Isis. There is a high and 
fast growth vector for the community by being adopted by currently existing 
applications. But for that, official APIs should be provided for:
- Custom viewers support: easing the interaction with custom-made 
pre-existing User Interfaces (through the REST API, but also through Java 
APIs). It should include fully-supported API classes or interfaces for Apache 
Isis session handling, transaction management, etc.
- JPA support: most Java applications use at the persistent layer the JPA API 
or the custom Hibernate API. The initial support for JPA could be based on 
DataNucleus, allowing to migrate all persistent domain classes and 

[jira] [Created] (ISIS-472) Limit number of bookmarks

[David Tildesley (JIRA)]

David Tildesley created ISIS-472:


 Summary: Limit number of bookmarks
 Key: ISIS-472
 URL: https://issues.apache.org/jira/browse/ISIS-472
 Project: Isis
  Issue Type: New Feature
  Components: Core, Viewer: Wicket
Reporter: David Tildesley
Assignee: Dan Haywood
Priority: Minor


Ability to limit the number of bookmarks. First in, first out when the limit is 
reached. If the user has pinned the bookmark then this remains at the top of 
the panel and is not removed until the user removes it or the users session is 
ended.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (ISIS-473) Allow operations to individually be specified for @bookmarkable behaviour.

[David Tildesley (JIRA)]

David Tildesley created ISIS-473:


 Summary: Allow operations to individually be specified for 
@bookmarkable behaviour.
 Key: ISIS-473
 URL: https://issues.apache.org/jira/browse/ISIS-473
 Project: Isis
  Issue Type: Improvement
  Components: Core, Viewer: Wicket
Reporter: David Tildesley
Assignee: Dan Haywood
Priority: Minor


The bookmarks tab gets filled up quickly with operations from an object that is 
marked as @bookmarkable. It would be better to have finer grained control over 
which operations (if any) are bookmarked. Maybe it is easier to overide the 
existing behaviour by a @bookmarkable parameter for an operation that 
effectively prevents the operation from becoming bookmarked.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (ISIS-467) timezone difference issue in date test in org.apache.isis.objectstore.sql.HsqlTest

[David Tildesley (JIRA)]

David Tildesley created ISIS-467:


 Summary: timezone difference issue in date test in 
org.apache.isis.objectstore.sql.HsqlTest
 Key: ISIS-467
 URL: https://issues.apache.org/jira/browse/ISIS-467
 Project: Isis
  Issue Type: Bug
  Components: Core
 Environment: Just followed the estatio build instructions to build 
ISIS on ubuntu 12.04. Time zone for my computer is GMT+12 
Reporter: David Tildesley
Assignee: Dan Haywood
Priority: Minor


Test set: org.apache.isis.objectstore.sql.HsqlTest
---
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.667 sec  
FAILURE!
testTestAll(org.apache.isis.objectstore.sql.HsqlTest)  Time elapsed: 0.752 sec  
 FAILURE!
java.lang.AssertionError: Applib date: Test '2010-3-5', expected 2010-03-05, 
but got 2010-03-06. Check log for more info.
at org.junit.Assert.fail(Assert.java:88)


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira