Re: Deep copy object graph

[David Tildesley]

Thanks Dan.  

On Tuesday, 14 March 2017 6:09 PM, Dan Haywood 
<d...@haywood-associates.co.uk> wrote:
 

 Meant to post an opinion on this.

My thought was to store the object graph as a jaxb / xml ; these are then
easy to clone and are also view models automatically.

Downside to this design is handling changes to the structure of these over
time... Anyway backward breaking change would be problematic.

HTH
Dan

On Tue, 14 Mar 2017, 05:39 David Tildesley, <davo...@yahoo.co.nz.invalid>
wrote:

> Thanks Kevin,
> I guess I was looking for something like deep clone using serialization
> rather than detach-clone-persist and so on through the object graph. Being
> lazy ;)
> Regards,David.
>
>    On Tuesday, 14 March 2017 4:07 PM, "ke...@kmz.co.za" <ke...@kmz.co.za>
> wrote:
>
>
>  Hi David,
>
> Did you find a solution?
>
> Just a question: Why would you not use a standard service action to
> create the copy? Is there any reason why you want Datanucleus to do it?
>
> Personally, I would try and use a service that creates a copy of the
> current records and updates the public reference instance to always
> point to the latest (perhaps use a Proxy, for example - and another
> administrative view that displays the full set of changes over time).
>
> Cheers,
> Kevin
>
>
> On 2017-03-08 06:05, David Tildesley wrote:
> > Hi,
> > I have a need to keep public records and to be able to edit objects
> > and put them through a publishing lifecycle whilst public can view the
> > current record without seeing the changes.
> > Temporal object pattern [1] seems like the simplest pattern.
> > Then it comes down to how hard or easy it is to simply  copy a
> > components entire object graph to make a new version (don't really
> > care about the duplication of data that hasn't change from version to
> > version).
> > Datanucleus has some support for coping an object graph from one
> > repository to another - I assume you can copy to the same repository
> > to achieve what I want to do.
> > Krypo [2] seems like it is being used by Datanucleus.
> > Anyways - how to do this with ISIS? Any suggestions appreciated.
> > Some context:
> > A Building (component)  has a current FireSafetyCertification
> > (component) and is published as a public record and these records are
> > kept for 10 years. A change to a record that is viewable by the public
> > is regarded as a new public record. Overtime (slowly) these
> > FireSafetyCertificates may expire/withdrawn/change in detail. But when
> > they are published they constitute a public record. Building has
> > names, addresses, images, parts, construction details, etc. whilst
> > FireSafetyCertification has documents, exemption notices, expiry dates
> > etc.
> > Using the Temporal Object pattern, a Building object has 1..*
> > BuildingVersion and all of the Building's detail hangs off
> > BuildingVersion.
> > Any other suggestions instead of Temporal Object pattern also
> > appreciated.
> >
> > [1] https://martinfowler.com/eaaDev/TemporalObject.html
> > [2] http://camposha.info/source/java-kryo/
> > Thanks!
> > David.
>
>
>


   

Re: Deep copy object graph

[David Tildesley]

Thanks Kevin,
I guess I was looking for something like deep clone using serialization rather 
than detach-clone-persist and so on through the object graph. Being lazy ;)
Regards,David. 

On Tuesday, 14 March 2017 4:07 PM, "ke...@kmz.co.za" <ke...@kmz.co.za> 
wrote:
 

 Hi David,

Did you find a solution?

Just a question: Why would you not use a standard service action to 
create the copy? Is there any reason why you want Datanucleus to do it?

Personally, I would try and use a service that creates a copy of the 
current records and updates the public reference instance to always 
point to the latest (perhaps use a Proxy, for example - and another 
administrative view that displays the full set of changes over time).

Cheers,
Kevin


On 2017-03-08 06:05, David Tildesley wrote:
> Hi,
> I have a need to keep public records and to be able to edit objects
> and put them through a publishing lifecycle whilst public can view the
> current record without seeing the changes.
> Temporal object pattern [1] seems like the simplest pattern.
> Then it comes down to how hard or easy it is to simply  copy a
> components entire object graph to make a new version (don't really
> care about the duplication of data that hasn't change from version to
> version).
> Datanucleus has some support for coping an object graph from one
> repository to another - I assume you can copy to the same repository
> to achieve what I want to do.
> Krypo [2] seems like it is being used by Datanucleus.
> Anyways - how to do this with ISIS? Any suggestions appreciated.
> Some context:
> A Building (component)  has a current FireSafetyCertification
> (component) and is published as a public record and these records are
> kept for 10 years. A change to a record that is viewable by the public
> is regarded as a new public record. Overtime (slowly) these
> FireSafetyCertificates may expire/withdrawn/change in detail. But when
> they are published they constitute a public record. Building has
> names, addresses, images, parts, construction details, etc. whilst
> FireSafetyCertification has documents, exemption notices, expiry dates
> etc. 
> Using the Temporal Object pattern, a Building object has 1..*
> BuildingVersion and all of the Building's detail hangs off
> BuildingVersion. 
> Any other suggestions instead of Temporal Object pattern also 
> appreciated.
> 
> [1] https://martinfowler.com/eaaDev/TemporalObject.html 
> [2] http://camposha.info/source/java-kryo/
> Thanks!
> David.


   

Deep copy object graph

[David Tildesley]

Hi,
I have a need to keep public records and to be able to edit objects and put 
them through a publishing lifecycle whilst public can view the current record 
without seeing the changes.
Temporal object pattern [1] seems like the simplest pattern.
Then it comes down to how hard or easy it is to simply  copy a components 
entire object graph to make a new version (don't really care about the 
duplication of data that hasn't change from version to version).
Datanucleus has some support for coping an object graph from one repository to 
another - I assume you can copy to the same repository to achieve what I want 
to do.
Krypo [2] seems like it is being used by Datanucleus.
Anyways - how to do this with ISIS? Any suggestions appreciated.
Some context:
A Building (component)  has a current FireSafetyCertification (component) and 
is published as a public record and these records are kept for 10 years. A 
change to a record that is viewable by the public is regarded as a new public 
record. Overtime (slowly) these FireSafetyCertificates may 
expire/withdrawn/change in detail. But when they are published they constitute 
a public record. Building has names, addresses, images, parts, construction 
details, etc. whilst FireSafetyCertification has documents, exemption notices, 
expiry dates etc. 
Using the Temporal Object pattern, a Building object has 1..* BuildingVersion 
and all of the Building's detail hangs off BuildingVersion. 
Any other suggestions instead of Temporal Object pattern also appreciated.
[1] https://martinfowler.com/eaaDev/TemporalObject.html [2] 
http://camposha.info/source/java-kryo/
Thanks!
David.

Re: choices / autocomplete with option to create new item

[David Tildesley]

Hi All,

Imho:

Putting the "don't do CRUD" principle spin on this: Isn't it just a 
matter of allowing a "Concert" component (I call it component since it 
will have several objects that are associated with the primary 
moment-interval) instance to be "built up" until it can be "published"? 
All you need is a "canPublish()" method returning a boolean that does 
all the necessary checks to ensure all the required bits and bobs are in 
place before "publishing" it (for want of a better term). Why are you 
wanting to create a rod for you own back by having database constraints 
to enforce business logic when you can enforce the constraints in logic 
in your code with more flexibility? I may be wrong, but I think the 
Naked Object model would force you take this approach because you are 
only allowed to "see" domain objects in the viewer. Use of view models 
will tend to take you in the other direction - caution needed. 
Conflating "view" aspects with "domain" aspects will make the situation 
worse.


Next make sure you have firmly in your mind the separation of UI 
concerns from domain layer concerns - don't conflate them. If you need 
to create some view models to build aggregate forms or a wizard - 
because that is what your users demand  just remember the separation of 
concerns principle - view models are UI, not domain layer and they will 
tend to cause you to compromise the domain layer/model if you are not 
fastidious about this.


By the way, it is next to impossible to have this discussion without a 
proper domain model available - if there is no domain model available 
then you are already traveling an unsound path.


Regards,

David.

On 30-Sep-16 12:37 PM, Stephen Cameron wrote:

Hi Martin,

Just a few thoughts in response inline.

On Fri, Sep 30, 2016 at 12:51 AM, Martin 
wrote:


Thanks all for your replies and your input.

The DDD book was actually one of the books I bought many years ago and
enjoyed reading a lot. I still recommend it to friends and colleagues.


:) Which probably led you to trying Apache Isis?


I gave Stephens idea a second thought and tried out this approach today.
For the association of more complex objects, like let's say a
ConcertLocation which cannot be created from within the Concert dialogue
there is a Fixture creating a dummy placeholder ConcertLocation object,
which can be selected instead, and the Concert entity has an action to
create a new ConcertLocation, so that things can be corrected after
creation.


I'm don't think this is the best approach to take, if a Concert must have a
concert location then offer the user two options in the Concert dialogue, a
list of existing ConcertLocations and a String parameter to (at least) name
a new one if the one of interest does not pre-exist. A validate method for
the create action can check that one of these but not both is
selected/filled. That was Dan's suggestion I think.

If the problem is that there are so many mandatory properties for a Concert
the Concert 'create' action gets to become a big list of parameters, and
one that is confusing to 'naive' users, which I don't Apache Isis being a
good fit for anyway. There might be a case for designing a ConcertBuilder
domain class, this is just used to collect data for then creating a new
valid Concert. Such a ConcertBuilder could be a state-machine maybe, it has
a series of Actions that are enabled or disabled based on current state?


I will still have to come up with a way to highlight/color fields that
reference placeholder objects (identified by name or by a flag) to make it
clear in the UI that something still needs to be done. This does the trick
for a few cases where there the next level object only has trivial
properties or associations to already existing objects.

To address how to draw attention of the users to replacing placeholders
with real objects a possible approach would be to have special query for
the placeholder objects to see which other objects reference them, maybe
thus proposing a set of ToDos/problems to the user on the dashboard that
need to be addressed. Such as: there are currently three concerts
referencing the dummy/placeholder location, please go look at them and
correct that. One could probably construct a business rule from that to
check for overall validity of an object tree. If any of the referenced
objects in the tree is a placeholder, then the path is invalid.


There is a incode Notes module [2] that I think could be of value, this
could be used in the 'create' action to attach a note to the concert saying
that a new ConcertLocation has been created that might need further
validation. Maybe by a data-quality person. I am using this module.


I was thinking about the distinction between static and dynamic data. There
are certainly cases when a user should not be allowed to add a new entity
to a collection, but then again I can also think about times when the data
structures that are being transferred from 

Re: object level ownership / tenancy

[David Tildesley]

ser);

(2)

 String disables(Object domainObject, ApplicationUser

applicationUser);  (3)

}



To test this, I knocked up a demo app; it's implementation of this

service

is:

@DomainService(nature = NatureOfService.DOMAIN)public class
ApplicationTenancyEvaluatorForConcerts implements
ApplicationTenancyEvaluator {
 public boolean handles(Class cls) {
 return Concert.class.isAssignableFrom(cls);
 }
 public String hides(Object domainObject, ApplicationUser

applicationUser) {

 if (!(domainObject instanceof Concert)) {
 return null;
 }
 final Concert concert = (Concert) domainObject;

 final Optional roleIfAny =
 applicationUser.getRoles()
 .stream()
 .filter(role ->

Objects.equals(role.getName(),

concert.getName()))  (1)
 .findAny();

 return roleIfAny.isPresent()? null: "Requires role " +
concert.getName();
 }
 public String disables(Object domainObject, ApplicationUser
applicationUser) {
 return null;
 }
}



Hope that makes sense, let us know how you get on.

Cheers
Dan


[1] https://github.com/isisaddons/isis-module-security
[2] https://github.com/danhaywood/security-generalized-tenancy-app



On 24 September 2016 at 23:53, David Tildesley

<davo...@yahoo.co.nz.invalid>

wrote:


Just read my own post. Sorry those chevrons were meant to be double,

and

they are only indicating color modelling "archetypes"[1] - force of

habit -

helps me conceptualize problem domains.

[1] http://www.nebulon.com/articles/fdd/download/adspostera3.pdf




