jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stu Robertson <srobert...@nvisia.com>
Subject Re: RDC: Functional/unit testing RDC-voiceXML apps using canoo webtest
Date Sat, 16 Jul 2005 17:07:00 GMT
Hi Rahul.  It would make a nice wiki page.  I'll try to put something  
up over the next few days.  The only reason I didn't post my test  
files/scripts is because the content is clearly client-oriented.  I  
hope the patch gets accepted to htmlunit shortly, since patching is  
by far the trickiest part of what needs to be done.  The writing of  
scripts is pretty trivial - I found I spent the same amount of time  
writing regression scripts as I had done creating a "test jsp" with  
links to the same content for visual inspection.

I have a few RDC questions for you.  There are a few things we'd like  
to do, some of which will require changes to the RDCs.  I'll be doing  
that over the next week probably, but would like to bounce them off  
you first to make sure I'm going in the right direction.

First, we need validation that in put is an exact size, rather than  
just a range, for alpha, digit and alphanum.  Range works, but the  
error message is goofy.  The change looks straightforward, and I was  
thinking of making the new attribute "size."

The main thing though is to find or make a way to specify custom  
grammars for standard RDCs.  For instance, date.grxml allows year to  
be optional, which for our purposes will never be the case.  We'd  
also like to narrow some of the grammars that accept wider input than  
we need, to improve the accuracy of speech recognition.  These are  
generally minor tweaks, and do not change the contract between the  
grammar and the RDC.  I see in fsm-input where these are set, and  
that there's flexibility to have inline grammars and arrays of  
either.  I didn't see a mechanism for specifying overrides for  
default grammars though.  I think it would be ideal if this were  
doable at the per-instance level and also per-application level, the  
later possibly via an init param to the grammer servlet.  Speaking of  
which, though I haven't thought through all the way how to implement  
this yet, I suspect we're going to bump head-on into the  
GrammarServlet's dependence on the taglibs-rdc.jar.  Will we have to  
break this up to implement this?  Maybe if it pulled grammars from  
the classpath instead?

Thanks for giving credit for my little wiki page :-).  There will be  
more!  We're just starting to hit stride in design of our first app,  
with many to go.  We have some interesting things planned that should  
stretch RDCs a bit too.  I'll definitely bounce ideas off of the list  
before jumping in then too, but this is enough for now.

Oh, before I forget, I really do need to send you a simple example of  
the jsp forwarding problem with struts-submit.  I'm now redirecting  
between all struts actions so that no more than 1 JSP ever renders  
within a single request.  I understand this works in Tomcat, but WAS  
6.0.1 (haven't applied the 6.0.2 patch yet) the voice interpreter  
errors out with prolog complaints.  Recreating it is pretty simple,  
and you might even hit it with the example apps.  If not, I'll try to  
find time to create a simple example, or maybe just send you  
something offline.  As I mentioned before, my theory is that  
(assuming it isn't "operator error" :-) the spec is vague about what  
happens to the buffer when forwarding through a mechanism other than  
jsp:forward.  At least that's how it read to me a few weeks ago - I  
think I mentioned sections in the last post on the topic.

No biggie for us.  Redirecting works fine, though we'd prefer not to  
do that forever.

Stu

> Stu -
>
> I haven't tried canoo, I'm hoping to soon now, based on your  
> feedback. It
> would be great if you could take your previous email and create a new
> tutorial page on the wiki [
> http://wiki.apache.org/jakarta-taglibs/ReusableDialogComponents/ 
> Tutorials
> ]. You've done all the work for the new tutorial, maybe slap three  
> curly
> brackets around the patch and we should have a very useful wiki  
> page ;-)
>
> Thanks Stu!
> -Rahul
>
> P.S.-I added a line for credits on your TryingOut tutorial, a trivial
> update from me earlier left no indication who the original author  
> was -
> for the casual surfer atleast.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message