Summary: | Dynamic events section | ||
---|---|---|---|
Product: | Websites | Reporter: | Stuart Herbert (RETIRED) <stuart> |
Component: | Other | Assignee: | Sven Vermeulen (RETIRED) <swift> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | infra-bugs, omerc.net |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Stuart Herbert (RETIRED)
2005-02-10 15:18:55 UTC
I see no problems with this, on the contrary. I do have one small request: I'm fine with PHP or whatever we use, but I'd like it to use guide.xsl _completely_ for it's interface. The guide.xsl file contains the XSLT code for the website design and converts GuideXML to the current XHTML (and future new design). Other than that, what are infra's requirements? Any chance for a design document? USE cases and such? If we can avoid php I'd prefer it. Having php on our web nodes just adds that much more for us to maintain, especially when an exploit or the like comes out. It also adds more of a security risk. Is there anyway we can generate this info on the fly using other means? Right now our web nodes are fairly easy to maintain, the thought of php scares me a little. I can deal with php on specific sites easier (forums, packages, etc). We can work around this by developing an application that manages the events, design an events xml and add in XSLT for events->guidexml. If you know how GLSAs are written, it's the same. We can then have event xml files somewhere which are then dynamically (read: using one of those kinky dyn-scripts) read in and converted to an XML file (like GLSAs and news items are done). It doesn't provide the flexibility that the PHP application would give but has proven to be adequate for similar things. Perhaps Stuart can clarify what he has in mind of functionality. I'm a bit worried about the "PHP-versus-by-hand" approach as even with a nice interface, all is still done by hand. If you insist on keeping the XML formation of the website, I think I can work somthing out to run by cron or somthing that will run some script that will update a static XML page with latest events and such, so that the static website we have now will be somewhat dynamic. That's been the current approach with a couple of the dynamic pages we already have like the main one. I could provide you with some ideas on how we currently deal with this. Just let me know. I'd sure like to get started on this, please contact me asap so I can get some work done. The easiest approach is to have an events.xml page which chains an events.xsl file with our guide.xsl file (i.e. convert EventXML -> GuideXML and then GuideXML -> XHTML). Think ProjectXML (http://www.gentoo.org/proj/en/gdp/index.xml?passthru=1) which uses project.xsl first (http://www.gentoo.org/xsl/project.xsl) to convert to GuideXML, which then uses guide.xsl. It's then just a matter of finding out what information you want to keep about each event, design an EventXML DTD and XSL. I'm totally in favor of such a project; it's a good addition for our community (both user and dev) and doesn't require too many resources (only a handful of people that occasionally add new events - probably by bug or through e-mail or other communication). Setting up would be easy: develop an EventXML (with DTD), transformation to GuideXML, a script that lists all events in an XML file (like we do for GLSA/news) and parse it. Go for it! Hi, The one limitation of an 'events.xml' approach is that we can't highlight specific events based on the user's location. If you look at www.php.net, this site highlights the events which are near a user (based on the publically-available geoip database). Can we insert dynamically-generated XML into the front-end? I'll settle for a static 'events.xml' approach, but it seems a shame that we're held back from producing a modern and fully-capable website by its fundamental design. Best regards, Stu If not being able to filter events based on the user's IP address which may not reflect the possibility that they are looking for an event in another country where they plan to vacation is the one limitation to an xml approach similar to what we already use for GLSAs and news items, I wouldn't think it's all that much of a limitation to be honest. Sorry, but I'm no longer interested in doing this. I'm a bit disappointed that something this simple has met so much resistance. Best regards, Stu |