The oops templates are all over the place. There is no consistent strategy to how they are used. Some are completely redundant.

Really, sorting these templates out should be part of an internationalisation strategy. However, that's beyond what i want to do just now. For Dakar, I want to:

1. Eliminate redundancy and duplication
2. Move error strings out of code and into the templates wherever possible

The following templates are redundant:

D      oopslockedrename.pattern.tmpl
D      oopsbadpwformat.tmpl
D      oopsmissing.tmpl
D      oopsaccessmanage.tmpl
D      oopsresetpasswd2.tmpl
D      oopsaccesschange.tmpl
D      oopsaccessrename.tmpl
D      oopsrev.tmpl
D      oopslocked.tmpl
D      oopslocked.pattern.tmpl
D      oopslockedrename.tmpl
D      oopsempty.tmpl
D      oopsbadcharset.tmpl
D      oopsauth.tmpl

-- CrawfordCurrie - 27 Mar 2005

As part of the internationalization effort ... perhaps go the same way that others have and move error strings out of the code and into lookup tables.

Yes, i know its easier with C where such strings are 'tagged' and a pre-processor puts them into a table and replaces the string in the code by a reference to teh table. Changing languaes changes ... I forget, is it the table or a secondary key?

Either way, having an error mesasge table will simplify oops-ness. It also offers oportunity for endless ammusment. (In one frivolous moment in my youth I used YACC to write a tanslator to rhyming slang.)

Seriously though: is there some way we can refctor and simplify the Oops handling? Perhaps have a two-stage system, a single Oops template and a table that imposes oe of a limited number of formats on it.

-- AntonAylward - 27 Mar 2005

I think that what Crawford highlights above is just another example of the confusion between layout, appearance, and content, which was prevalent in the early TWiki and which we have begun to sort apart now. I would expect that there would be a limited number of oops templates eventually:

• Probably one oops template for errors (e.g., oopslocked.tmpl), and
• one oops template each for the variouus dialogs (e.g., oopsmore.tmpl)

Having the content of error templates driven from a table is a good strategy. I guess that we need to do the same for the dialogs, but that is much more work.

-- ThomasWeigert - 27 Mar 2005

Oops template elements:

1. Title
2. Body text
3. Links/buttons

-- ArthurClemens - 27 Mar 2005

At this level of abstraction, of course you are right. But that can also describe a normal twiki topic. If you look at some of the oops templates, say, the more or change form oops, what would be in text is rather complex. Definitely much more than just a string of text saying "you messed up".

-- ThomasWeigert - 27 Mar 2005

Another thought: all oops messages (text and buttons) could be in one topic, and dynamically included using %INCLUDE%.

-- ArthurClemens - 27 Mar 2005

Inspired by Arthur, I extended the oops support to add a "def" parameter to the OopsException, so you can now select a single def from among many in an oops template to be expanded. This allows us to collapse all these little error messages into a small number of files. It also allows us to use the full set of %PARAM values with every error message.

I have reviewed all the uses of the templates in code to try and make sure the parameter orders are right, but there may still be some that are wrong. Please help test by generating the relevant errors from the browser.

The templates can all be reviewed at TestCaseManageOopsies, TestCaseRegisterOopsies and TestCaseOtherOopsies. On DeveloBranch, of course.

-- CrawfordCurrie - 01 Apr 2005