Well, there's accessible and then there's California-government accessible if you know what I mean. If we have the latter in our sights, we will also consequently go broke and slowly sink into the ocean as well... haha :)
Simply aiming for keyboard accessibility would put us 85% of the way there and I think would be an excellent place to start. ----- Original Message ----- From: "Scott Battaglia" <scott.battag...@gmail.com> To: cas-dev@lists.jasig.org Sent: Wednesday, January 4, 2012 11:07:12 AM Subject: Re: [cas-dev] CAS-1013 implicit evaluationOrder in service registrations To be as accessible as possible (and yes, I know we have a long way to go :-)). I know Fluid's components were accessible out of the box. Wasn't sure about the jQuery plugin (I've found that some are friendly, and some are not so friendly) At this point where we can make it friendly with minimal effort (and where it would difficult for someone to work if we didn't), we should just do it. If we need to formalize that, I can certainly propose something. I can start to put together a guide also (but I would imagine you guys probably know more than I do) On Wed, Jan 4, 2012 at 1:07 PM, Jacob Lichner < jlich...@unicon.net > wrote: Yeah definitely because jQuery itself is accessibility-friendly via various keyboard plugins, etc. What are the accessibility requirements for CAS, exactly? On Jan 3, 2012, at 5:13 PM, Scott Battaglia wrote: Is the jquery one accessibility-friendly? On Jan 3, 2012 7:03 PM, "Jacob Lichner" < jlich...@unicon.net > wrote: Good discussion. (By the way, just got back from a nice break, hope everyone had a great Christmas and New Year!) I am fully on board with Andrew's thoughts here and I believe it was myself asking that exact question (ie "what can I take away?") that was the reason behind this particular ticket. It was my original thought after looking over the UI that the evaluationOrder should take care of itself as you would expect it to, but there are many factors involved that I am not aware of. I've looked over Misagh's drag and drop implementation and spoke with him about it today as well, which I would like to repeat here. I want to suggest sticking with jQuery for the drag and drop rather than Fluid Infusion. My impression with Fluid is that there is a lot of cumbersome overhead that adds complexity, creates a steep learning curve, etc (all of the things you would expect with a cumbersome overhead…). I also asked Matt and the others if they felt the same way and they feel exactly the same way. They suggested jQuery Sortable, which is part of the Widget Factory: http://jqueryui.com/demos/sortable/ (Quick side note: the new skin I created no longer uses FSS as well because simple CSS is all that is needed, but the new skin is another topic that I hope to address soon.) On Dec 20, 2011, at 6:32 AM, Andrew Petro wrote: > Misagh, > > I hear you on ways to make evaluationOrder more understandable, by reflecting > it in the UI (ability to list in order of evaluationOrder, display the > evaluationOrder attribute with the registrations listing in the manage view). > > My thought is that Order is just not the right abstraction here. The current > services management / services registry solution is using abstractions that > are too abstract versus what would be sufficient. > > I expect that CAS adopters don't want more than a few overlapping patterns, > and in the case where patterns do overlap, there are obviously more specific > and less specific patterns, and they always want the more specific pattern to > match. Getting to a programmatic algorithm for evaluating "obviously more > specific" is an interesting nugget of a problem; I'll be interested to see > how solvable this is. I admit I haven't given it enough thought to to know > the answer offhand. > > Consider a typical use case. > > A university balancing privacy and agility in SSO integrations might want: > > 1) By default, any service may get a persistent, anonymous, opaque identifier > 2) All services at https://portal.someschool.edu may get proxy tickets, since > they're service URLs representing portlets that proxy to interesting other > services > 3) Specific registered services may get the username and, varying by service, > other user attributes > > Now, suppose I go and register > > https://portal.someschool.edu/NetReg/login > > because someone decided to deploy the NetReg application into the uPortal > Tomcat. It's not a portlet, I don't want it getting proxy tickets, but I do > want it to get some other attributes, say. > > So, isn't it obvious that I'd want the > https://portal.someschool.edu/NetReg/login registration to supersede the > https://portal.someschool.edu/** registration? > > *There's no use case for unreachable registrations.* I certainly don't want > to add the NetReg registration and have it have no effect. And I certainly > don't want to add the registration, have it have no effect, and not be warned > about this. Yes, I could take care in making my registration have the right > evaluationOrder to get the desired effect, and yes, UI affordances could make > it easier to take this care, but I'm wondering if the best UI affordances > around evaluationOrder would be not to have it at all. > > That is, services registry and services management has more in common with a > rules engine and less in common with a Netflix queue. I'm not queueing discs > to be shipped to me, where Order and a better UI for reflecting and managing > Order makes sense, since we're essentially talking about objects that > necessarily really have an order. Rather, we're talking about rules for how > CAS is going to treat a service URL presented at runtime. These rules have > order only incidentally, because computers can only evaluate them serially > and because this is how logic works. They're not inherently ordered. > evaluationOrder isn't reflecting something inherent about the domain -- it's > a concession to the implementation. > > So, it seems to me that the use cases for these registrations are simpler > than the arbitrary configuration that evaluationOrder supports. I don't need > the power to create registrations with relative evaluationOrder such that in > practice they will never have any effect. Can I have less power and more > usability? > > If evaluationOrder had never existed, how would CAS figure out which > registration matches, and would that be good enough? > > I can't imagine a CAS deployment with more than 1000 service registrations. > Might it actually be true that CAS could load all registrations into memory, > *try every one of them*, and pick the one with the most specific pattern that > matched? I'm not saying that's the right, refactored, quality algorithm to > use here. But might it be the "simplest thing that could possibly work", and > might it be more usable than what's there now? > >> if order really has to go away > > I don't think of it this way. This isn't a war on "evaluationOrder". Order > doesn't really have to go away, or really have to be there. It's less a > question of what has to go away, and much more a question of what has to be > there. > > Isn't there some adage about a design being complete not when everything > that's needed has been added, but rather when everything that is not needed > has been taken away? > > My thought is that evaluationOrder isn't needed here, and can be taken away, > and the result will be simpler and better, if it proves feasible to program > the intuition of which registration "obviously" should match when two > overlap. > > Kind regards, > > Andrew > > PS: Thought: Perhaps evaluationOrder remains as an internal implementation > detail, derived from the registrations and precompiled on registry edit. > > On Dec 19, 2011, at 4:11 PM, Misagh Moayyed wrote: > >> Folks, >> >> Started to evaluate this new CAS feature request: >> https://issues.jasig.org/browse/CAS-1013 >> >> Few thoughts: >> >> 1. I would imagine that setting up a basic numeric value to indicate order >> would be much easier to understand than regular expression patterns. I >> certainly would be in favor of the property, but what I find confusing is >> that services management UI does not list the registered services by their >> order, but sorts them using their name. I think this is pretty misleading >> because you could have service A up at the top with the order 999999 and the >> user would probably assume that just because it comes first, it gets to be >> evaluated first as well. I think it’d be better if we modify the UI to sort >> by evaluation order >> >> 2. Why not show the value of the order on the UI in the list of services ? >> The scenario would be that if I want to register a new service, wouldn’t it >> be easier to know what the order of the new service should be beforehand >> rather than going back and forth between previously registered services and >> trying to find what the order should be based on other services? As the >> original comment on the feature says, if it’s on the main services page, it >> would be a better reminder for it to be updated. >> >> 3. I have also looked at ANTLR to see if an existing algorithm already >> exists. So far, haven’t found any other alternative. So, for starters if >> order really has to go away, how about something like the following priority >> order: >> >> a. Non-pattern URLs >> b. Longer URLs >> c. Prefer URLs that use “?” over those that use “**” or “*” >> >> Suggestions are welcome. >> >> -Misagh >> >> > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > jlich...@unicon.net > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- You are currently subscribed to cas-dev@lists.jasig.org as: scott.battag...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: jlich...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: scott.battag...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: jlich...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
