Difference between revisions of "WebDev"

From Earlham CS Department
Jump to navigation Jump to search
(→‎The Courses Project (outdated))
Line 25: Line 25:
 
</ul>
 
</ul>
  
−
==The Courses Project (outdated)==
 
  
−
''The information on this project is outdated and is for the most part in need of rather serious revision. A direction for how to implement this has been chosen and work progresses steadily, it is at this point a very easy task, depending on a few external factors. In any event, use the below information only as historical reference.'' --[[User:Bogatjo|Jon]] 09:34, 3 Apr 2006 (EST)
 
−
 
−
Since I'm (albeit slowly) approaching the programming phase I thought maybe an opened discourse would be useful about my plans for making the course list dynamic.
 
−
For efficiency's sake there's really no need to continually be parsing what will be pretty much a static XML feed from WebDB. So what I thought was we'll throw a perlscript in the Courses sub-directory and execute it from crontab every semester or so... It can pull in the XML, apply the XSL transform, and generate the course list.
 
−
Dynamic, but not wasteful, is what I'm aiming for.
 
−
Thoughts?
 
−
 
−
Last updated [[User:bogatjo|Jon]] 23:56, 8 Mar 2006 (EST)
 
−
 
−
 
−
It might make more sense to put the perl script into the cgi-bin, just to help keep the file structure as clean and organized as possible...
 
−
--[[User:Weissto|Tom]] 16:51, 12 Mar 2006 (EST)
 
−
 
−
 
−
Well, theoretically I should be able to add to the cgi-bin CVS module, I'll throw it in there when I get back to Indiana. Somehow I lost my ability to tunnel through Quark with SSH to my desktop so the XML parser'll have to wait for implementation until after Spring Break.
 
−
 
−
We need to come up with a location for cache.html; the generated HTML course list which'll live as cache for the perlscript. We also need to deal  with $recache; the variable which indicates after what period new content should be generated. And, finally, we need to determine whether it is necessary to generate an MD5 sum of the cache to check for validity; otherwise it'd be damned easy for somebody to inject an SSI into cache.html which calls God Knows What.
 
−
 
−
One thought I had was generating cache.html from the XML parser and then chucking it into the Content database, which if I recall was just brought into existence. We can throw it in along with an MD5 sum of the page and when it was  cached, hell we can even create an archive kind of deal where we keep old caches and let people browse 'em for historical purposes or for predicting what courses could be offered in the future, somewhat like what's there now.
 
−
 
−
[[User:bogatjo|Jon]] 16:09, 21 Mar 2006 (EST)
 
−
 
−
 
−
Okay, Jim brought up in an e-mail that it would be more efficient to have the perlscript run at a specific time through I imagine a Crontab, instead of through an SSI. I think that I want to avoid Crontab so what I'm going to is suggest that we use the Perlscript we have but instead of SSI we run with AJAX.
 
−
What I think should happen is that in the Courses page we have an iframe linked to the cached generated course content. That way the user at least sees something when he or she enters, and odds are it'll never be that far off.
 
−
In the background, JavaScript should call the Perlscript and send as its GET variable the result of querying through the document object module cache.html's document.lastModified variable; then the Perlscript can check that against the current date and time, and then use that to determine whether to regenerate the cache.
 
−
In any case, the Perlscript will send back either the word "refresh" or "norefresh" and that can be evaluated to determine whether to refresh the iframe.
 
−
 
−
AJAX allows us to offload the processing to the background; I think it should be considered instead of Crontabs. I'm going to start looking at the feasibility of implementing this, unless anybody has any objections to raise on the matter...
 
−
 
−
[[User:bogatjo|Jon]] 14:05, 25 Mar 2006 (EST)
 
−
----
 
  
 
==Fixed Problems==
 
==Fixed Problems==

Revision as of 11:08, 9 January 2009

Content Administration Group

All the current issues we are working with, or are on our to do list.


ToDo

  • Continue to Report CVS bugs....( all )
  • Validate our XHTML and CSS and links( all )
  • Install the W3C Log Validator to automate the above task..(CS Admins working on this)
  • Replace center tags with something valid XHTML/CSS (Jon) Update 03/08/06: This sort of spawned another project... The CSS is a bit lengthy so I'm also looking into tightening the CSS in general a bit. (Jon)
  • Get feedback from the rest of the CS Department about AlumniDB
  • Fix everything under /html/courses it is all out of date. Part of this is getting the XML feed working and the other part is organizing old course folders and the like. (Jon) Update 03/08/06: I just wrapped up debugging the XSL transforms for the feed, so that gnome on my back has been shot after many hours of frustrated gnome-wrangling. Now it looks like another two weeks and I'll hopefully be able to have a tangible product in place for dynamic fetching of the course list. (Jon)
  • Find the script Jeremy wrote for barndoor to generate png images of email address and incorporate that into the admin interface to the mail system.
    • It should be possible to make all the image handling automatically done by the php scripts, they should be able to, using jeremey's script and a pre determined naming scheme, create the image, and delete the image when emails are added or deleted from the database. The images should also be updated when the data base entry is updated.
  • We should decided if we are using the virtual included headers for our pages or not, and then implement that site wide... Right now it is kind of a mish mash of stuff.


Fixed Problems

  • Register function for AlumniDB is broken.
  • Revert to yourself function is broken. Get a 404 error and your stuck as the new user until you relogin.
  • Fix AlumniDB admin function changeuser to show the info of the user that was switched to instead of admin's info on the 'view my info' page.
  • Ability to create an email list of all current alumni (admin only)
  • Revert function is broken again, in a different way though. When reverting from a user who isn't admin, the revert function serves up error.php
  • The mail system has been updated to use a postgres data base to support the cgi and php scripts. An admin interface has also been written to allow admins to access the database and make changes from the web. See the source code in html/email/ for more information.
Retrieved from "https://wiki.cs.earlham.edu/index.php?title=WebDev&oldid=4519"