RE: [bpel4people] ISSUE 6: Title: Does ht:getLogicalPeopleGroup() cause an LPG to evaluate?

["Mark Ford" <mark.ford@activevos.com>]

Martin,

Technically it's not the function's behavior that's different but rather the
LPG's behavior. Once an LPG is assigned to it is sticky. Therefore any
request for its data will return the value previously assigned, ignoring any
arguments passed into the LPG for its evaluation.

Based on your comment, I would expect you would raise a similar concern over
the ht:from and bpel:from logicalPeopleGroup variations since they exhibit
the same behavior.




-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com] 
Sent: Thursday, May 15, 2008 9:47 AM
To: 'Mark Ford'; bpel4people@lists.oasis-open.org; 'Trickovic, Ivana'
Subject: RE: [bpel4people] ISSUE 6: Title: Does ht:getLogicalPeopleGroup()
cause an LPG to evaluate?

Mark,

A function that behaves differently depending on context, as suggested in
the last paragraph, is always a bad idea in my opinion.
I'd rather see two different functions, or a parameter requesting evaluation
or not.

Martin.


>-----Original Message-----
>From: Mark Ford [mailto:mark.ford@activevos.com]
>Sent: Wednesday, May 14, 2008 8:54 PM
>To: bpel4people@lists.oasis-open.org; 'Trickovic, Ivana'
>Subject: [bpel4people] ISSUE 6: Title: Does
>ht:getLogicalPeopleGroup() cause an LPG to evaluate?
>
>
>The discussion at today's conference call clarified that the 
>original intent for this custom function was to provide a 
>means for getting a value from an LPG without triggering an 
>evaluation of the LPG. The assumption is that the LPG would 
>have been previously evaluated and the process or task 
>definition wants to reference the same value from that LPG to 
>ensure that it doesn't change with another evaluation. 
>
>I don't see the use case for this implementation. If a user 
>wants to ensure that they're getting the exact same values 
>from an LPG then they can use a local variable to store those 
>values and read from that variable. If the function is going 
>to be used within a task definition then the caller would more 
>likely want to pull organizational entities from one of the 
>task's generic human roles as opposed to pulling directly from 
>the LPG. The same would apply if someone were building a four 
>eyes pattern with people activities. It's better to use the 
>b4p functions to pull the values from the generic human roles 
>rather than to try and reuse a value from an LPG. 
>
>The simpler approach is to have one way of accessing LPG data. 
>Each call into an LPG triggers an evaluation of the LPG. The 
>only exception is if the LPG was previously assigned. With 
>this model, an LPG has two states: unassigned and assigned. 
>LPG's are in the assigned state when they are the target of a 
>copy operation. In this state they always returns the same 
>value. An LPG in the unassigned state always evaluates. In 
>this approach, there is no difference between the custom function
>ht:getLogicalPeopleGroup() and the ht:from or bpel:from.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS 
>TC that generates this mail.  You may a link to this group and 
>all your TCs in OASIS
>at: 
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php