Hi Scott,
Thanks for your email.  Yes, I did notice the browser definitions in the
global sitemap.xmap, and I had previously verified that entries exist for
IE6 and IE7.  While the BrowserSelector mechanism does seem to match IE in
general, it appears to have problems differentiating betwen IE6 and IE7 --
but as far as I can tell, the problem only occurs on the Login page.  It
almost seems like the Login page is not building the HTML header the same
way that other pages are.

My theme's XSL file does override buildHeader (to include TAMU's breadcrumb
ellipse feature), but not buildHead which is responsible for CSS, RSS, etc.
Thinking that overriding only one of these might be responsible, I tried
adding the other to my XSL file too, but I didn't notice a difference.  I
also tried removing all of my overrides, but that didn't seem to fix the
problem either.  Then there is the odd caching issue that I mentioned
before.  Not really sure what to make of that.  I've tried backing out all
the changes I can think of, and the problem remains.  I must be missing
something though, since I doubt this problem exists in the stock
distrobution.

I had to demonstrate DSpace yesterday to one of our faculty committes on
campus, so I ended up implementing a workaround.  What I did was configure
my theme to use only style.css and style-ie.css.  In the IE stylesheet, I
have a general section with rules that render properly in IE7 followed by a
section of overriding rules that use the underscore hack to target IE6.
Not elegant, but it worked in a pinch since I no longer had to choose a
specific CSS file based on IE's version.

Eric

On Thu, Feb 12, 2009 at 9:59 AM, Scott Phillips
<scott.a.phill...@gmail.com>wrote:

>
> Eric,
>
> The ability to provide additional CSS files for specific browsers is meant
> to simplify your life not make it hell - sorry about that. First look at the
> global sitemap.xmap at the root of the webapp around line 136 you should
> find something like the following:
>
> <map:selector name="browser"
> src="org.apache.cocoon.selection.BrowserSelector"
>        logger="sitemap.selector.browser">
>        <browser name="explorer" useragent="MSIE"/>
>        <browser name="explorer6" useragent="MSIE 6"/>
>        <browser name="explorer7" useragent="MSIE 7"/>
>        <browser name="safari2" useragent="(KHTML, like Gecko) Safari"/>
>        <browser name="safari3" useragent="(KHTML, like Gecko) Version/3"/>
>        <browser name="firefox" useragent="Firefox"/>
>        <browser name="firefox1" useragent="Firefox/1."/>
>        <browser name="firefox2" useragent="Firefox/2."/>
> </map:selector>
>
> These are the definitions that your theme is using to select stylesheets,
> basically if it sees the string in the useragent field then the request is
> tagged. A request can have multiple tags, so if the useragent string
> contains MSIE 7 it will match the tags "explorer" and "explorer7"
>
> I hope that light on the mechanism makes things simpler.
>
> Scott--
>
>
>
> On Feb 10, 2009, at 2:37 PM, Eric Luhrs wrote:
>
>  Hi all,
>> After looking at this problem for a few days, I feel like I'm going nuts.
>> Hopefully someone on this list can help me with it.
>>
>> My Login page sometimes pulls the wrong CSS for IE.  All other pages pull
>> the right CSS for different versions of IE, and Firefox works fine no mater
>> what page is requested.
>>
>> Here's where things get strange....  Sometimes IE6 pulls the stylesheet
>> for IE7.  Other times IE7 pulls the stylesheet for IE6.  As far as I can
>> tell, it seems to depend on which version of IE is the first to view the
>> login page after tomcat has been rebooted.  So if I reboot tomcat and then
>> visit the Login page with IE6, subsequent visits with IE7 will continue to
>> pull the CSS for IE6.  If I reboot tomcat again, and then visit the Login
>> page with IE7, subsequent visits with IE6 will continue to pull the CSS for
>> IE7.  Doesn't seem to matter if I visit with Firefox first, it's only the
>> first version of IE that gets stuck.  If I disable caching in Cocoon the
>> problem goes away, but then "advanced search" gives a Null Pointer Exception
>> (see posting from a few days ago for details on this).
>>
>> I'm using 1.5.2 code that is a few weeks old.  My theme is based heavily
>> on Reference, with a few changes to the XSL.  I also modified the EPerson
>> sitemap.xmap file to make the "login" link skip the Login Chooser and go
>> directly to /ldap-login.  I don't think this is causing the problem though,
>> because the same thing happens when I use the standard EPerson sitemap.
>>
>> Does this make sense to anyone?  All suggestions will be GREATLY
>> appriciated!
>>
>> Eric
>>
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with
>> Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills and code
>> to
>> build responsive, highly engaging applications that combine the power of
>> local
>> resources and data with the reach of the web. Download the Adobe AIR SDK
>> and
>> Ajax docs to start building applications today-
>> http://p.sf.net/sfu/adobe-com_______________________________________________
>> DSpace-tech mailing list
>> DSpace-tech@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>>
>
>
------------------------------------------------------------------------------
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Reply via email to