On 24-Sep-16 3:59 PM, David Tildesley wrote:


Hi Martin,

You haven't described a  tenancy problem so I wouldn't necessarily

try

and bend that to your problem. I would model it in the domain and

use

domain behavior. The behaviour checks if the user is a member of a
committee (Committee) in the role of managing

(ConcertManager)

the concert (Concert) before allowing operations

on

the

concert component.

Regards,

David.


On 23-Sep-16 6:07 PM, Martin wrote:


Hello,

We want to give ownership of specific objects in the domain model

to a

subset of users.

Example: an application to manage concerts, and a subset of the

users

is

the concert organization committee. The members of
the organization committee can be added and removed at runtime or

defined

when creating a new concert object. A user can be assigned to be a

member

of multiple committees, and the members of a concerts organization
committee should be granted permissions to manipulate the concert

and

its

associated objects.

I looked at the isis-security-module (
https://github.com/isisaddons/isis-module-security) and also at

the

tenancy, but I had trouble figuring out if this could actually

serve

our

needs.

How would one go about this with apache isis?

Thanks and regards,
Martin





--
Bilgin Ibryam
Camel Committer at ASF & Integration Architect at Red Hat
Blog: http://ofbizian.com | Twitter: @bibryam

Camel Design Patterns https://leanpub.com/camel-design-patterns
Instant Apache Camel Message Routing http://www.amazon.com/dp/

1783283475

Re: object level ownership / tenancy

[David Tildesley]

Just read my own post. Sorry those chevrons were meant to be double, and 
they are only indicating color modelling "archetypes"[1] - force of 
habit - helps me conceptualize problem domains.


[1] http://www.nebulon.com/articles/fdd/download/adspostera3.pdf



On 24-Sep-16 3:59 PM, David Tildesley wrote:

Hi Martin,

You haven't described a  tenancy problem so I wouldn't necessarily try 
and bend that to your problem. I would model it in the domain and use 
domain behavior. The behaviour checks if the user is a member of a 
committee (Committee) in the role of managing 
(ConcertManager) the concert (Concert) before 
allowing operations on the concert component.


Regards,

David.


On 23-Sep-16 6:07 PM, Martin wrote:

Hello,

We want to give ownership of specific objects in the domain model to a
subset of users.

Example: an application to manage concerts, and a subset of the users is
the concert organization committee. The members of
the organization committee can be added and removed at runtime or 
defined
when creating a new concert object. A user can be assigned to be a 
member

of multiple committees, and the members of a concerts organization
committee should be granted permissions to manipulate the concert and 
its

associated objects.

I looked at the isis-security-module (
https://github.com/isisaddons/isis-module-security) and also at the
tenancy, but I had trouble figuring out if this could actually serve our
needs.

How would one go about this with apache isis?

Thanks and regards,
Martin

Re: object level ownership / tenancy

[David Tildesley]

Hi Martin,

You haven't described a  tenancy problem so I wouldn't necessarily try 
and bend that to your problem. I would model it in the domain and use 
domain behavior. The behaviour checks if the user is a member of a 
committee (Committee) in the role of managing 
(ConcertManager) the concert (Concert) before 
allowing operations on the concert component.


Regards,

David.


On 23-Sep-16 6:07 PM, Martin wrote:

Hello,

We want to give ownership of specific objects in the domain model to a
subset of users.

Example: an application to manage concerts, and a subset of the users is
the concert organization committee. The members of
the organization committee can be added and removed at runtime or defined
when creating a new concert object. A user can be assigned to be a member
of multiple committees, and the members of a concerts organization
committee should be granted permissions to manipulate the concert and its
associated objects.

I looked at the isis-security-module (
https://github.com/isisaddons/isis-module-security) and also at the
tenancy, but I had trouble figuring out if this could actually serve our
needs.

How would one go about this with apache isis?

Thanks and regards,
Martin

Re: Apache ISIS - Shiro - CAS Authentication

[David Tildesley]

Hi Uma,
Just an idea: you could extend  
org.apache.isis.viewer.wicket.viewer.integration.wicket.WebRequestCycleForIsis
1. Check for a Wicket Session: org.apache.wicket.protocol.http.WebSession.get();
2. If none, assume the "container" has authenticated the user so then check 
HttpServletRequest for a remote user (getRemoteUser();)
3. If remote user exists then set the user in wicket:  
org.apache.wicket.authroles.authentication.AuthenticatedWebSession.get(0.signIn(username,
 ""):

No doubt a few other things to take care of but may be a good starting point.

David. 

On Tuesday, 16 August 2016 5:04 PM, uma narayan 
 wrote:
 

 Hi,
I need to integrate apache isis with shiro-cas. With shiro-cas I was able to 
authenticate and authorize successfully but still isis login page is presented 
is to me. 

Summarizing my application flow:1. CAS filter re-directs to CAS Login 
2. CAS Realm performs authentication and authorization3. Then, apache isis 
login page is presented again.

On analyzing the source code found that AuthenticatedWebSession is not created. 
Please provide me a solution to resolve this issue.
Thanks for your help,Uma




  

Re: Binary, non-base 64 upload

[David Tildesley]

Good point Kambiz - with the likes of S3 object storage this is becoming a 
common requirement - especially for very large files where loading the whole 
file into memory is not appropriate. And much better than storing in a rdbms 
blob column.

I suggest a hidden mandatory attribute on a domain object (actually to hold the 
stored object ID once it has uploaded) to prevent the form from being submitted 
and javascript (delivered via a custom wicket component) using Fine Uploader 
Javascript Upload Library since it is Ajax your form is not submitted until 
your javascript allows it by storing the uploaded object ID in the hidden 
mandatory field. Also the user sees a fine progress bar whilst uploading and 
this library supports chunking and direct to S3 and Azure or to traditional 
server side (servlet).
What do you think?
Regards,David.

|   |
|   |  |   |   |   |   |   |
| Fine Uploader Javascript Upload LibraryFine Uploader. A dependency-free, 
open-source, native browser upload tool. |
|  |
| View on fineuploader.com | Preview by Yahoo |
|  |
|   |

 

On Saturday, 6 August 2016 7:31 AM, Martin Grigorov  
wrote:
 

 Hi Kambiz,

I guess this code works only because you don't need another request
parameter in the same action.
Latest versions of Isis recommend to have an action per request parameter,
so maybe this is not an issue.
But imagine submitting a form with one or more text fields and one file
upload field. To be able to pass the values of the input fields Isis will
need to call request.getParameter(someName) and this will consume the
request body and later your code won't see anything in the inputstream.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Fri, Aug 5, 2016 at 4:27 PM, Kambiz Darabi 
wrote:

> Hello Martin,
>
> On 2016-08-05 13:42 CEST, Martin Grigorov  wrote:
>
> > [...]
> > The problem here is that you have to make sure that your code is the very
> > first one that reads from the ServletInputStream. Otherwise the body will
> > be already consumed.
> > You may need to override some Wicket/RESTeasy code to be able to do this
> > for the default viewers.
> > And this would be much harder than custom Servlet Filter in front of the
> > ones by Wicket/RESTeasy
>
> If you look at the change in my original post:
>
> https://github.com/m-creations/isis/commit/aa3b16a5cf463466f5abadbcc8cc73
> f16857a628
>
> you can see that I added this functionality to the
> restfulobjects-viewer, so that I can be sure that the full stream is
> handed to the action without any change.
>
> That code is tested against the Isis archetype with this addition to the
> SimpleObjectMenu service:
>
>    @Action(semantics = SemanticsOf.SAFE)
>    public void upload(HttpServletRequest request, HttpServletResponse
> response) {
>      FileOutputStream out = null;
>      try {
>        File outFile = new File("/tmp/request");
>        out = new FileOutputStream(outFile, false);
>        IOUtils.copy(request.getInputStream(), out);
>        out.close();
>      } catch (IOException e) {
>        if(out != null) {
>          try {
>            out.close();
>          } catch (IOException e1) {
>            // LOG something
>          }
>        }
>        // throw something
>      }
>    }
>
>
> and the file in /tmp/request is identical to the posted binary file which
> is sent by
> curl:
>
> curl -X POST --data-binary @big-binary-file
>  --header "Authorization: Basic c3ZlbjpwYXNz" \
>  --header "Accept: application/json;profile=urn:org.apache.isis/v1" \
>  --header "Content-Type: application/octet-stream" \
>  http://localhost:8080/restful/services/SimpleObjectMenu/
> actions/upload/invoke
>
>
> Cheers
>
>
> Kambiz
>
> >
> >> action with the metadata of the files/request, but it would help a lot
> >> to have such a facility inside Isis instead of writing a separate
> >> servlet and manually integrating its deployment and the calling of
> >> domain actions etc.
> >>
> >> Cheers
> >>
> >>
> >> Kambiz
> >>
> >>
> >> On 2016-08-03 18:53 CEST, Willie Loyd Tandingan <
> tandingan@gmail.com>
> >> wrote:
> >>
> >> > Hi Kambiz,
> >> >
> >> > We had a requirement similar to yours. The problem with injecting
> >> > HttpServletRequest to domain services is that it kind of violates the
> >> DDD's
> >> > hexagonal architecture by letting viewer implementation leak into the
> >> > domain layer.
> >> >
> >> > The specific requirement that we had was to be able to pre-upload
> files
> >> > before submitting an action. We developed a custom blob that stores
> an id
> >> > instead of the actual data, a service layer that manages a blob
> storage
> >> > abstracting and running on top of jclouds (we plan to be able to
> support
> >> > other types of storage aside from file system), and a file service
> that
> >> > manages the state of "transient files" (files that were pre-uploaded
> or
> >> > that are returned from actions as result 

Re: Edit modes in Apache Isis

[David Tildesley]

Hi,
Just to add an architectural perspective - I think you are all right and all 
wrong at the same time ;). 
Dan is absolutely right if he constrains his comments to Domain Objects (which 
I believe is the case).
I think the framework should enforce the Naked Object principles (which are in 
turn are an expression of sound architecture and OO principles and patterns) .  
And that means no CRUD exposed in the UI directly from Domain Objects and for 
Domain Objects to be action/behaviour oriented.
However in reference to the UI layer - then consider it disposable, evolving 
and changing with new views as need for specific use cases. That is precisely 
what the View Model is for in ISIS I believe.
The domain layer (domain objects), provided the domain model was well designed 
in the first place, is mostly stable and easily extended over the lifecycle of 
the application. 
We can't stop developers from bleeding concerns across layers but we can do 
more  re-inforce the domain object/model and the rich domain pattern which is a 
reflection of the principle of separation of concerns and layering style.
What it does mean though, is  that for many use cases, it is less likely that 
you will expose the domain objects directly and more likely you will use View 
Model (I hesitate to use the term View Object for obvious reasons) and View 
Model will call behaviour on the domain objects as needed.
Which hopefully means that generated wicket UI/viewer behaviour from View Model 
source will move to provide what some folk are asking for - a rapid data input 
(tab through the fields type of thing). But not from domain objects.
OK so it means that you need to deliberately layer your application by 
separating View and Domain concerns ... but that is a good thing in the long 
run of the life of your app is it not?
ISIS doesn't make the NO paradigm mandatory - that was caused by the 
introduction of the view model - I think that is a good thing - provided that 
you understand that the view model is UI layer only and you shouldn't bleed 
domain behaviour into it.
Regards,David.

 

On Thursday, 26 May 2016 5:15 AM, Dan Haywood 
 wrote:
 

 Good input, thanks.

My experience both with Estatio (4 years) but also with the big Naked
Objects system in Ireland (12 years) is that actions only is good enough in
the vast majority of cases ; and where bulk input is genuinely needed, then
we can usually address it with a little lateral thinking.

For Estatio, there's an occasional requirement to bulk upload new tax
rates, and for that we use the isis-module-excel that allows the users to
just upload an excel spreadsheet and process that.  Works quite well.

The risk of allowing general free - form editing in ERP systems is that
users are liable to abuse the freedom... we saw this for example in the
packaged software that Estatio replaced... spare /unused fields end up
being co-opted to store all sorts of adhoc info.  Instead, we should be
exploiting the fact that Isis allows such rapid development by keeping
things tight: relying on actions only means that the conversation as to
*why* the data needs to change can be had, resulting in a richer ubiquitous
language/insights/domain model.

All that said, we'll continue to evolve and improve the default UI, and to
make it easier to allow it to be extended for use cases such as this. One
option is different UIs, or to use custom UIs based on the Restful viewer,
but they are completely different experiences from an end-user
perspective.  Another more seamless/smoother integration might be to
leverage the nowicket framework which allows custom Wicket forms to be
developed quite easily; we've been in touch with its developer, and have
started spiking some things.

Hope that helps explain some of the rationale a little better.

Thanks,
Dan

http://invesdwin.de/nowicket/introduction

Hello. I have to agree with Steve and Hector. In my experience creating
and implementing ERP and large Merchandise Management systems, the
ability to change all fields within a TAB combined with in-line row
entry and editing is a must in a system where you handle a large volume
of transactional data entry (we have been extensively using those
features for the last 25 years or so in our systems, and the users
strongly request them). As an example use case, a user must enter
sometimes tens or even hundreds of rows (a purchase order line item
detail, a price change batch line item, journal entries and so on). Just
try doing that using the mouse and going back and forth on each row.
Luckily in our current applications we are building with Apache ISIS, we
are managing most of the data entry on the mobile devices, which handle
this in-line editing and all form editing easily, leveraging the amazing
ISIS capability to create web services from actions. But we do not see
us using the current Isis forms for that a system where there is volume
data entry in the browser. Having the ISIS ability 

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
  

Re: Integration with Keycloak?

[David Tildesley]

Hi Anton,
Having just read all about Keycloak and the fact it is ASL 2.0 licensed, I 
think that is an excellent idea. Apache Shiro has the advantage with it's fine 
grained permission model and role to application permission mapping but 
Keycloak is a much more comprehensive access manager that can provide SSO 
across multiple applications, support Social network authentication, REST API 
authentication etc. But it does overlap with some of the recent user management 
features in the ISIS-Addons.Looks like Keycloak and Shiro could work together 
with Keycloak asserting the authentication and Identity attributes and roles 
with Shiro continuing to offer the fine grained permission model based on the 
asserted roles and it's role to permisson mapping.
How you would go about doing that, I am not the best person to ask, but really 
keen to see Keycloak integrated.
Regards,David.  

On Tuesday, 19 January 2016 6:56 AM, Anton Hughes  
wrote:
 

 Hello

I am interested in knowing if it is possible to integrate keycloak, and if
yes, how would this be done?

Thanks and kind regards
Anton


  

Re: Does ISIS make following "rich domain model" pattern easier?

[David Tildesley]

Thanks Dan for this comprehensive reply. 

Regards,David. 


 On Monday, 16 November 2015 8:48 PM, Dan Haywood 
<d...@haywood-associates.co.uk> wrote:
   

 

On 15 November 2015 at 20:30, David Tildesley <davo...@yahoo.co.nz> wrote:

Hi All,

I am looking for reasons why Apache ISIS framework promotes and enables a "rich 
domain model" [1] [2]  and therefore promotes OO design.



It certainly _enables_ a rich domain model, whereas many other frameworks don't 
even do that.  And its architecture acts a little like a "firewall", preventing 
behaviour from leaching out of the domain layer and into the adjacent 
presentation layer and persistence layer, ie technical infrastructure layers 
that should have no business logic.
I don't know that it necessarily promotes OO (non-anaemic) design, or rather, 
you can choose to do that or you can choose not to.  Generally it's easier to 
start with a non-anaemic approach - just put behaviour into actions on methods 
- so in the sense that that is the quickest route to a functioning app, then I 
suppose it does promote OO.
However, the more I work with the naked objects pattern the more I think of it 
as an aspect-oriented system rather than an object-oriented one.  We are all 
used to AOP at the technical infrastructure level, for example security 
(authorization), logging/auditing, command profiling ... and these are all 
supported by the framework.  Also, persistence is another cross-cutting concern 
which the framework offloads to the DataNucleus ORM.  But I also think of naked 
objects pattern itself as a cross-cutting concern... basically the ability for 
provide a representation of domain objects in the presentation layer.
Over and above AOP at the technical layer, I think that the framework also 
promotes aspect-orientation within the domain layer itself.  For example, for a 
long time we've had the concept of contributed actions, which is behaviour 
implemented in domain services but which apparently belongs to the domain 
objects (binding on action parameter types).  Over the last couple of years the 
framework has extended this to contributed collections and contributed 
properties.  In the most recent 1.10.0 release we've simplified this with the 
new @Mixin annotation ... so these things are very much like AOP traits.  I 
experimented with this concept while implementing the incode-module-notes and 
incode-module-commchannel modules [3], so one can see what such code looks 
like.   I've also used it for some new functionality to be able to generate XML 
and XSDs from JAXB-annotated "DTO" view models [4]
Also (and I only actually realized this while drafting this answer) the events 
that we emit on the event bus (for 
hide/disable/validate/pre-execute/post-execute) are actually a type of 
pointcut, allowing other behaviour (of the subscribers) to be interleave and 
influence with the original business logic.
What's important, I think, is not OO design per se.  It's that the framework 
supports the single responsibility pattern, ie that the way to organize code is 
to put code that changes at the same rate together, but to separate out code 
that changes at different rates.  So sometimes putting behaviour with data is 
the right thing, but sometimes it's right to move that behaviour out into a 
mixin or into a subscriber of an event.


 
And of course any reasons to the contrary (i.e. things that ISIS does that gets 
in the way of OO design).



No, I don't think it does get in the way of OO design.    Though that said 
there are some minor limitations to the sorts of OO designs one can 
contemplate... we still don't support collections as action parameters, for 
example.

 
Or is it simply neutral? i.e. developer choice.



This is probably the best answer.  Though it takes a little time working with 
the framework to realize this... most will think it is heavily biased to OO and 
rich domain models and only later realize that one can do it both ways.
My 2c, but would love to hear other opinions on this too.
CheersDan
[3] http://catalog.incode.org/[4] 
https://github.com/apache/isis/blob/master/core/applib/src/main/java/org/apache/isis/applib/services/jaxb/Dto_downloadXml.java
 
Regards,
David.

[1] 
https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/
[2] http://www.martinfowler.com/bliki/AnemicDomainModel.html




  

Re: Does ISIS make following "rich domain model" pattern easier?

[David Tildesley]

Thanks Stephen,
Certainly the intention of DDD is to make it easier for a development team to 
focus on a  "rich domain model" and therefore OO design principles.
I agree Naked Objects approach facilitates the focusing on the domain model as 
an intention.
And so both DDD and Naked Objects have the same intention. Another way of 
putting it is that they both strive to remove the "distractions" that derail 
the domain model.
You could also say the same about UML class model to code intention - the 
intention is to remove the technical "distractions" so that everyone can focus 
on the domain model with the basic use of UML representing the "just enough" 
domain model design.
One of the main influencers on an efficient and loosely coupled (rich) domain 
model shape is domain behaviour (actual problem domain behaviour - beyond the 
basic setters and getters) e.g. calculateXXX(...). 
Regards,David.
 
 


 On Monday, 16 November 2015 10:54 AM, Stephen Cameron 
<steve.cameron...@gmail.com> wrote:
   

 Hi David,

I would ask a slightly different question: does Isis assist with DDD as
explained by Evans as a means of "tackling complexity"  (the root of what
makes big projects fail I believe)?.

In fact its slightly disturbing to me to hear this talk of UML
"design-time" tools and of round-tripping, that is, if learning by coding
and refactoring a design (as code) is the essence of 'agile'  DDD. In fact
I spent alot of time looking into this and decided that UML and MDA
particularly were not that helpful, for that reason. If they were we'd have
moved to executable UML.

I think a bigger problem is that people use OO when its not actually the
best kind of language for their specific problem.

To answer your question though, I'd say its the naked objects approach more
than use of OO per se that aids that, you focus more on the objects than on
specific use-cases. If that is done an anaemic design seems improbable.

On Mon, Nov 16, 2015 at 7:30 AM, David Tildesley <davo...@yahoo.co.nz>
wrote:

> Hi All,
>
> I am looking for reasons why Apache ISIS framework promotes and enables a
> "rich domain model" [1] [2]  and therefore promotes OO design.
>

> And of course any reasons to the contrary (i.e. things that ISIS does that
> gets in the way of OO design).
>
> Or is it simply neutral? i.e. developer choice.
>
> Regards,
> David.
>
> [1]
> https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/
> [2] http://www.martinfowler.com/bliki/AnemicDomainModel.html
>


  

Re: Thinking about re-introducing UML in our workflow

[David Tildesley]

On Sunday, 15 November 2015 5:37 AM, Dan Haywood 
 wrote:
> Thanks for this James.

> My observation re: using the (relational) data model as the initial input
> though is that this is likely to lead to rather coupled code, ultimately
> not maintainable.

Couldn't agree more.


> So, while going from the database up to the domain is fine for a single
> module of 10 or so entities, any app that is bigger than this really should
> be modelled from the domain down to the database.

Quite right. Any business app that is non trivial should be domain modelled.

David.

> Dan





On 14 November 2015 at 15:00, James Agada  wrote:

> I actually tested out using Telosys to generate an isis app from database
> definition. It did work but of course it meant i did the ER first. I used
> MySQL, did the ER modelling on the workbench, forward engineered into the
> database and then used telosys scripts to generate a functional Isis
> application. Did it as a PoC but we will come back to it later.
> James Agada
> Chief Technology Officer
>
>
> On 14 Nov 2015, at 3:49 PM, Óscar Bou - GOVERTIS 
> wrote:
>
> Many thanks, Stephen for this detailed explanation.
>
> The problem I’m facing is that I intent to communicate the developers
> what’s the model to implement.
>
> And I usually don’t find big mistakes in action code, but what mostly
> forces us to refactor is miscommunication regarding the Domain Entities,
> attributes and actions names, including typos  (think my team speak Spanish
> but they’re modeling in English) or wrong or missing relationships between
> those entities.
>
> All that could be avoided by firstly agree in a common UML Class Diagram.
>
> If it can potentially generate automatically the Java skeleton with Apache
> Isis annotations is a big plus, as it will avoid mistakes when moving from
> design to implementation.
>
> And if it could potentially reverse engineer Java (incl. Apache Isis
> idioms) a really good feature.
>
> Any ideas about what tools could best adapt to the workflow (that could be
> potentially customized to cover the last 2 whishes) ?
>
>
> Thanks,
>
> Oscar
>
>
>
>
> El 14 nov 2015, a las 2:03, Stephen Cameron 
> escribió:
>
> Hi Oscar,
>
> In a qualified way I think your idea has merit. I have never used UML for
> design, but a few years ago I decided to take a good look at it and see it
> if was useful. The idea of being able to draw a diagram and generate code
> from it seemed sensible, after all that is what is done by most other
> 'design' professions, such as building architects and engineers.
>
> To cut a long story short I realised after some reading that it was not
> that simple, and that OO languages themselves are really all that are
> needed for the process of designing a system. This is "the code is the
> design" school of thought, mainly attributed to Jack Reeves [1].
>
> I found that  keeping code and UML diagrams in sync in a top-down 'UML to
> code' design process will always be problematic (maybe why there are
> apparently no open-source tools that claim to do this). Then I read about
> Domain Driven Design which seemed to agree with this premise, and from
> there found Apache Isis via Dan's  book.
>
> So now for me UML class diagrams do have an after the fact use for
> documentation purposes and if a solution implement was capable of that
> reverse generation of diagrams from code it would be a good thing to have.
> Entity Framework can do this, its their "code first" approach.
>
> Given that the-code-is-the-design is true, I think that UML class diagrams
> real main value is as a data model, the question then is why not use a
> purely data-modeling tool and generate Java classes off it. Then the
> diagrams 'designed' could have a usefulness to programmers and to system
> users, something like those created SchemaSpy [2]  for example.
>
> There are already useful and free Java class generation (binding) tools
> from off data-models, of one sort or another, such as JAXB, DataNucleus'
> schemaGen[3], even CAM [4].
>
> Here is my vision of what I think would be really useful: to have a design
> tool that can be used by non-programmers to create a simple data-model, and
> then to have that create a working Apache Isis based CRUD system. This
> could serve your purpose (I guess) and also find a wider use.
>
> The means of achieving this would I think, require something like the
> "dynamic classes" in available in the Moxy framework [5], that is, map
> based so that no Java class compilation is needed. Instead, a data-model
> configuration file (a schema) is read-in to configure the system. This is
> not a strange idea, in fact its the data-driven programming paradigm that
> is the basis of the original browser concept (before it was turned into OO
> application framework via addition of Javascript). In the browser the data
> is HTML that is turned into an 

Does ISIS make following "rich domain model" pattern easier?

[David Tildesley]

Hi All,

I am looking for reasons why Apache ISIS framework promotes and enables a "rich 
domain model" [1] [2]  and therefore promotes OO design.

And of course any reasons to the contrary (i.e. things that ISIS does that gets 
in the way of OO design).

Or is it simply neutral? i.e. developer choice.

Regards,
David.

[1] 
https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/
[2] http://www.martinfowler.com/bliki/AnemicDomainModel.html

Re: RAD RACE 2015

[David Tildesley]

Hi Stephen,
On Tuesday, 6 October 2015 12:20 AM, Stephen Cameron 
 wrote:
>In fact as configurable systems get more and more complex, the need 
>for>programming disappears, to be replaced by 'configurators' (business
>analysts?) tweeking workflow and rules engines.
I have seen such an approach almost ruin a business and I have yet to witness a 
successful example. It's akin to the early SOA hype concepts (you know, the 
forms based "UI" calling enterprise services that invoke workflow in workflow 
engines that invoke rules in rules engines and the so called "composite 
application"). Some very expensive lessons indeed. SOA has found it's rightful 
place in the enterprise albeit vastly scaled back in ambition. 
Richard Pawson wrote a blog on "workflow-a-triumph-of-hope-over-experience" but 
unfortunately the web has lost it like it loses so many gems. Maybe Richard 
will re-post it somewhere if he is reading this.
Long live DDD :)
Cheers,David.

Re: code-lists and administration thereof

[David Tildesley]

Hi Stephen,
A Description archetype object may or may not have domain behaviour however it 
would most likely have default behaviour. It caters for your values because 
your use-case was constrained list of values. It has the advantage being an 
object that you can have both unique code, value (e.g.name), and tip 
(description) and sensible additions like validFromDate, validToDate, 
version, ... 
Given that ISIS generates the viewer, perhaps there is a strong case for first 
class support for Description archetype in ISIS. 
I personally think that Eric Evans made an absolute  hash of this area of his 
DDD - by demoting an important archetype to a Value object. If he had taken 
the time to read Peter Coads works, I think DDD would have had far stronger 
influence on software development of business systems than it has. 
Regards,David.

 


 On Thursday, 30 July 2015 9:49 PM, Stephen Cameron 
steve.cameron...@gmail.com wrote:
   

 Hi David, I was speaking of the values/entries not the catalog or code-list 
collection object, which as you say will have some behaviour.

On Thu, Jul 30, 2015 at 3:53 PM, David Tildesley davo...@yahoo.co.nz wrote:

Hi Stephen,
Notwithstanding any issues with ISIS, I disagree with your assertion 
quoteIn terms of
domain modelling such code-lists are simple types that 'represent' things
on the boundary of the domain of interest./quote

When Peter Coad came up with the 4 domain archetypes and the DNC (Domain 
Neutral Component) [1],one of the archetypes was the Description archetype: 
The Description class archetype that models a catalog-entry-like description. 
It is a collection of values that apply again and again. It also provides 
behavior across the collection of all things that correspond to its 
description. [Coad99]. - See more at: Peter Coad's 'Modeling in Color'

|   |
|   |  |   |   |   |   |   |
| Peter Coad's 'Modeling in Color'An object modeling technique, 'modeling in 
color' helps identify and define robust, extensible, problem domain classes for 
a software component, application, or sys... |
|  |
| View on www.step-10.com | Preview by Yahoo |
|  |
|   |



[1] http://www.step-10.com/SoftwareDesign/ModellingInColour/

|   |
|   |   |   |   |   |
| Java Modeling In Color With UML: Enterprise Components and Process: Peter 
Coad, Jeff de Luca, Er...This is the first book to teach software design in 
color. Peter Coad and his co-authors use four colors to represent four 
archetypes: forms that appear repeatedly in effective component and object 
models. Given a color, you'll know the kind of attributes, links, methods, and 
int... |
|  |
| View on www.amazon.com | Preview by Yahoo |
|  |
|   |




     On Thursday, 30 July 2015 2:17 PM, Stephen Cameron 
steve.cameron...@gmail.com wrote:


 Not so simple, as now the property cannot be updated.

I have the following (@Hidden is deprecated)

    @Column(allowsNull = true)
    @MemberOrder(sequence = 7)
    @PropertyLayout(hidden=Where.EVERYWHERE)
    public Region getRegion() {
        return this.region;
    }

    public void setRegion(Region region) {
        this.region = region;
    }

    public ListRegion choicesRegion(){
        ListRegion regions = container.allInstances(Region.class);
        return regions;
    }

    @MemberOrder(sequence = 7.1)
    public String getRegionName(){
        return (getRegion() != null) ? getRegion().getName() : null;
    }

Sure enough getRegion doesn't appear in the UI but getRegionName does, but
then setRegion and choiceRegion don't mean anything to the UI, so the
Region property is read-only.

This issue is maybe more significant than it appears at first, in terms of
domain modelling such code-lists are simple types that 'represent' things
on the boundary of the domain of interest. So we usually want to just
represent them with a name. Presently it makes no sense to go to that thing
via a hyperlink as all we'll find is that name, our model extends no
further.

However we just might like to allow users to leave the domain model and go
to a resource outside. So, extending the suppressLink=true idea, I would
add that each object could have an implicit link(URL),created by Isis, or
an explicit one and if the explicit one is present it can optionally be
used as an alternative to the implicit one.

For example, you might create a database to log fish details, species is a
boundary concept, we aren't likely to want to add a new species to the list
of known species, but we'd like to keep such a list handy, but for each
named species in that list, to provide an explicit link to a resource in a
global fish database. It makes more sense to use this link than the
implicit one, as if the implicit one is used we'd navigate to the domain
object page displaying the name and URL, both of which items of data could
have been in the explicit link.

In the explicit case you might want to warn the user they are navigating
outside the Isis domain application.

Perhaps all this could be done

Re: Ideas for online forms application.

[David Tildesley]

()).newTransientMultiTenantUnnamedEntity(clazz1, 
null, null);

                this.wrapSkipRules(orderedItemOption).setOrderedItem(this);
                this.wrapSkipRules(orderedItemOption).setGroupOption(current);

                this.persist(orderedItemOption);

            }
        }
    }

    private void clearOptions() {
        final SetOrderedItemOption copySet = 
Sets.newHashSet(this.getOptions());
        for (final OrderedItemOption current : copySet) {
            this.getOptions().remove(current);
            this.getContainer().flush();
        }
    }

