David Scotson

Good stuff. I've always thought search to be important and this looks like it's going to tick all the boxes for me.

Have you considered the possibility of (optionally) allowing people to use the Java (or .Net) Lucene implementations for certain tasks? I've certainly heard of people returning results via e.g. Perl or Python but relying on Java to do the hard data crunching on the backend but I'm not sure how interchangeable they are for various task.

Quickform appears to do most of it out-of-the-box and has built in hooks for customising the rest. It also seems widely used, including being extended and customised in many different ways, as well as being generally well-respected.

It might not be perfect (what is?) but would appear to be the one to beat in this arena, the default option for handling forms with PHP. So maybe it's worth fully exploring what Quickform can't do before asking what the alternatives can.

From my reading of things I'm not sure I agree with Martín's contention that it requires/enforces MVC (in fact Googling seems to find the opposite complaint), or that any of Tim's points against it are unsolvable dealbreakers (e.g. unobtrusive javascript validation, even using AJAX to call PHP validation routines, is effectively orthagonal to the form generation if you can identify the forms with suitable CSS).

There's a lot of info here about how people envisage the input to the form generation process, but is everyone clear on what the output (that is, the eventual HTML, JS & CSS that will get sent to the browser) will look like?.

I'm just wondering where things like e.g.:

• making the forms CSS stylable with appropriate class and id names for each form and input,
• label tags that identify form items and their associated text label for easier clicking,
• titled sections for accessiblity,
• altered tab-ordering, or
• as-you-type AJAX validation (with a second layer of javascript that validates the form as a whole, and a third layer of functionally equivalent server side backup written in PHP) that checks user entries against a validation format and generates appropriate and usable error text to prompt the user to re-enter data

comes in to the equation.

Surely that's why people want to use form generation libraries in the first place, because of the awkward, boring, repetitive stuff like that rather than just HTML generation and escaping. The examples given to contrast the different approaches so far all seem to be at the shallow end of the problem space.

From the perpective of someone reporting bugs to various projects I'd vote for Trac. Many other bug trackers seem like they were simply autogenerated from a set of database tables. Trac feels like they've actually paid attention to the user experience of reporting a bug.

I can only assume they've put the same effort in to the experience for developers as I've generally heard good things from people on the other side of the equation too.

(And surely a move to SVN is merely a matter of time?)

I'm not a Mediawiki expert by any means, but I'm not convinced that even Mediawiki does this in exactly the way you describe. It does have templates but they are generally used for inserting a block of static text into multiple pages. And when the ability to insert custom page specific into templates is used it's primarily for tables of data rather than free flowing text.

Have a look at the editing source of this Wikipedia page and see how the infobox on the right and the succession boxes at the bottom are done. It works but it's geeky and tricky to edit if the text grows beyond a few words or phrases.

If it was me I'd just add an intial wiki page with the template text (and probably some task instructions too) and then ask the students to view the wiki code and cut and paste it into a new page before they begin. It's hardly an onerous task, works on every wiki ever made and so teaches them exciting and transferrable information technology skills.