On 7/18/05, Stu Robertson <[EMAIL PROTECTED]> wrote: > The patch for unit testing voiceXML apps was just accepted to htmlunit. <snip/>
Yup, saw the blanket application/*+xml. Thanks. > Regarding my validation issue, you're right -- I can get what I need by > setting size=7 for min and max and making the messages the same in the > config. And actually that is acceptable for me. It would be nice if > there were a separate validation for exact size so that the default > error message would be more appropriate, but that's a pretty fine point. > Doing it at the grammar would be tricky because grammars are static > resources in the jars, right? I wasn't thinking of that, though it's > interesting. How would that impact error messages? Would that mean the > interpreter would generate a no-match event if the input were the wrong > size? If so, I don't like that because it wouldn't give a very > meaningful message (speaking name and giving 6 digits would give same > error msg). Having the RDC generate the message seems like the most > flexible and user-friendly approach. <snap/> A colleague of mine, Jeff Kusnitz, was of the opinion that the grammars be constrained based on instance data. You're right that would probably produce more nomatch'es. You're also right that the static grammar will need to be replaced (more below on your question about dynamic grammars). Its more work for the RDC author; I personally do not have a preference on this one -- its upto the RDC author. > > As for the property files for specifying grammars, I noticed those went > in a while ago, but haven't taken a look. Do I need to change them in > the rdc source, or is there something I can do in app-space to make the > new grammars active for a locale? <snip/> You don't need to go to the source in the sense of re-building the sources, but you will need to edit the properties file for the locales that exist in the distro (currently, thats US English). The properties files for the other locales can just be dropped in WEB-INF/classes. > We'll be doing a multi-lingual app, > so the locale-per-app granularity is what we're looking for. I'll read > through your comments more carefully a bit later when we get to this > stage. It sounds like overriding these on a per-locale basis is > possible...which was my hope. <snap/> Its possible :-) > > Btw, what is a dynamic grammar? <snip/> Sorry, I was probably a little too brief there. A RDC could use a URI grammar where the URI points to a JSP/servlet that emits grammar based on some request params (which are in turn influenced by the values of the RDC tag attributes). > Also, what did you mean by "vary > validation rules suitably?" Did you mean change rdc validation to do > things that could also be done in the grammar, as per your example? <snap/> The point there was -- to constrain the input from the user further, one can either produce a restricted grammar or introduce more stringent validation rules. One can work in the other direction to get a more forgiving UI widget. And finally, one can author a RDC where the tag attribute values affect the grammars and validation rules so that two instances of the same component behave differently (going back to our example, the date component may cause the year to be required or optional or absent based on a "mode" attribute). > > Regarding the possible JSP writer buffering issue during forwards, would > you like me to send you my application offline? It should be an ideal > testbed since I get it instantly when I stop redirecting. <snip/> The first priority right now is to get the RDC release out, but feel free to send me an email with a simple test case attached (and the redirecting solution you use). Also attach some patience ;-) Thanks, -Rahul