@PersistenceCapable
@XMSEntityNames({ @XMSEntityName(locale = es, name = Artículo Principal del 
Pedido) })
public class OrderedMainItem extends OrderedItem {

…}


@PersistenceCapable
public class OrderedSubItem extends OrderedItem {

    // {{ SubItem (property)
    private SubItem subItem;

…
}


@PersistenceCapable@XMSEntityNames({ @XMSEntityName(locale = es, name = 
Opción de Artículo del Pedido) })public abstract class OrderedItemOption 
extends AbstractMultiTenantUnnamedEntity {
    // {{ OrderedItem (property)    private OrderedItem orderedItem;
…
    // }}
    // {{ ItemOptionGroupOption (property)    private ItemOptionGroupOption 
groupOption;


——

And after that some specialized classes for the different types of ItemOption 
the app manages:
@PersistenceCapable@XMSEntityNames({ @XMSEntityName(locale = es, name = 
Opción con Elección del Artículo del Pedido Genérico) })public class 
GenericOrderedItemOptionWithChoices extends OrderedItemOption {
    // {{ ChoiceSelected (property)    private 
GenericItemOptionWithChoicesChoice choiceSelected;

…}
@PersistenceCapable@XMSEntityNames({ @XMSEntityName(locale = es, name = 
Opción con Fecha del Artículo del Pedido Genérico) })public class 
GenericOrderedItemOptionWithDate extends OrderedItemOption {
    // {{ DateSelected (property)    private Date dateSelected;
...    // }} @PersistenceCapable@XMSEntityNames({ @XMSEntityName(locale = es, 
name = Opción con Número del Artículo del Pedido Genérico) })public class 
GenericOrderedItemOptionWithNumber extends OrderedItemOption {
    // {{ NumberEntered (property)    private BigDecimal numberEntered;
…}


 
HTH,
Oscar


