No, it’s really just something bolted on top of a permission system on a suite
of applications that have been in continuous development for almost 20 years.
In other words, not an ideal architecture at this point, but I think impressive
that it’s holding its own!
> On Aug 13, 2017, at 6:02 PM, Paul Yu <p...@mac.com> wrote:
>
> Is this an ABAC implementation?
>
> Paul
>
> Sent from my iPhone
> Please excuse iOS autocomplete
>
>> On Aug 13, 2017, at 5:08 PM, Morris, Mark <mark.mor...@experian.com> wrote:
>>
>> This is a topic that was discussed back in 2011, but my searches haven’t
>> turned up a satisfactory solution.
>>
>> Some quick background info, we have information-dense, complex pages, and
>> there are a variety of permission levels for internal and external users
>> that needed to be implemented at field-level granularity.
>>
>> My approach was to create a method for determining edit-ability in the
>> superclass for each area’s components that maps permission level with field
>> name:
>>
>> public boolean editingEnabledByField( String field )
>>
>> … which I’m calling using WOOgnl in WOConditionals as the condition and in
>> custom components like this:
>>
>> <wo:OurCustomComponent
>> editingEnabled="~editingEnabledByField(\”thisFieldName\")" expanded="$true"
>> />
>>
>> This actually works fine as far as the functionality goes. The issue is our
>> logs get filled with warnings that look like error messages, one for every
>> field for every page hit. Since the bindings on these pages are
>> synchronized, the log messages apparently occur when the value of
>> “editingEnabled” tries to get pushed into
>> “editingEnabledByField(”thisFieldName”)”, which obviously isn’t possible.
>> (So getting the value from the ognl expression works fine, setting to the
>> ognl expression does not.)
>>
>> In 2011 Mike Schrag wrote about almost this exact same question:
>>
>>> this seems wrong to me ... it's not the ognl is intrinsically unsettable
>>> it's that you're trying to set a value on an ognl expression that
>>> definitely ISN'T settable. either you should turn off automatic binding
>>> synchronization on SelectByCharacterPopupEditField and manually sync, or
>>> this patch should maybe be smarter about how it determines "setability" in
>>> ognl. i would be afraid of breaking anyone who might be taking advantage of
>>> settable ognl expressions. i don't, offhand, know how to perform that check
>>> -- whether ognl has API to do it or if it's even possible.
>>
>> The patch he was referring to was:
>>
>> public WOOgnlAssociation(String s) {
>> super(s);
>> _isValueSettable = false;
>> }
>>
>> … which is a sledgehammer approach that probably wouldn’t be applicable in
>> general. However, picking up from where Stefan left off there, perhaps this
>> is at least a partial solution (that I think will work for my case anyway):
>>
>> public WOOgnlAssociation(String s) {
>> super(s);
>> if( s != null && s.matches( ".+\\(.*\\S.*\\)" ) ) {
>> _isValueSettable = false;
>> }
>> }
>>
>> This regex checks to see if there’s a method call with some sort of
>> parameter (by looking for something followed by “(“ followed by some
>> non-whitespace followed by “)”).
>>
>> Does this seem reasonable? Any counterexamples where a matching key path
>> should be settable? I know that ognl expressions can include parentheses as
>> well, but I would think those also would not be settable, right?
>>
>> Thanks for any tips or advice!
>>
>> Regards,
>> Mark
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/pyu%40mac.com
>>
>> This email sent to p...@mac.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
