The conference happened in March, so the site needed updating to reflect the fact that it had finished, and to include the final program with abstracts.
Leaving early today.
The IP restriction will be frustrating for all of us when we're not on campus, so I've implemented a workaround, which I won't document here, for obvious reasons. Now those who need access can get it, and those who are off-campus and not entitled will be shut out.
Two of JL's students, who created the pages with the streetcar video, are finishing up their project, so we've been helping them get it organized for submission. We're only doing things that will make it easier to maintain in the future, such as abstracting common page features to PHP includes (menus, footer, etc.), and unifying all the styles. They've nearly finished their final edits (a little more on Monday), and we've done all the code tweaks we'll do, so we can burn a CD on Monday. Meanwhile, we're hosting a copy of the site so JL can see it.
I still have to write up the details of this meeting, on our upcoming tasks and priorities; just logging the fact that it happened. I'll write up my notes tomorrow.
It was decided at today's meeting that we need to prevent general users outside UVic from accessing all content except for 1858, because we can't properly vouch for its accuracy, and it's incomplete (no footnotes, bios, etc.). I did some research to try to figure out how to most easily branch a pipeline based on the client ip address on Cocoon. This is one way to do it.
First, add this to the sitemap for the project, to enable the remote-address-regexp matcher:
<!-- MDHCustom: added remote IP matcher to restrict access by IP to UVic, for some resources.-->
<map:matchers>
<matcher name="remote-address-regexp" src="org.apache.cocoon.matching.modular.CachingRegexpMatcher">
<input-module name="request">
<parameter>remoteAddr</parameter>
</input-module>
</matcher>
</map:matchers>
Then you can use it to branch a sitemap pipeline, like this:
<map:match pattern="^142\.104" type="remote-address-regexp"> <map:redirect-to uri="intro.htm" /> </map:match>
However, this proved completely impractical, because we couldn't work out a negative matching regexp that would work in this context. PERL has extensions which make negative regexps work better, but one which worked well on our test utilities didn't work in the context of the Cocoon sitemap.
So I had to go for a simpler solution. In the sitemap, we have this:
<map:transform type="saxon" src="xsl/doc_to_xhtml.xsl">
<map:parameter name="clientIP" value="{request:remoteAddr}" />
</map:transform>
This enables us to check the IP during the transformation, and hide some of the content. We're now doing that. However, this will annoy all of us in the end when we have to do work from home, so I'll now have to find a workaround that we can secretly use. GRRR.
DP reported a bug in the Web View output that affects pages with huge annotation lists. The annotation menu appears to have a scrollbar, but in fact it doesn't scroll, so you can't get down to the bottom elements in the list; and because it's position: fixed, even though the page itself scrolls to accommodate it, you can't get down to the bottom of the list because the menu doesn't move with the page. The sample page is here.
There's a JavaScript function called Initialize() that does a lot of the positioning and sizing work. It contains this line:
document.getElementById('AnnMenu').style.overflow = 'scroll';
which should make the scrolling work, but I suspect the height of the container element is being extended too far, and the container doesn't have a scrollbar. I see a line commented out, just before that:
// L.style.maxHeight = ImgHeight + 'px';
That would set the max height of the menu container, which might achieve the desired effect, but if I've commented it out, it's probably because of some unwanted side-effect (probably with IE, which doesn't support CSS max-height).
AskPhilosophers.org - Philosophy For Everyone
Philosophy is usually reserved for the upper echelons of academia. You learn a little about it in college and it’s quickly forgotten. However, now and then, no doubt, a philosophical question will strike. So where do you go to get your answer? AskPhilosophers.
Got PS started on proofing and editing the schedules, and he's finished the first file (of 133); we estimate about 140 hours in total to do them all. Also, I added more details to the document_sequence.xq output, so that in the future I'll be able to produce a full page of links including all the documents. That's going to be handy if we want Google to index everything, and/or we want to allow people to search the whole set. Through the day, too, we've done various small tweaks to output and appearance, between us.