El 28/7/2015, a las 10:15, Stephen Cameron steve.cameron...@gmail.com 
escribió:

Hi David,

My two bits worth, I think Apache Isis is the last thing i would use for
this kind of a task. If the information collected is that complex, then
trying to fit in into a relational database via an object model makes no
sense. Just use an XML database and XForms.

There are server-side implementations of XForms that work well, namely
Orbeon and BetterForms, if you want to hide the declarative form logic from
users.

For me, its Isis for behaviour and XForms/XQuery for complex data, both are
efficient in their domains of specialisation.

Where the boundary lies is an interesting puzzle to me. There is paper that
myself and another wrote, somewhat on this contrast, here [1].

XForms is efficient as all the complexity that you describe can be done
declaratively via XPath predicates [2]. That said, there is no validating
compiler, so refactoring is a pain for example. Joeron's suggestion of two
domain models might be alluding to that perhaps? But subforms do provide a
means to manage this.

Finally, XForms can be fun too, see [3]

Cheers
Steve Cameron

[1]
http://www.balisage.net/Proceedings/vol10/html/Velasquez01/BalisageVol10-Velasquez01.html
[2] http://lib.tkk.fi/Diss/2007/isbn9789512285662/article3.pdf
[3]
http://exist-db.org/exist/apps/XSLTForms-Demo/modules/form.xq?form=tic-tac-toe.xml



On Sun, Jul 26, 2015 at 11:38 AM, David Tildesley davo...@yahoo.co.nz
wrote:


