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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
