Did something not work when you tried the snapshot build of 4.1?
I think jwebunit uses httpunit which uses Rhino (ie mozilla ) to handle the javascript testing. Tapestry uses Rhino to test javascript now as well, but we code directly against the rhino api. HttpUnit and others have tried (unsuccessfully ) to mimick the behaviour of the containing window / browser that the js interpreter runs in but none have done a good job of it so far. (Except for the browsers themselves of course ;) ) If you had any issues with something running in a real browser I'd be very interested in hearing them asap. For unit testing I think we've decided to have a sub/seperate special maven distro/project site hosting all of the tapestry testing goodies publicly for people to use as well. (With some sort of caveat stating that we can/will change any portion of the testing stuff as much as we want, but will try to give fair warning..Ie not a public facing API sort of thing, just being nice to the community.) This should give you the ability to test all of your java code with java code (ie TestNG / junit ) and test your javascript code in javascript (via our rhino unit test infrastructure, which I've yet to port to a maven plugin) On 7/5/06, Aslak Grønflaten <[EMAIL PROTECTED]> wrote:
Thanks for a good answer. Obviously, my experience with tacos and tapestry 4.1 are extremely limited, so it's good to hear more of what's going on. My concern arose from trying out a snapshot of 4.1, and seing that standard components such as LinkSubmit use Dojo, thus seeming to depend on it. Also, it's not just browser compatibility I'm worried about. I'm also using jwebunit to test my applications, and it's javascript interpreter (Neko I think it's called?) also needs to be compatible, if I'm to continue doing this. Aynway, I'm sure I've just been too eager to try out the very latest, and that by the time of a release my worries will be needless. A On Jul 5, 2006, at 11:47 AM, Jesse Kuhnert wrote: > That's an understandable viewpoint. > > Safari hasn't traditionally had very good support/implentation of > some of > the core JS api . (that is required to be ecma compliant at least). > They > have fixed this in more recent versions of safari but it's > something the > dojo dev's are still trying to support as much as possible. > > The good news is that no one has to use the new JS features if they > don't > want to, and the ones that are used by default in some sections are > all > cross browser compliant. > > As for standardizations, I know a few companies/projects that might > not > agree with you; > > - IBM > - Sun Microsystems > - AOL > - Every web based framework hosted on apache. (if I've missed > knowing any > then apologies, I'm speaking more to the core JSF/struts/webwork type > frameworks) > - Many other big wigs that would take too much time to hunt down > and list.. > > The official list of supported browsers can be found here: > http://dojo.jot.com/FAQ#Supported%20Browsers. I should also note > that the > dojo foundation/devs are in direct contact with the mozilla/IE > teams to try > and ensure more industry wide browser compatibility/improvements in > general. > > > That being said, I definitely don't want to ignore browser > compatibility > issues when they come up and will definitely react quickly to any > bugs that > are found. (as long as they are humanly reasonable, expecting <= ie > 5.0support or any of the earlier safari versions probably isn't going > to > happen.) > > People really don't have too much to worry about as any of the more > dynamic > functionality is something people can choose to "opt in" for. > > Of course, since tapestry uses hivemind this is all a moot point. > If you > ~do~ want the dynamic features but would rather use something other > than > dojo then you have the choice of specifying your own "ResponseBuilder" > configuration point. I've re-factored all of this logic and any of the > existing javascript handling so that people can plug in their own > handles > and manage as much of this process as they would like. Choice is > always a > good thing :) As much as I love dojo I don't want to code myself > (or the > community) into a hole we can't get out of easily if it's decided > to move to > a different toolkit someday. > > Hope that helps :) If anyone would like more answers I can probably > pull one > of the dojo devs or the sun servlet spec lead people in to answer > to things > I can't.
-- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