Hi,
I am looking for some ideas around how ISIS could be helpful in the
following Use Case. N.B. For non-disclosure reasons, I have to mask the
real problem domain however at the same time try and give you a sense of
what it all about and the degree of complexity.
UC1. Apply for 'XYZ'
N.B. 'XYZ' in truth has many variations ('XYZa, XYZb, XYZc, ...) which
differ substantially in the information that must be collected from the
Applicant(s). There is only a very small subset of information that is
common.
1. The Applicant(s) (individual(s)) core details (name, contact details,
dob, identity document number, ...). Depending on the type of 'XYZ' a very
large set of additional information about these parties must be collected
(e.g. educational qualifications, military history, job history, ...)2.
Depending on the type of 'XYZ' and the answers to previous questions,
information about other Parties (Organisation or Individual) must be
collected.3. The system needs to be reactive to the user input. The user
should only be presented with the relevant forms question/input that comply
with the rules for the 'XYZ' type and context (their answers to previous
questions that may trigger another set of questions).4. The system should
group questions into multiple input forms rather than have

Re: code-lists and administration thereof

[David Tildesley]

Hi Stephen,
Notwithstanding any issues with ISIS, I disagree with your assertion 
quoteIn terms of
domain modelling such code-lists are simple types that 'represent' things
on the boundary of the domain of interest./quote

When Peter Coad came up with the 4 domain archetypes and the DNC (Domain 
Neutral Component) [1],one of the archetypes was the Description archetype: 
The Description class archetype that models a catalog-entry-like description. 
It is a collection of values that apply again and again. It also provides 
behavior across the collection of all things that correspond to its 
description. [Coad99]. - See more at: Peter Coad's 'Modeling in Color'

|   |
|   |  |   |   |   |   |   |
| Peter Coad's 'Modeling in Color'An object modeling technique, 'modeling in 
color' helps identify and define robust, extensible, problem domain classes for 
a software component, application, or sys... |
|  |
| View on www.step-10.com | Preview by Yahoo |
|  |
|   |



[1] http://www.step-10.com/SoftwareDesign/ModellingInColour/

|   |
|   |   |   |   |   |
| Java Modeling In Color With UML: Enterprise Components and Process: Peter 
Coad, Jeff de Luca, Er...This is the first book to teach software design in 
color. Peter Coad and his co-authors use four colors to represent four 
archetypes: forms that appear repeatedly in effective component and object 
models. Given a color, you'll know the kind of attributes, links, methods, and 
int... |
|  |
| View on www.amazon.com | Preview by Yahoo |
|  |
|   |




 On Thursday, 30 July 2015 2:17 PM, Stephen Cameron 
steve.cameron...@gmail.com wrote:
   

 Not so simple, as now the property cannot be updated.

I have the following (@Hidden is deprecated)

    @Column(allowsNull = true)
    @MemberOrder(sequence = 7)
    @PropertyLayout(hidden=Where.EVERYWHERE)
    public Region getRegion() {
        return this.region;
    }

    public void setRegion(Region region) {
        this.region = region;
    }

    public ListRegion choicesRegion(){
        ListRegion regions = container.allInstances(Region.class);
        return regions;
    }

    @MemberOrder(sequence = 7.1)
    public String getRegionName(){
        return (getRegion() != null) ? getRegion().getName() : null;
    }

Sure enough getRegion doesn't appear in the UI but getRegionName does, but
then setRegion and choiceRegion don't mean anything to the UI, so the
Region property is read-only.

This issue is maybe more significant than it appears at first, in terms of
domain modelling such code-lists are simple types that 'represent' things
on the boundary of the domain of interest. So we usually want to just
represent them with a name. Presently it makes no sense to go to that thing
via a hyperlink as all we'll find is that name, our model extends no
further.

However we just might like to allow users to leave the domain model and go
to a resource outside. So, extending the suppressLink=true idea, I would
add that each object could have an implicit link(URL),created by Isis, or
an explicit one and if the explicit one is present it can optionally be
used as an alternative to the implicit one.

For example, you might create a database to log fish details, species is a
boundary concept, we aren't likely to want to add a new species to the list
of known species, but we'd like to keep such a list handy, but for each
named species in that list, to provide an explicit link to a resource in a
global fish database. It makes more sense to use this link than the
implicit one, as if the implicit one is used we'd navigate to the domain
object page displaying the name and URL, both of which items of data could
have been in the explicit link.

In the explicit case you might want to warn the user they are navigating
outside the Isis domain application.

Perhaps all this could be done simply if there was a URI type in Isis, that
would allow it to create 'smart links' automatically.





On Wed, Jul 29, 2015 at 9:37 PM, Stephen Cameron steve.cameron...@gmail.com
 wrote:

 Thanks Jeroen, seems simple enough :)

 On Wed, Jul 29, 2015 at 9:28 PM, Jeroen van der Wal jer...@stromboli.it
 wrote:

 You could also hide the property and create a separate getter for display
 purposes only:

 private MyProperty myProperty;

 @Hidden
 public MyProperty getMyProperty() {...}

 public void setMyProperty(...) {...}

 public String getMyPropertyName() {
    getMyProperty.getName();
 }

 On 29 July 2015 at 13:18, Stephen Cameron steve.cameron...@gmail.com
 wrote:

  On Wed, Jul 29, 2015 at 6:38 PM, Dan Haywood 
 d...@haywood-associates.co.uk
  
  wrote:
 
   You are right, they will be displayed as links; there's no way to
 disable
   it currently.
  
   We could add a bit of metadata perhaps for this, eg
   @DomainObjectLayout(suppressLink=true) or similar.
  
   Please raise a ticket.
  
 
  OK https://issues.apache.org/jira/browse/ISIS-1180
 
  
   Thx
   Dan
  
   PS: these entities wouldn't be value types, rather regular entities.
 But
   

Re: Ideas for online forms application.

[David Tildesley]

Thanks Stephen, I have been doing a little research around XForms and had a 
play with Orbeon. I'll look into it more.
Regards,David.  


 On Tuesday, 28 July 2015 8:15 PM, Stephen Cameron 
steve.cameron...@gmail.com wrote:
   

 Hi David,

My two bits worth, I think Apache Isis is the last thing i would use for this 
kind of a task. If the information collected is that complex, then trying to 
fit in into a relational database via an object model makes no sense. Just use 
an XML database and XForms. 

There are server-side implementations of XForms that work well, namely Orbeon 
and BetterForms, if you want to hide the declarative form logic from users. 

For me, its Isis for behaviour and XForms/XQuery for complex data, both are 
efficient in their domains of specialisation. 

Where the boundary lies is an interesting puzzle to me. There is paper that 
myself and another wrote, somewhat on this contrast, here [1].

XForms is efficient as all the complexity that you describe can be done 
declaratively via XPath predicates [2]. That said, there is no validating 
compiler, so refactoring is a pain for example. Joeron's suggestion of two 
domain models might be alluding to that perhaps? But subforms do provide a 
means to manage this.

Finally, XForms can be fun too, see [3]

Cheers
Steve Cameron

[1] 
http://www.balisage.net/Proceedings/vol10/html/Velasquez01/BalisageVol10-Velasquez01.html
[2] http://lib.tkk.fi/Diss/2007/isbn9789512285662/article3.pdf
[3] 
http://exist-db.org/exist/apps/XSLTForms-Demo/modules/form.xq?form=tic-tac-toe.xml



On Sun, Jul 26, 2015 at 11:38 AM, David Tildesley davo...@yahoo.co.nz wrote:

