With advice from BLT on what was intended, I've fixed the secondaryNavbar.php code in the student subfolder. I think the style of the section headers could be revisited, and customized, so they don't look selected, but the page is valid and everything works.
The previous bugs in aboutus/secondaryNavbar.php had re-introduced themselves, so I fixed them again. Then I realized that another secondaryNavbar.php page in the studehnt subfolder has similar bugs, so I started looking at it. The left-side menu looks like it was supposed to be designed to expand and contract, so initially you would see only:
For all students For undergraduates For graduates
then when you clicked on one of those, it would expand and show the contents below it. But it doesn't work like that; all the contents are expanded all the time.
The code looks as though it was once written to expand and contract, but it's completely broken; it has <li> elements embedded directly inside <li> elements, multiple class attributes on the same element, and all sorts of confusion. I don't yet know how to go about fixing it, because I don't know what it originally looked like. I found an old backup of Stewart's, but it's structured completely differently; instead of secondaryNavbar.php, it uses section_left_nav.inc, which looks somewhat similar, but was only ever intended to be static. I'm waiting for some feedback from BLT, in case he can remember what the original intention was, and when the changes were made.
I've now implemented the plans described in this previous post, as follows:
rssReaderManyDepts.phpfile has been modified in a couple of places, to add an optional parameter (default value "true") called
$includeDesc, which is used to control whether or not the Description field is included when the full event detail is written out. This doesn't change any other behaviour elsewhere on the site, but enables me to suppress the description information when I need to.
rssReaderclass, which is set to retrieve events for only 8 days. This class then writes out the events twice, once in short form (for copy-pasting into the email) and once in long form (so that the speaker information can be retrieved and copy-pasted into the email too, where appropriate).
I've emailed BLT to let him know about the new page.
Preparing to write the new Events feed page requested by BLT, I first set about fixing a bunch of errors in the existing code:
writeOutTitle()did not echo open
</li>tags around its content, although it is called in the context of a
<ul>tag. Added the appropriate tags, and also commented out
<br/>tags which were being used to space the content.
writeOutEvent()echoed out two
<br/>s and an
<hr/>after closing the
<li>tag; this obviously was invalid, so I've moved them inside the
<includes/rightColumn.inc>had two elements with the same id attribute (
rightCol_1). I changed the second to
<includes/rightColumn.inc>had an unclosed
rightCol_2). That's now closed.
Pages now validate, so I can move on to the new events output page.
Details of a request from BLT to an enhancement to the RSS feed reader on the Humanities faculty site:
<ul>element with children which are
<p>s instead of
I'll get to work on this in the week of the 18th.
BT contacted me asking about a feature of the Hums site which SA had proposed and possibly implemented that would provide a short-form view of the events calendar events, suitable for copy/pasting into a weekly email. I poked around on the site, and I found that the RSS reader object is based on some code I adapted years ago for the GRS site, so I've seen it before, but it's been modified considerably to handle the multiple calendar sources. The reader has a "shortForm" parameter that causes it to spit out the events in a shorter form. That can't be set externally, unfortunately -- it's private and there's no setter function -- so as a quick workaround I created a new page called eventsSimple.php which re-creates the reader with the shortForm parameter set to true in the constructor.
The resulting output for each event consists only of a date and a title, which is linked to something that doesn't work. Obviously we'll have to tweak it, so I'm waiting for details from BT about what he'd like to see in the list, and then I'll make some modifications to the reader to make the short form output more useful, testing everything in the :8080 first.
I'm beginning to work out the structure for the tables in the database for the Victorian Poetry database.
The primary unit in this database appears to be a published-poem.
Each published-poem has a relationship to a poem and to a periodical. Each poem has a relationship to an author.
There are some questions that I need MT to answer before I can continue.
1) Will there be any instances of a poem having more than one author?
2) Do we distinguish between a poem with no author and poem whose author is anonymous?
3) Do we have one anonymous author associated with all unattributed to poems, or do some unattributed poems get associated with one "anonymous" and other unattributed poems get associated with another "anonymous" (for example, if you have a collection of poems you know to be written by one unknown person and wish to distinguish that author from another unknown person who wrote another poem)
4) We've noted that authorship can be declared or can be inferred by the scholar, are there any other ways authorship is attributed? (We'll need to include a "authorship_determined_by" field to contain that information.)
5) We need to tighten up conventions on what information we capture about each person's name (and possible title or other identifiers) and how each of those is to be represented in the spreadsheet. The most common presentation of author name is Surname, FirstName, but a number of entries don't conform, for example these from DarkBlue.xls:
the late John Lyall
Leary (D.C.L.), T.H.L.
And these from DublinU:
The London Hermit
Rev. Dr. MacMoreland
And these from PoetryIndex_1.docx
We discussed having an "author-as-found" field and an "author-normalized" field.
6) Do we separate author surnames from given names e.g. for purposes of searching?
7) We also need to tighten up conventions on what information we capture about each published poem's title and how each of those is to be represented in the spreadsheet. Some of the "titles" appear to be titles, others appear to be the first line of the poem. Do we want to distinguish between those?
8) These are instances of titles that appear to contain more than just the title. Do we need to do anything with these other than reproduce the characters as found?
Tragedy (trans. from the German by Franz Huffer)
The Story of Europa (Hor. Od. III. Xxvii. 25.)
'Amour qui Sourit Caché'
One untitled poem opens and two close the author’s essay “Sketches of Travel in Germany”
9) This example of a title in DarkBlue appears to refer to a collection of poems.
Garden Poems (I.—The Garden, II.—Visions, III.—The Bird ...)
This example from DublinU also appears to refer to a collection, but is treated differently:
I [Happiest of happy feelings ‘tis to feel]
II [If gold could give us peace]
We have no structure right now for handling collections of poems. Should we? That is, do we want to treat an entire collection as one poem (what about collections whose poems are written by different authors) or do you want to treat each poem in a collection as a separate poem and then add a "collections" table and some way of relating each of the poems to the collection?
In the poetryindex_1 file, a typical entry begins like this:
No. 1, 129
Whereas, in DarkBlue the issue/page field looks like this:
1 (March 1871): 35
What does each piece of information in both types of entry identify? We'll need to normalize that.
This blog is for work done creating and major updating of departmental and similar sites. Routine text edits etc. are logged in the Depts blog.
|<< <||> >>|