Return-Path: Delivered-To: apmail-incubator-isis-commits-archive@minotaur.apache.org Received: (qmail 29518 invoked from network); 16 Dec 2010 15:44:51 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 16 Dec 2010 15:44:51 -0000 Received: (qmail 52068 invoked by uid 500); 16 Dec 2010 15:44:51 -0000 Delivered-To: apmail-incubator-isis-commits-archive@incubator.apache.org Received: (qmail 52034 invoked by uid 500); 16 Dec 2010 15:44:50 -0000 Mailing-List: contact isis-commits-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: isis-dev@incubator.apache.org Delivered-To: mailing list isis-commits@incubator.apache.org Received: (qmail 52026 invoked by uid 99); 16 Dec 2010 15:44:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Dec 2010 15:44:50 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Dec 2010 15:44:46 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id 54BFC2388A43; Thu, 16 Dec 2010 15:44:25 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r1050012 - in /incubator/isis/trunk: applib/src/docbkx/guide/ core/src/docbkx/guide/ src/site/apt/TOREVIEW/ Date: Thu, 16 Dec 2010 15:44:25 -0000 To: isis-commits@incubator.apache.org From: danhaywood@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20101216154425.54BFC2388A43@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Author: danhaywood Date: Thu Dec 16 15:44:24 2010 New Revision: 1050012 URL: http://svn.apache.org/viewvc?rev=1050012&view=rev Log: moving some notes into isis-applib.xml (ISIS-21) Added: incubator/isis/trunk/src/site/apt/TOREVIEW/TODO_online-demo.apt - copied unchanged from r1049824, incubator/isis/trunk/src/site/apt/TOREVIEW/online-demo.apt Removed: incubator/isis/trunk/src/site/apt/TOREVIEW/gotchas.apt incubator/isis/trunk/src/site/apt/TOREVIEW/notes-on-profiles-via-commandline.apt incubator/isis/trunk/src/site/apt/TOREVIEW/online-demo.apt Modified: incubator/isis/trunk/applib/src/docbkx/guide/isis-applib.xml incubator/isis/trunk/core/src/docbkx/guide/isis-core.xml Modified: incubator/isis/trunk/applib/src/docbkx/guide/isis-applib.xml URL: http://svn.apache.org/viewvc/incubator/isis/trunk/applib/src/docbkx/guide/isis-applib.xml?rev=1050012&r1=1050011&r2=1050012&view=diff ============================================================================== --- incubator/isis/trunk/applib/src/docbkx/guide/isis-applib.xml (original) +++ incubator/isis/trunk/applib/src/docbkx/guide/isis-applib.xml Thu Dec 16 15:44:24 2010 @@ -70,7 +70,7 @@ Apache Isis application library (or applib), in order that the framework can correctly pick up and render the business rules and logic encoded within their - domain objects. + domain objects. @@ -4034,9 +4034,9 @@ isis.fixtures= ClaimsFixture,LogOnAsCliv <methodname>SwitchUserFixture</methodname> - The SwitchUserFixture provides an alternative to - AbstractFixture, just allowing the current - user to be switched. + The SwitchUserFixture provides an + alternative to AbstractFixture, just allowing + the current user to be switched. The main difference is one of style; SwitchUserFixture can be used in a @@ -4051,6 +4051,74 @@ isis.fixtures= ClaimsFixture,LogOnAsCliv A fixture in this style could then be used within a composite fixture hierarchy. + + + Do be aware of when you call switchUser() in a + Fixture as it causes the current + transaction to be ended and a new one started (for the new user). + If you share a reference between the two you will get an + exception. + + For example: + + Account account = accounts.createAccount( + "ACME", "Peter Planner", "pplanner@acme.com"); +Participant peterPlanner = account.getAdmin(); + +switchUser("pplanner@acme.com", new String[0]); + +Work work = plan1.createWork(); +BcpPlan plan = (BcpPlan) work.getTarget(); +plan.getOwner().modifyLeader(peterPlanner); + + This will fail because peterPlanner + reference is no longer valid after the switch user. + + The solution is to retrieve the object again so it is part + of the second transaction. In this example we can change to code + to this: + + accounts.createAccount("ACME", "Peter Planner", "pplanner@acme.com"); + +switchUser("pplanner@acme.com", new String[0]); + +Account account = uniqueMatch(Account.class, "0 ACME"); +Participant peterPlanner = account.getAdmin(); + +Work work = plan1.createWork(); +BcpPlan plan = (BcpPlan) work.getTarget(); +plan.getOwner().modifyLeader(peterPlanner); + + + + + Gotchas + + like this. The fixture code shared the + <<<Participant>>> object between the two + transactions when coded like this: +---------- Account account = + accounts.createAccount("ACME", "Peter Planner", + "pplanner@acme.com"); Participant peterPlanner = + account.getAdmin(); switchUser("pplanner@acme.com", new + String[0]); Work work = plan1.createWork(); BcpPlan plan = + (BcpPlan) work.getTarget(); + plan.getOwner().modifyLeader(peterPlanner); +---------- To resolve + the problem you will need to retrieve the object again so it is + part of the second transaction. In this example we can change to + code to this: +---------- accounts.createAccount("ACME", "Peter + Planner", "pplanner@acme.com"); switchUser("pplanner@acme.com", + new String[0]); Account account = uniqueMatch(Account.class, "0 + ACME"); Participant peterPlanner = account.getAdmin(); Work work = + plan1.createWork(); BcpPlan plan = (BcpPlan) work.getTarget(); + plan.getOwner().modifyLeader(peterPlanner); +---------- An + alternative is to force this separation by putting the switch call + into a separate fixture, as you now have no choice but to look it + up. * Deployment limitations of using switch user Switch user will + only work in exploration and prototype mode. To make it run on the + server (ie using Tomcat) I changed the deployment type by adding + the following to the isis.properties file: -------- + isis.deploymentType=prototype --------- + @@ -4764,7 +4832,7 @@ Element customerXsd = snapshot.getXsdEle In order to be recognized, all methods must be public. Any methods that do not match are deemed to be - action methods that the user can invoke from the user interface. + action methods that the user can invoke from the user interface. Modified: incubator/isis/trunk/core/src/docbkx/guide/isis-core.xml URL: http://svn.apache.org/viewvc/incubator/isis/trunk/core/src/docbkx/guide/isis-core.xml?rev=1050012&r1=1050011&r2=1050012&view=diff ============================================================================== --- incubator/isis/trunk/core/src/docbkx/guide/isis-core.xml (original) +++ incubator/isis/trunk/core/src/docbkx/guide/isis-core.xml Thu Dec 16 15:44:24 2010 @@ -4192,76 +4192,83 @@ Persistable: User Persistable behaviour it can offer, and to find other information such as the object's title, a suggested order of it fields, when the actions can or can't be used. The details about this interface are recorded in an - instance of ObjectSpecification. As each class of - domain object is loaded into the system introspection is performed and - an instance of ObjectSpecification is generated. That - specification object is subsequently available from any object adapter - (using the ObjectAdapter.getSpecification method) for + instance of ObjectSpecification. As each class + of domain object is loaded into the system introspection is performed + and an instance of ObjectSpecification is + generated. That specification object is subsequently available from + any object adapter (using the + ObjectAdapter.getSpecification method) for that type of domain object; or it can be retrieved directly, by name - or class, from the ObjectSpecificationLoader instance - (obtained from the Isis repository). - - Through an object's ObjectSpecification instance - the rest of the NOF can find out the fields that an object has, the - methods it offers, the title to use to identify the object, and other - details about the object. These are used normally used by the - implementations of ObjectAdapter etc when another component ask the - adapter for details about another object. For example For example the - statement adapter.getField(no.getFields()[0]) would + or class, from the ObjectSpecificationLoader + instance (obtained from the Isis + repository). + + Through an object's ObjectSpecification + instance the rest of the NOF can find out the fields that an object + has, the methods it offers, the title to use to identify the object, + and other details about the object. These are used normally used by + the implementations of ObjectAdapter etc when another component ask + the adapter for details about another object. For example For example + the statement adapter.getField(no.getFields()[0]) would retrieve the first field in the domain object held by the [[NAME]] referenced by adapter. - How it Works + + How it Works - When a domain object is used within the NOF the - ObjectSpecificationLoader instance is asked for the - ObjectSpecification for the domain object's class (by - name or java.lang.Class object). For performance - reasons these objects are normally cached and if the class has - previously been introspected then the cached version would be - returned. The first time that class is requested however the loader is - responsible for performing the introspection and creating a complete - ObjectSpecification. - - For each field that the reflector recognises the loader creates - either a OneToOneAssociation object for a value field - or a reference field, or a OneToManyAssociation object - for a collection or array. Using the field objects the NOF can access - or change the values and references in the domain object. The fields - can also be used by the NOF to find out the field name, if the fields - are visible and whether it can be modified. - - For each action method that the reflector recognises the loader - must create an Action object. Using the action object - the NOF can invoke the method on the domain object. The action object - also can be used by the NOF to find out the action's name, whether it - is visible and whether it can be executed. - - In addition to the fields and actions the specification must can - also: return the various forms of class name (singular; plural; short; - and full); retrieve a title from, or generate a title for, the domain - object; flag the type of object (abstract, lookup, object, value, and - whether persistable); refer to its superclass, any inteferfaces it - implements and any subclasses; and allow objects to marked/cleared as - being dirty. - - - - Installation - - To set up the NOF to use a reflection mechanism the - Isis repository must be given a - ObjectSpecificationLoader instance before the - repository is initialised. This can be done using the repository's - static setSpecificationLoader method. For example, - the following sets the NOF up to use the basic reflector. + When a domain object is used within the NOF the + ObjectSpecificationLoader instance is asked + for the ObjectSpecification for the domain + object's class (by name or java.lang.Class + object). For performance reasons these objects are normally cached + and if the class has previously been introspected then the cached + version would be returned. The first time that class is requested + however the loader is responsible for performing the introspection + and creating a complete + ObjectSpecification. + + For each field that the reflector recognises the loader + creates either a OneToOneAssociation object + for a value field or a reference field, or a + OneToManyAssociation object for a collection + or array. Using the field objects the NOF can access or change the + values and references in the domain object. The fields can also be + used by the NOF to find out the field name, if the fields are + visible and whether it can be modified. + + For each action method that the reflector recognises the + loader must create an Action object. Using + the action object the NOF can invoke the method on the domain + object. The action object also can be used by the NOF to find out + the action's name, whether it is visible and whether it can be + executed. + + In addition to the fields and actions the specification must + can also: return the various forms of class name (singular; plural; + short; and full); retrieve a title from, or generate a title for, + the domain object; flag the type of object (abstract, lookup, + object, value, and whether persistable); refer to its superclass, + any inteferfaces it implements and any subclasses; and allow objects + to marked/cleared as being dirty. + + + + Installation + + To set up the NOF to use a reflection mechanism the + Isis repository must be given a + ObjectSpecificationLoader instance before the + repository is initialised. This can be done using the repository's + static setSpecificationLoader method. For + example, the following sets the NOF up to use the basic + reflector. - ObjectSpecificationLoader loader = new + ObjectSpecificationLoader loader = new JavaSpecificationLoader(); Isis.setSpecificationLoader(loader); - - + + @@ -5930,6 +5937,22 @@ isis.fixtures = BookingsFixture, Perspec + + + + + + + To store profiles (during exploration) for users the a profile + store must be specified. + + On the command line use -e xml to store them in an XML. + + Without this the profile will simply be kept in memory, and lost + on exit. + + +