Hi,
I am looking for some ideas around how ISIS could be helpful in the following 
Use Case. N.B. For non-disclosure reasons, I have to mask the real problem 
domain however at the same time try and give you a sense of what it all about 
and the degree of complexity.
UC1. Apply for 'XYZ'
N.B. 'XYZ' in truth has many variations ('XYZa, XYZb, XYZc, ...) which differ 
substantially in the information that must be collected from the Applicant(s). 
There is only a very small subset of information that is common.
1. The Applicant(s) (individual(s)) core details (name, contact details, dob, 
identity document number, ...). Depending on the type of 'XYZ' a very large set 
of additional information about these parties must be collected (e.g. 
educational qualifications, military history, job history, ...)2. Depending on 
the type of 'XYZ' and the answers to previous questions, information about 
other Parties (Organisation or Individual) must be collected.3. The system 
needs to be reactive to the user input. The user should only be presented with 
the relevant forms question/input that comply with the rules for the 'XYZ' type 
and context (their answers to previous questions that may trigger another set 
of questions).4. The system should group questions into multiple input forms 
rather than have one large form.5. The system should allow the user to 
navigate between the collection of forms until the OK to submit rule is 
satisfied, only displaying the relevant form questions for the 'XYZ' type and 
context.
There over 1500 information elements in the superset and it is likely that even 
for the simplest 'XYZ' type (single party), at least 50 information elements 
will be required. There will be collections in some cases (e.g. job history).
The rules while many, are not complex (no calculations) and focused around If 
the user answered yes to this question then ask them to complete another 
section of information. Some rules will apply to multiple 'XYZ' types. I 
ISIS allows us to hide/unhide, enable/disable properties, objects, etc. 
dynamically. It's just a question of the rules. Coding the rules would be 
difficult to maintain because of the size of the data set and the number of 
'XYZ' types (About 10 main types, with each type having several variations).
From a domain model perspective, there is :
A Party component which has Party details, Party relationships, contact 
details. fairly standard stuff
A XyzApplication Lodgement component that is centered around a 
Moment-Interval archetype called XyzApplication which as you might guess, has 
a large number of MI-Detail class/object (e.g. JobHistory). And it has a large 
number of Role archetype class/object that are roles played by Party wrt 
XyzApplication. 
Any thoughts on how and what for the rules management and present smart form 
would be appreciated. 
N.B If you think you might like to answer this, there is no urgency for 
answers - if I don't see anything for a few weeks, I will try again :)
Regards,David. 
 




  

Re: Ideas for online forms application.

[David Tildesley]

Hi Jeroen,
Thanks for the reply - I'll look into those ideas :-)
Cheers,David. 


 On Tuesday, 28 July 2015 10:15 AM, Jeroen van der Wal 
jer...@stromboli.it wrote:
   

 Hi David,

About 10 years ago I wrote an application that acted as a data maintenance
front-end for SAP. It was similar in scale: ~1600 unique information
elements that a application manager could use to assemble (sub) forms.
There was a state machine which handled workflow and visibility of (sub)
forms. It could easily act as advanced survey application too. I used Lotus
Notes as the backend which generated XForms for the client side.

Now if I decided to rebuild that application in Apache Isis I would create
two domains: one that contains the core entities of the business: customer,
user, application, etc and another domain which represents dynamical forms:
field, collection, subform, form, rule, etc.

The toughest part is the representation. When an Apache Isis application
starts it inspects the domain and builds a metamodel of that. A viewer,
wicket or RO, transforms that into HTLM or JSON. In this case the domain
objects are dynamic so the metamodel information cannot be created upfront.
But it might be possible to create it on the fly based on the defined rules
and give the viewer a generated pojo to store the collected data in [1]. As
far as I know there is currently no formal API to read en write to the
metamodel. Dynamic forms might be a good use case to create one.

HTH

Cheers,

Jeroen


[1]
http://blog.javaforge.net/post/31913732423/howto-create-java-pojo-at-runtime-with-javassist

















On 26 July 2015 at 03:38, David Tildesley davo...@yahoo.co.nz wrote:

 Hi,
 I am looking for some ideas around how ISIS could be helpful in the
 following Use Case. N.B. For non-disclosure reasons, I have to mask the
 real problem domain however at the same time try and give you a sense of
 what it all about and the degree of complexity.
 UC1. Apply for 'XYZ'
 N.B. 'XYZ' in truth has many variations ('XYZa, XYZb, XYZc, ...) which
 differ substantially in the information that must be collected from the
 Applicant(s). There is only a very small subset of information that is
 common.
 1. The Applicant(s) (individual(s)) core details (name, contact details,
 dob, identity document number, ...). Depending on the type of 'XYZ' a very
 large set of additional information about these parties must be collected
 (e.g. educational qualifications, military history, job history, ...)2.
 Depending on the type of 'XYZ' and the answers to previous questions,
 information about other Parties (Organisation or Individual) must be
 collected.3. The system needs to be reactive to the user input. The user
 should only be presented with the relevant forms question/input that comply
 with the rules for the 'XYZ' type and context (their answers to previous
 questions that may trigger another set of questions).4. The system should
 group questions into multiple input forms rather than have one large
 form.5. The system should allow the user to navigate between the
 collection of forms until the OK to submit rule is satisfied, only
 displaying the relevant form questions for the 'XYZ' type and context.
 There over 1500 information elements in the superset and it is likely that
 even for the simplest 'XYZ' type (single party), at least 50 information
 elements will be required. There will be collections in some cases (e.g.
 job history).
 The rules while many, are not complex (no calculations) and focused around
 If the user answered yes to this question then ask them to complete
 another section of information. Some rules will apply to multiple 'XYZ'
 types. I
 ISIS allows us to hide/unhide, enable/disable properties, objects, etc.
 dynamically. It's just a question of the rules. Coding the rules would be
 difficult to maintain because of the size of the data set and the number of
 'XYZ' types (About 10 main types, with each type having several variations).
 From a domain model perspective, there is :
 A Party component which has Party details, Party relationships, contact
 details. fairly standard stuff
 A XyzApplication Lodgement component that is centered around a
 Moment-Interval archetype called XyzApplication which as you might guess,
 has a large number of MI-Detail class/object (e.g. JobHistory). And it has
 a large number of Role archetype class/object that are roles played by
 Party wrt XyzApplication.
 Any thoughts on how and what for the rules management and present smart
 form would be appreciated.
 N.B If you think you might like to answer this, there is no urgency for
 answers - if I don't see anything for a few weeks, I will try again :)
 Regards,David.




   

Ideas for online forms application.

[David Tildesley]

Hi,
I am looking for some ideas around how ISIS could be helpful in the following 
Use Case. N.B. For non-disclosure reasons, I have to mask the real problem 
domain however at the same time try and give you a sense of what it all about 
and the degree of complexity.
UC1. Apply for 'XYZ'
N.B. 'XYZ' in truth has many variations ('XYZa, XYZb, XYZc, ...) which differ 
substantially in the information that must be collected from the Applicant(s). 
There is only a very small subset of information that is common.
1. The Applicant(s) (individual(s)) core details (name, contact details, dob, 
identity document number, ...). Depending on the type of 'XYZ' a very large set 
of additional information about these parties must be collected (e.g. 
educational qualifications, military history, job history, ...)2. Depending on 
the type of 'XYZ' and the answers to previous questions, information about 
other Parties (Organisation or Individual) must be collected.3. The system 
needs to be reactive to the user input. The user should only be presented with 
the relevant forms question/input that comply with the rules for the 'XYZ' type 
and context (their answers to previous questions that may trigger another set 
of questions).4. The system should group questions into multiple input forms 
rather than have one large form.5. The system should allow the user to 
navigate between the collection of forms until the OK to submit rule is 
satisfied, only displaying the relevant form questions for the 'XYZ' type and 
context.
There over 1500 information elements in the superset and it is likely that even 
for the simplest 'XYZ' type (single party), at least 50 information elements 
will be required. There will be collections in some cases (e.g. job history).
The rules while many, are not complex (no calculations) and focused around If 
the user answered yes to this question then ask them to complete another 
section of information. Some rules will apply to multiple 'XYZ' types. I 
ISIS allows us to hide/unhide, enable/disable properties, objects, etc. 
dynamically. It's just a question of the rules. Coding the rules would be 
difficult to maintain because of the size of the data set and the number of 
'XYZ' types (About 10 main types, with each type having several variations).
From a domain model perspective, there is :
A Party component which has Party details, Party relationships, contact 
details. fairly standard stuff
A XyzApplication Lodgement component that is centered around a 
Moment-Interval archetype called XyzApplication which as you might guess, has 
a large number of MI-Detail class/object (e.g. JobHistory). And it has a large 
number of Role archetype class/object that are roles played by Party wrt 
XyzApplication. 
Any thoughts on how and what for the rules management and present smart form 
would be appreciated. 
N.B If you think you might like to answer this, there is no urgency for 
answers - if I don't see anything for a few weeks, I will try again :)
Regards,David. 
 

Re: Accessing ISIS Domain Services via EJB

[David Tildesley]

Hi David,
When you say via EJB do you mean that you want to front end ISIS 
application with session beans and invoke those from another application via 
remote EJB invocation? 
Are you are saying that you want to do that just because you want to avoid 
having to learn REST/Json? 
Or you are thinking you need to expose some coarse grained services via session 
beans as opposed to having to deal with the fine grained RO that would be the 
case if you didn't make use of ISIS View objects?  
Have you considered using using ISIS View objects (a view over the Domain 
layer) to achieve a coarse grained RO interface to match the granularity that 
you need? 
Or is it the case that you are required to wrap and use remote EJB invocation 
to enlist the ISIS based application service in a distributed managed 
transaction? But presumably because you were already considering using the RO 
interface, then this is not a requirement?
I think more information about your architecture constraints and requirements 
is needed.
Regards.David.

 On Friday, 24 July 2015 7:52 AM, David Harrison dharri...@psionline.com 
wrote:
   

 
Hello,

We are interested in integrating Apache ISIS Domain Services (and Domain 
Objects)  in an existing application architecture, via EJB.  We briefly 
investigated using the RESTful interface, but the HATEOAS (hypertext as the 
engine of application state) style of interacting with ISIS was a bit more 
involved than we feel comfortable using as this point in time.

Is there a way to access ISIS Domain Services via EJB ?

If someone can point me (and my colleagues) in the right direction, we would be 
grateful.

Best Regards,
David Harrison and Ashwin Shimpi

Environment:
Apache Tomee 1.6.2  and EJB 3
OpenJDK Java 1.8.0
Apache ISIS - latest version,  1.8.0


  

Re: Reworked website, with new user guide and reference guide

[David Tildesley]

That's great documentation Dan. Thanks!
Kind Regards,
David. 


 On Tuesday, 16 June 2015 6:49 PM, Dan Haywood 
d...@haywood-associates.co.uk wrote:
   

 Hi folks,

Over the last month or so I've been reworking the Isis website, to:

- consolidate our how-to documentation into a comprehensive user guide [1]
- provide a corresponding reference guide [2]
- rework from Markdown to Asciidoctor

I've pushed the updated site this morning.  The home page [3] is
substantially the same, but the documentation page [4] has been overhauled
and simplified with big prominent buttons to the two new guides.

So you know, these guides do reference some feature in 1.9.0-SNAPSHOT, so
if you are working on 1.8.0 and can't find something that's discussed,
that'll be why.  (Releasing 1.9.0 is the next thing on my todo list).

The guides are mostly complete, though there are still some placeholders
here and there.  I decided to release them in their current state because
even slightly unfinished I think they are far better than what we had
before.

Feedback welcome, as ever.

Thx
Dan

PS: The source for all this is in our git repo [5], and can be built
locally [6].  Pull requests welcome!
PPS: if you don't see any changes, then force reload of the page (ctrl-R or
similar).

[1] http://isis.apache.org/guides/ug.html
[2] http://isis.apache.org/guides/rg.html
[3] http://isis.apache.org/
[4] http://isis.apache.org/documentation.html
[5]
https://github.com/apache/isis/tree/master/adocs/documentation/src/main/asciidoc
[6] https://github.com/apache/isis/tree/master/adocs/documentation/README.md


  

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]

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: d...@isis.apache.org; users@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: Web-App with ISIS usings a (Soap) WebService (no persistence)

[David Tildesley]

Hi Dan, Ged,

No, unfortunately this wasn't pursued. However we did go down the view object 
track for a simple backend ws integration. 
Augustinus has touched on the same issue - ISIS domain should be capable of 
having non-locally persisted domain  objects that can save or have data 
injected via DI via a system integration layer.

Regards,
David.
Sent from Yahoo Mail on Android

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

Re: IsisCon 2014, 6-7 June, Milan Italy

[David Tildesley]

Would love to come but I live on the other side of the world. Hope it goes well.

David.
On Friday, 28 March 2014 12:42 AM, Dan Haywood d...@haywood-associates.co.uk 
wrote:
 
Just a further reminder that we would love to have a couple of members of
the user community along to meet with us in Milan in June.  We expect there
to be 4 or 5 committers at the meet; all other things being equal, we'll
just have a great time discussing Isis and generally hanging out with each
other.

But if you can make it to Italy for either one or both of the days, we'd
love to meet you.

Cheers
Dan



On 15 March 2014 21:00, Jeroen van der Wal jer...@stromboli.it wrote:

 IsisCon 2014 is the first open conference dedicated to Apache Isis. It
 will take place on Friday 6  Saturday 7 June in Milan, Italy. IsisCon is
 a unique opportunity to meet the committers, learn from experts, share
 experiences and discus the future of Apache Isis.

 We appreciate your attendance but you can also participate. We'll run the
 conference as an open conference and self-organize the sessions at the
 beginning of each day. Feel free to propose talks, discussion subjects or
 whatever you feel should be covered during those days; we have put all
 ideas in preparation on the conference wiki page [1].

 You can register by replying to this e-mail. Further details can be found
 on the wiki page [1].

 The Apache Isis team is looking forward to see you in Milan!

 [1] https://cwiki.apache.org/confluence/display/ISIS/IsisCon+2014

 [image: Inline image 1]

Re: New screencast on bulk updates using the Excel domain service

[David Tildesley]

Nice work  :) . Looking forward to 1.4.0 also.



On Monday, 17 February 2014 4:52 AM, Dan Haywood 
d...@haywood-associates.co.uk wrote:
 
Hi folks,

just a heads-up that the Isis website now contains a new page and
screencast [1] showing how Estatio [2] uses the Excel domainservice [3]
that I recently put together.

I've also updated some of the existing pages which have screencasts for
them, and updated the main documentation page [4] so it is easier (through
a little icon) to see which pages have screencasts on them.

Any feedback (positive or negative) let me know

Cheers
Dan

PS: hoping to do a 1.4.0 release this coming week.


[1]
http://isis.apache.org/reference/services/third-party/danhaywood-isis-domainservice-excel.html
[2] https://github.com/estatio/estatio
[3] https://github.com/danhaywood/isis-domainservice-excel
[4] http://isis.apache.org/documentation.html

OWASP vulnerability test results

[David Tildesley]

Hi,

Good news: sonar owasp plugin picked up only 4 vulnerabilities (of 97 active 
OWASP rules) and overall 0.1% OWASP risk factor score (the app under test based 
on 1.3.0 ISIS core and 1.3.1 wicket viewer) and those vulnerabilities may be 
attributable to the business code we wrote rather than ISIS core. Can't say any 
more than that so please don't ask. 


Similarly I ran an out of the box Arachni pen test (anonymous only) and it 
didn't pick up anything of note that wasn't caused by our own implemention


However my advice is to always run your own tests - don't rely on the 
assertions of others but at least you may draw some comfort in terms of making 
an investment with ISIS (and Wicket etc) that it is unlikely to let you down in 
this area.

David.

Re: How can I search for an entity using the OID

[David Tildesley]

I'm interested in the answer to that also.

David.



On Sunday, 17 November 2013 8:50 AM, james agada okwuiag...@gmail.com wrote:
 
When creating a view model, I am retrieving the OID of a referenced entity.
Is it possible to retrieve an entity with just the OID which is usually an
integer

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

Re: Views and view models

[David Tildesley]

Hi Jeroen,

Out of curiosity, what was the driver for using a database view instead of 
calling the behaviour on the domain layer to get the information for the view 
model? Performance?

David.



On Tuesday, 12 November 2013 1:09 AM, Jeroen van der Wal jer...@stromboli.it 
wrote:
 
To answer questions 1 and 2: the Estatio codebase has two examples of a
viewmodel using a database view [1]. Haven't worked with Jasper Reports
myself, perhaps others have?

[1]
https://github.com/estatio/estatio/tree/master/dom/src/main/java/org/estatio/dom/invoice/viewmodel



On Sun, Nov 10, 2013 at 11:47 PM, james agada okwuiag...@gmail.com wrote:

 I want to use view models. The documentation is a bit scanty and the todo
 view model and how it is used is difficult for me to comprehend.
 1. Can I define views at database level and map it to a view model? If so,
 a small example will do.
 2. Is there a better documented example of using view models for instance
 for reports.
 3. Is there a way to integrate something like jasper report to isis?

Re: Shiro with JdbcRealm

[David Tildesley]

I suggest you remove the [users] and [roles] sections from the ini file as they 
are not needed for your purpose and from memory there is some side-effect from 
leaving them in place when not using the iniRealm. It would be useful to see 
the other tables as well.

David.




On Monday, 11 November 2013 3:16 AM, james agada okwuiag...@gmail.com wrote:
 
I have struggled with this for some time and i still cannot get the
behaviour right. Now, it is only a permission of * that works. Anyother
permission and the user cannot see the menu or dashboard. I also have to
shut down and restart before any permission changes or user definitions
take effect.

Here is the shiro.ini

#

# Licensed to the Apache Software Foundation (ASF) under one

# or more contributor license agreements.  See the NOTICE file

# distributed with this work for additional information

# regarding copyright ownership.  The ASF licenses this file

# to you under the Apache License, Version 2.0 (the

# License); you may not use this file except in compliance

# with the License.  You may obtain a copy of the License at

#

#    http://www.apache.org/licenses/LICENSE-2.0

#

# Unless required by applicable law or agreed to in writing,

# software distributed under the License is distributed on an

# AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY

# KIND, either express or implied.  See the License for the

