James...
> On May 5, 2015, at 1:41 PM, James Wennmacher <[email protected]> wrote:
>
> I think
>
> <pags-group
> script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn
> <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
