That does make more sense. Thanks for explaining it so well. James Wennmacher - Unicon 480.558.2420
On 05/06/2015 09:43 AM, Drew Wills wrote: > James... > >> On May 5, 2015, at 1:41 PM, James Wennmacher <[email protected] >> <mailto:[email protected]>> wrote: >> >> I think >> >> <pags-group >> script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn"> >> <name>Member of Students (PAGS)</name> >> <description>Member of Students group</description> >> <selection-test> >> <test-group> >> <member-of-group>Students</member-of-group> >> <not-member-of-group>Test Users</not-member-of-group> >> </test-group> >> </selection-test> >> </pags-group> >> >> is great and a much cleaner solution. I want to verify you could do >> something like the following: > > Except that (I feel) the child groups *need* to be wrapped in a <test> > element and the <tester-class> element *needs* to be there. I don’t > want to start teaching Import/Export about specific IPersonTester > implementations and whether you can “infer” one or another > specifically based on the nature of the child elements found within > the <test-group>. > > Also, the element names “member-of-group” & “not-member-of-group” are > workable — that approach would be okay — but I think even better is > <includes> & <excludes>, here’s why… > > In the future we may want to create even more IPersonTester classes > that do new and innovative things. For their functioning, they may > need some parameters in the <test> element as well. These parameters, > moreover, will need to be modeled as members on > IPersonAttributesGroupTestDefinition and the JPA-managed > implementation of that interface as well… so that means (albeit minor) > database schema changes. I’d like to avoid those, to the extent > possible, so I’d prefer to use names that are more likely to be > reusable in the future with other IPersonTesters. > > So my proposal for the XML corresponding to this example would be > (note the version change in the script attribute)… > > <pags-group > script="classpath://org/jasig/portal/io/import-pags-group_v4-3.crn"> > <name>Non-Test Students</name> > <description>Students who are not test accounts</description> > <selection-test> > <test-group> > <test> > > <tester-class>org.jasig.portal.groups.pags.testers.AdHocGroupTester</tester-class> > <includes>Students</includes> > <excludes>Test Users</excludes> > </test> > </test-group> > </selection-test> > </pags-group> > > This way, furthermore, it’s clear how you combine test definitions > based on the AdHocGroupTester with other criteria (just as we’ve > always done). This approach makes this new type of group less > different or weird as compared with existing groups, testers, data > files, documentation, Import/Export support, etc. > > drew > > > > > -- > > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