# specific language governing permissions and limitations

# under the License.

#


[main]

ps = org.apache.shiro.authc.credential.DefaultPasswordService

pm = org.apache.shiro.authc.credential.PasswordMatcher

pm.passwordService = $ps


aa = org.apache.shiro.authc.credential.AllowAllCredentialsMatcher

sm = org.apache.shiro.authc.credential.SimpleCredentialsMatcher


ds = com.jolbox.bonecp.BoneCPDataSource

ds.driverClass = com.mysql.jdbc.Driver

ds.jdbcUrl = jdbc:mysql://localhost:3306/myticket

ds.username = root

#ds.password =  .

jdbcRealm.dataSource = $ds


jdbcRealm = org.apache.shiro.realm.jdbc.JdbcRealm

jdbcRealm.permissionsLookupEnabled = true

jdbcRealm.credentialsMatcher = $sm

builtInCacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager



jdbcRealm.dataSource = $ds


jdbcRealm.authenticationQuery = SELECT password FROM user WHERE name = ?

jdbcRealm.userRolesQuery = SELECT role.name AS role_name FROM user,userroles,
role WHERE  user.user_id = userroles.userid AND userroles.roleid =
role.role_id AND user.name = ?

jdbcRealm.permissionsQuery = SELECT permission.permission AS roleper FROM
role, permission, rolepermissions WHERE rolepermissions.roleid=role.role_id
AND rolepermissions.permissionid = permission.permission_id AND role.name =
?

securityManager.realms = $jdbcRealm

securityManager.cacheManager = $builtInCacheManager

# to use .ini file

#securityManager.realms = $iniRealm




#
-

# Users and their assigned roles

#

# Each line conforms to the format defined in the

# org.apache.shiro.realm.text.TextConfigurationRealm#setUserDefinitions
JavaDoc

#
-


[users]

# user = password, role1, role2, role3, ...



sven = pass, admin_role

dick = pass, user_role, self-install_role

bob  = pass, user_role, self-install_role

joe  = pass, user_role, self-install_role

guest = guest, user_role




#
-

# Roles with assigned permissions

#

# Each line conforms to the format defined in the

# org.apache.shiro.realm.text.TextConfigurationRealm#setRoleDefinitions
JavaDoc

#
-


[roles]

# role = perm1, perm2, perm3, ...

# perm in format: packageName:className:memberName:r,w


user_role =   *:ToDoItemsJdo:*:*,\

              *:ToDoItem:*:*

self-install_role = *:ToDoItemsFixturesService:install:*

admin_role = *


***
Here is the permission table
PERMISSION_ID,DESCRIPTION,NAME,OWNEDBY,PERMISSION,VERSION
1,Create Users,CreateUser,sven,*:ToDoItemsFixturesService:install:*,7
2,View Existing Users,ViewUsers,sven,*:User:*:r,2
3,Root access,ROOT,sven,*,1
4,Setup inventory,SetupInventory,sven,*:Inventory:*:r,w,1
5,todo,TODO,sven,*:Parties:*:*,3



On Fri, Oct 25, 2013 at 3:27 AM, David Tildesley davo...@yahoo.co.nzwrote:

 Copy us the whole shiro.ini file (blank out any sensitive connection info).


 David.



 
  From: james agada okwuiag...@gmail.com
 To: users@isis.apache.org users@isis.apache.org
 Sent: Friday, 25 October 2013 9:23 AM
 Subject: Shiro with JdbcRealm


 I have been able to setup shire to use a jdbcrealm and authenticate against
 the database. However, it does not appear to use the permissions. I want to
 set a role to have permissions only to run the ToDoItems fixture service
 and I give the permission as so  *:ToDoItemsFixturesService:install:*. But
 the user

Publish and Audit service questions

[David Tildesley]

Hi All,

Audit service is missing one important item of information - the name of the 
attribute for the value that changed.

Publishing service doesn't provide the previous value and so this doesn't 
provide an alternative to address the point above.

Apart from framework changes (happy to raise a Jira) , what else can we do in 
the  meantime to override either Audit or Publishing service behavior?

Thanks,
David.

Re: Publish and Audit service questions

[David Tildesley]

Hi Dan,

Magic. Thanks very much for your quick reply. :)

Regards,
David.




On Thursday, 7 November 2013 10:19 AM, Dan Haywood 
d...@haywood-associates.co.uk wrote:
 
Hi David,
I noticed this (quite) recently also.

The AuditService2 interface adds in the missing attribute.  If the audit
service implements AuditService2 rather than the original AuditService,
then the overloaded version of audit(...) will be called that provides the
missing parameter.

All of the above was in the recent v1.3.0 release.

Let me know if that doesn't work for you.

Cheers
Dan




On 6 November 2013 21:57, David Tildesley davo...@yahoo.co.nz wrote:

 Hi All,

 Audit service is missing one important item of information - the name of
 the attribute for the value that changed.

 Publishing service doesn't provide the previous value and so this
 doesn't provide an alternative to address the point above.

 Apart from framework changes (happy to raise a Jira) , what else can we do
 in the  meantime to override either Audit or Publishing service behavior?

 Thanks,
 David.

Re: [ANN] Apache Isis version 1.3.0 and other components Released

[David Tildesley]

Congratulations to the team. The new features look great. I'm in awe of what 
you have achieved.

David.

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 users@isis.apache.org 
Cc: dev d...@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 

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: users@isis.apache.org users@isis.apache.org 
Cc: dev d...@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: users@isis.apache.org; David Tildesley davo...@yahoo.co.nz 
Cc: dev d...@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: Performance and scalability

[David Tildesley]

I'm not sure what your agenda is Mr Agada, however I can assure you that, from 
our experience  ISIS is not just a prototyping tool and we have put our 
application that uses ISIS through informal performance testing and we are 
confident. It is just that our application release one is batch driven use 
cases (which by the way have excellent performance driving updates through the 
ISIS DOM based domain logic) but only one (wicket viewer) human user (an 
admin), while our release two is planned to have a concurrency of 200 (wicket 
viewer) users with a high amount of query traffic compared with update traffic 
where we will be doing formal performance testing (which by the way is an 
expensive exercise).

You should know that even very large vendors don't publish performance figures 
for their frameworks and certainly don't publish performance comparison 
benchmarks with competing frameworks, commercial or otherwise. Performance 
figures can be skewed by favoring certain use cases over others.

I suggest you adopt a less accusatory tone and do your own performance 
benchmarking because at the end of day that is the only way you are going to 
answer your question to your own satisfaction.

David.



 From: james agada okwuiag...@gmail.com
To: users@isis.apache.org users@isis.apache.org 
Sent: Saturday, 17 August 2013 9:06 PM
Subject: Re: Performance and scalability
 

It should be on your priority except Isis will just be a prototyping tool.

Sent from my iPhone

On Aug 17, 2013, at 1:31 AM, David Tildesley davo...@yahoo.co.nz wrote:

 Performance testing our ISIS (RO, Wicket viewer) based application is on our 
 backlog to do soon, however we haven't started yet - mainly because it is not 
 a significant risk for our first release.

 Regards,
 David.


 
 From: Dan Haywood d...@haywood-associates.co.uk
 To: users users@isis.apache.org
 Sent: Saturday, 17 August 2013 3:08 AM
 Subject: Re: Performance and scalability


 Not yet.  It is something I intend to do in developing Estatio, though it's
 possible that others here (David?), might do look into this first.

 I would expect that the RO viewer would scale further than the Wicket
 viewer, because the former is stateless, the latter (due to Wicket's
 architecture) is not.

 Dan



 On 16 August 2013 16:06, james agada okwuiag...@gmail.com wrote:

 Does anyone have any experience and/or benchmarks and/or guides for Isis
 performance and scalability with wicketviewer or with the restfulobject
 viewer?

Re: Performance and scalability

[David Tildesley]

Performance testing our ISIS (RO, Wicket viewer) based application is on our 
backlog to do soon, however we haven't started yet - mainly because it is not a 
significant risk for our first release.

Regards,
David.



 From: Dan Haywood d...@haywood-associates.co.uk
To: users users@isis.apache.org 
Sent: Saturday, 17 August 2013 3:08 AM
Subject: Re: Performance and scalability
 

Not yet.  It is something I intend to do in developing Estatio, though it's
possible that others here (David?), might do look into this first.

I would expect that the RO viewer would scale further than the Wicket
viewer, because the former is stateless, the latter (due to Wicket's
architecture) is not.

Dan



On 16 August 2013 16:06, james agada okwuiag...@gmail.com wrote:

 Does anyone have any experience and/or benchmarks and/or guides for Isis
 performance and scalability with wicketviewer or with the restfulobject
 viewer?

Re: rules externalised from the code

[David Tildesley]

Dan Haywood wrote:


 Even though you say you don't want to think of this in terms of security,
 it does feel like a security concern to me... at least insofar that
 addRole(user, securityRole) implies access to specific functionality?

Hi Dan,

I think you have misunderstood - the security roles have nothing to do with the 
application that manages them. They are roles for other applications and IT 
resources. The business domain for the application in this case is Role Based 
Access Control Management.

The rest of your post however is interesting from an entirely different subject 
and we have a need to do something like this for Maintain my details function.

Thanks,
David.

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: users@isis.apache.org 
Cc: dev d...@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 

rules externalised from the code

[David Tildesley]

Hi,

We are looking at building a RBAC capability that evaluates security 
entitlements for users. The business rule to determine an effective role may be 
based on a combination of the users attributes. e.g. job title, organisation 
unit, location, organisation. The rules are not going to be all that 
complicated e.g.

if ((user.jobTitle.name == case worker)) AND (user.org.name == companyA) 
AND (user.location.code == NY)) then
    addRole(user, securityRole)

but we don't want to have to recompile the application each time a rule changes 
or a rule is added or removed.

Options? e.g. DROOLS rule engine (seems a bit too heavy weight for what we want 
to achieve).

In our case the application is built using ISIS and already contains a domain 
that has all the HR context required for RBAC determinations. i.e. a full 
object graph containing all the input information to the RBAC rule would be 
available.The solution would need to fit nicely with ISIS.


Any ideas would be appreciated.

N.B. do not get confused with Shiro security for the application - that's 
orthogonal to the functional capability that we are wanting to build.And yes, I 
know we can go and buy specialized products that do this functional capability 
but we have good reasons for not going down that path.


Thanks in advance,
David.

Allow the user to choose a role to work within that role context.

[David Tildesley]

Hi,

A question. A user may have a number of roles when using  ISIS (i.e. 
org.apache.isis.security.UserMemento has a list of roles  1). How hard would 
it be to let the user choose which role they want to use for the session.

The story:

1. As an administrator of the application I am also a normal user of the 
application and I would like to see the reduced view of the application that 
a normal user would see by choosing my normal user role to be used in the 
session.

Any ideas/ pointers would be appreciated.

Thanks,
David.

Re: rules externalised from the code

[David Tildesley]

Would JDO query be a candidate (assuming the query text can be associated with 
an object and loaded from a persistent source at run-time and then executed)?

Regards,
David.




 From: David Tildesley davo...@yahoo.co.nz
To: users users@isis.apache.org 
Sent: Wednesday, 7 August 2013 6:44 PM
Subject: rules externalised from the code
 

Hi,

We are looking at building a RBAC capability that evaluates security 
entitlements for users. The business rule to determine an effective role may be 
based on a combination of the users attributes. e.g. job title, organisation 
unit, location, organisation. The rules are not going to be all that 
complicated e.g.

if ((user.jobTitle.name == case worker)) AND (user.org.name == companyA) 
AND (user.location.code == NY)) then
    addRole(user, securityRole)

but we don't want to have to recompile the application each time a rule changes 
or a rule is added or removed.

Options? e.g. DROOLS rule engine (seems a bit too heavy weight for what we want 
to achieve).

In our case the application is built using ISIS and already contains a domain 
that has all the HR context required for RBAC determinations. i.e. a full 
object graph containing all the input information to the RBAC rule would be 
available.The solution would need to fit nicely with ISIS.


Any ideas would be appreciated.

