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