Hi, Omer Cohen has volunteered on gentoo-dev to write PHP-driven websites for us. And I'd like to take him up on his offer. Please make him feel welcome ;-) I'm keen on adding a PHP-driven events section to www.gentoo.org. Last year, I looked at what it would take to run the events section purely by hand, and I concluded that it's not sustainable. I'd like our events section to be very similar to what they do on php.net. The home page carries a short section listing upcoming events for the next two months, and each event's title is a hyperlink to full information about the event. In the section on the homepage, events which are in the same country as the reader are highlighted. Additionally, we'd have a form where users could submit events information. This part is really key; the single biggest problem I had with the static events section was the widely varying (and usually poor quality) information about each event. Having a structured form to fill out is a must have requirement. Submitted events would have to be approved before they could appear on www.g.o. A web-based interface for managing this will drastically cut down on how much time it takes to run the events section. If it's alright with you guys, in conjunction with Swift I'd like to act as the project sponsor, and owner of the business requirements. I'll also act as Omer's mentor. I suggest that the technical requirements are negotiated between Infra and Omer. At infra's request, we'll use this bug to track this particular project. What does everyone think? First of all, are there any objections to us having a web-application to power an events section? Best regards, Stu
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
