|
[
Permlink
| « Hide
]
Andrew Poland added a comment - 25-Jun-2007 12:36
Work committed to branch: https://source.sakaiproject.org/svn/portal/branches/SAKAI-10448
1 new configuration option is added to optionally control the order of the categories. If not specified the order will be undetermined.
portal.term.order.count=3 portal.term.order.1=Summer 2007 portal.term.order.2=PROJECTS portal.term.order.3=OTHER From John Leasia:
Andrew - I was wondering if you thought there would be any performance problem with sorting by term given that the term is stored in a XML blob inside a long which can't be gotten to directly via an SQL? Its better after the conversion to CLOB but still the sql as I understand it isn't too quick. I was going to send out something describing some changes we want to do for 2.5 - adding a Term field to the SAKAI_SITE table, which would allow faster searches. We want to do that for a couple reasons - including performance of the Sites Browser tool, and to make tab management in preferences able to do some things term based. Maybe that would help with your patch too, which looks cool. That's a good observation. This enhancement loops through each site the user belongs to and calls getTerm to build the category lists. I would imagine it does slow things down if it has to retrieve the terms via XML blob. I'd definitely be in favor of adding a new field for term.
TODO: At the moment this is hard coded for the out of the box site types "project" and "course". Would like to make it more flexible should an institution wish to use other site types.
Also need to determine best way to internationalize the column titles. Patch to css is also required
Andrew Observations 1. For performance..... We need to fix the XML serialization underneath all the legacy services not to use a DOM parser and not to have such a huge memory impact. 2. Since the sites are loaded already, the extra cost of getTerms is almost certainly zero. Questions. 1. How is this presentation controlled ? Can it be turned off with a switch back to the orriginal layout ? 2. I can imagine that we need UI/UX team agreement on this before it goes in as a change to the "more" drop down. If you can get agreement and blessing of this, I will feel safe putting the patch in without getting shot down. term is actually a site property, it's not serialized into an XML blob. In theory this could be read and sorted efficiently using a join of SAKAI_SITE and SAKAI_SITE_PROPERTY, but in practice I think probably SAKAI_SITE gets read and then all the related site properties for each site. I doubt it's a performance issue in this case though.
There might still be a case for promoting term to SAKAI_SITE rather than SAKAI_SITE_PROPERTY for other reasons. Ian:
At the moment it is a replacement for the dropdown. I can modify so that a switch back to the old layout selectable via sakai.properties. The UI could certainly benefit from further refinement, I will discuss with the UI/UX folks. I think when we put the switch in to allow the old layout, we would like to enhance the old layout to sort the list in the dropdown by term/categories using option groups:
Example: http://www.netmechanic.com/news/vol4/html_no20.htm Do you think there needs to be an additional switch to turn off the option groups and make it behave exactly as 2.4? Andrew 1. how does this mesh with the OSP setup for tabs? e.g. the organizer tabs for Courses, Sites, etc.
2. Unobtrusive JS might be a good approach to implementing this -- you could use JS to replace the listbox, since display of the menu is JS dependent. 3. requiring a click, as opposed to showing the menu on hover is somewhat non-idiomatic. Web users have been conditioned to associate clicks with going places, in this case we're really showing a menu of options, not changing the user location. Yea I had that bit about the XML wrong - was thinking about some other problem. But we do have performance issues with the Site Browser tool, thought it was due to the term lookup, but maybe more due to the way search is implemented there - e.g., trying to find all the Psych courses for a given term involves a lot of joins and 'like %Psych%' instead of = .
There was some performance problem related to term at one time - which is why the term column in the worksite setup list isn't sortable - It was at one time but that was found to be, or thought to be, a preformance problem that was running app servers out of memory. Anyway, w/r to the term property, we were tlaking here about the issue of now, with the CM_ACADEMIC_SESSION_T table that stores term (session) info, the property in the SAKAI_SITE_PROERTY table is duplicating data. WSetup stores the term in the sakai_site_property table, but it should probably now refer to the ACADEMIC_SESSION_ID in the CM_ACADEMIC_SESSION_T table and get the term Title from there to display when term info is needed in lists for sites. We thought a new table (sakai_site_session) with two columns, site_id and academic_session_id would be better (so as to not muck with the sakai_site table and add a column there), and then, for 2.5, have a conversion that moved the term info out of the sakai_site_property table into the sakai_site_session table. Using the above patches courses that don't have a term will end up in a category called '$termKey' this patch names it 'No Term'.
I am a little unclear of the status of the patches and the branch associated with this SAK.
I am assuming that the branch is the official version ? I have had a look at the Branch and done a test merge I think someone (Andrew) needs to address the ability to switch back to the old behaviour. The DHTML approach will probably not be acceptable at some schools due to internal policies/politics so I dont think that we can just remove it. Also.... is this merge command the right one to use (in a local copy of portal trunk) ? cd sakaisource/portal svn update svn merge -r 31808:HEAD https://source.sakaiproject.org/svn/portal/branches/SAK-10448 . I'd like a default ascending sort on terms instead of an undetermined order.
I'd also like a switch to have terms display off, for both 2.4 and new layout. Are the courses sorted? Is this configurable? It looks like it can take arbitrarily large space at the top of the window. I have a very large number of sites, because of various kinds of testing. I don't want to use a huge amount of space at the top of the screen to list them all. For me this would be a really bad change.
All project/other sites in one column is probably a naive approach. I wonder if what we need is a config switch for "maxEntriesPerColumn" and a sensible default, wrapping further entries to another column under the heading. Maybe 10 rows? The a horizontal scroll could deal with our proliferation of columns.
On a purely presentation side, we could float the element, so it didn't shift the rest of the page, which would help address problems on that front. Also lets us put in some sexy translucency or animations... I really like the concept of this change but have major concerns about the amount of real estate it will take when already struggle with displaying content above the fold.
Above Andrew pointed to some examples of a categorized list within the dropdown. I like this design much better because of the real estate issue. It only displays the full list when you click it on it. So you're not losing real estate when you're not switching sites.
Could the "More" tab say "Less" when more is already shown? (Expanded view)
-1
+1 needs (so far): Ian Boston [26-Jun-2007 01:49] Question 1 second part and Question 2 positive Jean-François Lévêque [18-Jul-2007 03:24] positive Jason Shao [18-Jul-2007 09:24] solution Display on hover instead of click Ian:
The branch is the official version. I think your merge command is correct. If you'd prefer, I can do the merge myself. As far as real estate goes, it has worked extremely well in production at IU and I've not heard this concern from people who have been using it. The dropdown is only visible when you want it to be, so it is not in the way. Also where the div appears on the page layout is configurable per institution via CSS. GATech has already done a custom modification that moves it to the upper right corner of the screen, for example, instead of pushing down the page content. I've committed an enhancement to the branch that gives the ability to switch back to the original layout. It is on by default, and portal.use.dhtml.more=false will turn it off committed noterm.patch to the branch
I have merged this into trunk,
But it appears slightly broken and needs checking, hence currently off by default. Could you check please I see sites on the traditional list, that dont appear on the DHTML list. Committed in r33959
You may want to delete your branch at this point. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Closed
Minor
DHTML Tab navigation enhancement 