N.B. do not get confused with Shiro security for the application - that's 
orthogonal to the functional capability that we are wanting to build.And yes, I 
know we can go and buy specialized products that do this functional capability 
but we have good reasons for not going down that path.


Thanks in advance,
David.

Re: rules externalised from the code

[David Tildesley]

Hi Oscar,
Thanks. That's handy. We'll explore that new feature.

Cheers,
David.

Sent from Yahoo! Mail on Android

Re: Transaction Handling

[David Tildesley]

Hi Okwui,

This is trivial - it's business rule driven (encapsulated in (dom) business 
object method code) and can be done in the normal ISIS transaction lifecycle. 
Nothing special.

Regards,
David.





 From: Okwui okwuiag...@gmail.com
To: users@isis.apache.org users@isis.apache.org 
Cc: users@isis.apache.org users@isis.apache.org 
Sent: Monday, 22 July 2013 8:16 PM
Subject: Re: Transaction Handling
 

Consider this use case:
I have an inventory transaction that transfers goods from one warehouse to 
another. I need to increase inventory in receiving location and decrease 
inventory in issuing location. Each location has a stock ledger entity. I want 
the increase in receiving stock ledger entity quantityAtHand and the decrease 
in the issuing stock ledger entity quantityAtHand to be handled as one 
transaction ie succeed or fail together. And this happens programmatically as 
part of the lifecycle of the transaction entity.

Sent from my iPad

On Jul 20, 2013, at 10:07 PM, David Tildesley davo...@yahoo.co.nz wrote:

 Hi O.  would be easier to answer your question if you described your use 
 case.  If it is just single database  persistence I would question why you 
 would want to do this in the first place. But anyway, I don't see any reason 
 why you couldn't detach your business objects using jdo detachable, work on 
 them, and when you are ready to save, call your custom operation to reattach 
 and persist (the viewer will do the transaction)..
 
 But  I'm not a developer, I'm an architect so you will need some further 
 advice on this. 
 
 David.
 
 Sent from Yahoo! Mail on Android
 

Re: Microsoft CRM as a reference architecture (part 2)

[David Tildesley]

I should add to this because someone will point out the seemingly obvious:

Why not call the generated restful objects API?

The RO API that is generated reflects the domain behaviour.

Generally when providing a service to a service consumer(s)
 you are doing a lot of aggregation of fine-grained domain behaviour to
coarse-grained service behaviour  on a large non-OO information model.

And so you would naturally gravitate to the same method 
as described in my post below and end up with UI objects that do 
the coarse-grained aggregation of behaviour and data 
but also implement ISIS services so that their (coarse-grained) 
RO API get's presented for the service consumer(s).

btw, in our use cases, with processing the files and staging tables, using the 
RO API was pointless because
the service consumers are in the same application and java to java is far more
efficient and you get atomic transaction behaviour as part of the bargain.

David.
 



 From: David Tildesley davo...@yahoo.co.nz
To: users@isis.apache.org users@isis.apache.org 
Sent: Sunday, 30 June 2013 8:32 AM
Subject: Re: Microsoft CRM as a reference architecture (part 2)
 

Hi Oscar, Dan,

We've successfully used Quartz and Apache Camel in an application using ISIS. 
I had a conversation on this list with Dan a few months back about calling the 
ISIS domain 
from what is effectively a non-human oriented UI layer.
We separated out the UI layer objects from the domain layer objects via 
packaging.
I would like to see a more enforced separation - I'm not sure how to go about 
it though. 
The aim is to maintain separation of concerns and thereby protect the rich 
domain as per this app layer pattern:

UI -- Rich Domain --SI 

As Richard Pawson said in his replies to comments in that same blog:
 Use-case driven analysis leads to poor object modelling in my experience. My 
position on this is that use-cases should be used to validate the object model, 
not to identify it.

With a system oriented UI (could be invoked in any number of ways: soap web 
service, JMS message, ...) 
as with a human UI, the trick is not to allow bleeding of domain business logic 
in to the UI
and ensure that the domain never depends on the UI. This way, you can bolt on 
any number of UI's to the same domain layer.

While what we have done (using packaging) works, maybe there could be a better 
(ISIS) way of enforcing separation of concerns?
Also it would be very nice to be able to independently package up the domain 
layer, SI in separate jar for reuse in different application contexts.
(by doing this you are removing all doubt about where the layer concerns are)

btw, in our UI we are processing files (using Camel) triggered by a schedule 
event (quartz) and also (another use case) processing staging tables, 
calling domain business objects behaviour as required. 

David.





Oscar wrote: 


Really nice the wayback machine. I remember read about it quite time ago, but 
never used it... and works like a charm!

I didn't pretended to open a debate about the role of Workflows on DDD or 
NakedObjects. 
It was just an example of an infrastructure service provided by MS CRM that 
could be also a higher-level Infrastructure Service available on Isis.

My intention was to open a debate about the possibility that higher-level 
building blocks were also part of Isis, 
such as a collection of infrastructure level services (like Dan's Email 
Service, the Event Service recently
 commited by Dan, the publish-subscribe service, a Geographic Mapping Service 
 - available on different , 
the Workflow service, a generic interface to a SMS Service with 
implementations based on different providers - 
such as Twilio, or Apache Camel - useful in multiple uses cases  -, etc.).

...

Re: Using Apache ISIS with an XML database

[David Tildesley]

+1. Jeroen is exactly right. 



 From: Jeroen van der Wal jer...@stromboli.it
To: users@isis.apache.org 
Sent: Monday, 20 May 2013 11:35 PM
Subject: Re: Using Apache ISIS with an XML database
 

Hi Steve,

A few years back I developed an XRX application using eXistDB as a backend
and betterFORM as a frontend. That worked pretty well up to a CRUD level
but when we had to enrich the domain and add complex business rules the
architecture flawed. This is why I moved (back) to Java and more
specifically Apache Isis.

IMHO there is no such thing as a no-code solution. Expressing your logic in
XML is also coding and I would never do that in XML again, too much pain.
However XRX can be the right architecture when your application is in it's
sweetspot.

As Dan mentioned you can make Isis work with an XML store but I can't see
how you can generate Isis code from an XML schema without writing a parser
to do that.

If you provide more details about your application I'm happy to provide
more guidance.

Regards,
Jeroen





On Mon, May 20, 2013 at 11:58 AM, Dan Haywood
d...@haywood-associates.co.ukwrote:

 Hi Steve,
 Thanks for your interest in Apache Isis.

 This is definitely do-able, and is not actually that far removed from one
 of Isis' original goals, to have pluggable support for its components.

 In fact, there is an Isis XML objectstore - though not yet formally
 released - which you could use as a starting point.  It works by saving
 separate files in a folder, but I imagine it'd be easy to fork it and write
 it so that it stores all the files in a single big XML file.

 As an alternative (and, actually, one I'd recommend instead), you could use
 the JDO/DataNucleus objectstore, but then exploit DataNucleus's own
 pluggable DataStore API.

 There are a number of implementations; not just RDBMS, as you can see here
 [1].  And there is one that persists to XML [2], so you could explore that.

 I don't know how many people are actually using this DataNucleus API, but
 it is at least implemented and supported, so probably is a lower risk
 approach than rolling your own based on the Isis API.

 Let us know which approach you decide to take; happy to support you if
 possible.

 Cheers
 Dan

 PS: this enquiry probably lives better on the dev@isis.a.o list.

 [1] http://www.datanucleus.org/extensions/store_manager.html
 [2] http://www.datanucleus.org/products/datanucleus/datastores/xml.html



 On 20 May 2013 05:40, Stephen Cameron steve.cameron...@gmail.com wrote:

  Hi
 
  I am starting a project looking at how best to auto-generate a simple
 data
  gathering application.
 
  I'd like to drive it off an XML Schema document, I've made something
  reasonably good for a web interface using XForms and soon an XML database
  as a back-end, the so-called 'XRX architecture'.
 
  I've been reading the Naked Objects books and am interested to see what I
  can do in a similar way with Apache ISIS, both for the ISIS web and
 native
  Java viewers.
 
  One question I have is: can I make use of an XML database as the
  persistence layer easily? The idea here being that the application
  generates one big XML file, or an archive with multiple files, at the end
  of a period, and that gets submitted to a central XML database.
 
  I guess that the history of ISIS would suggest that this is a strange
 thing
  to do, as opposed to using a relational database. However, the method in
 my
  madness is that I'm effectively building a no-code solution, asI'm hoping
  all the ISIS java code can be generated.
 
  Thanks for your feedback
 
  Regards
  Steve Cameron
 

attribute level security externalised

[David Tildesley]

Hi all,

We are looking at the options for controlling which fields that a user in a 
particular role can edit in a way that can be externalized like in the way 
Shiro externalizes role based  authorization configuration for operations. Any 
thoughts/ ideas or pointing out of the error of our ways most appreciated.

Regards,
David. 

Re: Hi to all. Project introduction and some doubts

[David Tildesley]

Hi Dan,

We are building a corporate application using the ISIS framework as is (JDO, 
Wicket viewer) and it is going well. 

However the unfinished JUnit wrapper poses a problem for us in the long run. 
Keen to see it completed (that's a vote fromme).


Unfortunately I can't publish the source for this particular application as it 
is not mine.


Maybe port the Car Serv application from your book to ISIS ?

Regards,
David.


 With respect to the JUnit viewer, at the moment it focuses on testing the
 UI/domain interaction, and just using an in-memory objectstore.
 Separately, there is IsisSystemForTest [4], which can be used to bootstrap
 an Isis runtime for domain/DB integration (via the JDO objectstore)

 What I want to do is to combine these frameworks into a single JUnit
 framework, which allows domain/DB integration and optionally allows the
 full-stack UI/domain/DB integration too.   This is the main reason I
 haven't released the JUnit viewer yet since us becoming a TLP.

 With respect to the BDD viewer, I think this also needs to work the same
 way; and it probably should be made part of the same single framework.  So,
 then it's one integration testing stack for domain/DB testing, optionally
 testing the UI interaction through the existing JUnit viewer stuff or
 through the BDD viewer stuff.

layering question

[David Tildesley]

Hi,

Firstly, I would like to compliment the developers/ designers/ architects of 
Apache ISIS on a fine product using a great design pattern and framework (naked 
objects).

A question:

While ISIS goes a long way (more than any other framework) to corralling the 
developer of a business application to rich domain pattern, DDD, separation of 
concerns, etc. It doesn't prevent them from doing the wrong thing and reverting 
to type e.g. anaemic domain, business logic in a service layer or application 
layer.

DDD process derives a rich domain model from requirements including use cases. 
A UI layer should be disposable (in the case of ISIS, the cost of the UI layer 
is practically zero and so this is all good) and multiple independent UI layers 
should be able to depend on the problem domain (aka rich domain, business, 
...) layer (I'll shorten it to PD layer), and the  PD layer must never depend 
on the UI layer. So called service, application layers are conceptually in 
the UI layer. This should drive us to consideration of only 3 layers 
(discounting the data persistence which is more like a property these days).  
UI -- PD --SI  (the arrows indicate direction of dependency). SI stands for 
System integration. This is in line with the hexagonal view.

What I like about ISIS is the lowering of cost for the UI layer (generated 
restful objects service and human UI viewers).

So ... the question: in order to also lower the cost of building a use case 
specific UI layer (not intended for a generated viewer and I'm thinking of a 
coarse grained service), I'm thinking that you could still leverage the ISIS 
service generation. However to retain the separation of concern between the 
three layers would require some specific directions to the developer. Does it  
make sense to do reinforce the separate of the ISIS source for generation 
into 3 separate packages? and is this sufficient? e.g.:

(UI)   com.mycompany.myapp.ui.*
(PD)  com.mycompany.myapp.pd.*
(si)   com.mycompany.myapp.si.*

So if I wanted to auto-generate a (restful object) service which is coarse 
grained and serves a non-human user/consumer and orchestrates calls to the pd 
layer business objects then I would create a service object  in the UI layer 
package and make sure I don't leach business logic and behaviour that should be 
in the pd layer business objects into this object. And obviously hide it from 
the viewers.

Does this make sense? 

Regards,
David.