|
The default and default-horiz skins contains a file called access.css. This file is used by the access servlet to style it's pages.
The access servlet has the access.css hardcoded to be the one in the default skin. /content-impl/impl/src/java/org/sakaiproject/content/impl/CollectionAccessFormatter.java Has the code which generates the link to the CSS. This code doesn't understand the default skin or the site skin for which the content is in. Example of an access URL (sakai-dev) https://collab.sakaiproject.org/access/content/group/1097928811887-22636/ Gonzalo, is this one you could review? Thanks.
There a 2 possible solutions to this, in order by desirability:
1 - servlet detects site skin, uses it - referenced css are: - tool_base.css, tool.css, access.css 2 - servlet uses access.css only - but access.css is improved by addition of selectors specific to it (for which the servlet would also need to be edited), and in turn it also calls tool_base.css (insuring that there is a family resemblance with the institutional stylesheet - colors, font, font-size, etc.) If 1 is the preferred method, a developer will need to add the link to the sheets. I could do 2 - see discussion at: http://bugs.sakaiproject.org/jira/browse/SAK-13694 Thanks! If go for option 2 could we move access.css out of the default skin (up one folder?) as it is misleading to people customizing their skins.
I think one should be able to customize the access collection display per site, so I 'd vote for option 1, with the possible variant that we do away with access.css and move the required selectors into tool_base.css and tool.css.
That does seem like the sensible thing to do:
1 - access servlet runs with site skin 2 - access css is incorporated into tool css Can you assign to someone that can do 1 (and review my changes to the servlet) and then back to me so that I can do 2? Thanks Ian, can you do the first part and Assign back to Gonzalo? Thanks.
We rewrote CollectionAccessFormatter.java for a custom Sakai build used for an online conference.
The revised code is here: https://source.sakaiproject.org/svn/uct/emerge08/content/content-impl/impl/src/java/org/sakaiproject/content/impl/CollectionAccessFormatter.java This is so different from the original that it's not really mergeable back into trunk, but it does have a number of fixes and useful features, including: - breadcrumbs - uses css from the site (currently tool_base, tool and access though I think the best is to drop access and put everything in the site's tool.css) - fixes links to metaobj - shows descriptions Having worked with this a little, 1. the basedir and sferyx stuff really complicates the code. We took this out for simplicity in the custom version. I'm not sure if it's even used anymore or what the specs/requirements are. 2. There are many possible desireable formats for directory indexes, and ideally one should be able to do this differently for different sites. I think it would be ideal if we could implement something that allows a custom xslt renderer (similar to how forms are rendered). We should have a good default which people can override on a site basis (or a folder basis, inheriting the parent being the default) if necessary. Example of directory index shown in a web content tool (formatted using the custom code referenced above).
The description is the item description and the italics is the dc_creator optional properties text. I am unassigning this issue as it gives the wrong impression. I dont have enough hours in the day to look at this issue at the moment and keeping it assigned to me give the reporter hope that I might be able to look at it. I am very sorry. If this issue is a real blocker for production then I would suggest you look for resource in the community to fix the problem, I am happy to respond to emails and guide. Where the code base is Rwiki or Search, I have absolutely no problem with someone else working on the code, this after all is a community.
This is the patch to 2.5.x we used in production. It depend on having a default skin in your local skins folder.
Trying automatic assignment (didn't work with Access)
Gonzalo, is this something you need to do more on now?
This has 2 parts in it's simpler version:
1 - access servlet runs with site skin 2 - access css is incorporated into tool css Till 1 gets done I cannot do 2. Also So it should be asssigned to someone who can do 1 and commit to kernel or submit a patch to kernel, sorry to not be clear.
Attaching a patch done against recent 2.5.x maint branch; it duplicates the attached Oxford 2.5 patch. This is being tested at Columbia and seems to work, so it could be used for a 2.5.x merge.
Resolved for kernel 1.1/trunk in
Stephen,
Anthony asks the following: "Gonzalo--can you review the following SAKs and if any have been tested and verified, can you close them, setting the fix version to 2.6.2 and, if appropriate, 2.7.0-M2. If any of the issues in the list are not ready for merging can you set the fix version to 2.6.3 and 2.7.0- M3 if appropriate." This SAK is included in the list, since I had little to do with the fix, can you make the determinations that A is asking about? Many thanks - that is why I assigned it to you. The fix for this is in
It could be backported if someone wanted to take it on by making equivalen changes in the 1.0.x version, or the complete set of changes related to Per the 2.5.6/2.6.2 Jira Review Meeting held on 2009-12-08, this issue has been scheduled for the 2.5.6 release. The 2.6.x status is less clear.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Resolved
Major
make 'access servlet' use files from local skins folder
The classes in access.css probably need to get merged into tool.css