I have always felt that the only true way to test is live.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thu 8/3/2006 11:53 AM To: Tapestry users Subject: RE: This would be a handy tool hm... won't work. Consider: ognl:visit.user.login Suppose that you're using tap4 and visit is an abstract method, injected in. You'll get an exception since the method is abstract. Suppose you use the abstract instantiator that howard wrote to instaniate the page/component class. Fine... now you'll get a NPE exception since visit won't be injected. So, now let's supposed we load up hivemind and let it work its magic on the injected values... now we're talking about the same sorts of time penalties already incurred from restarting your app. And even then, it wouldn't quite be "right"... Even if visit is injected, user is probably null since no user has logged into the system... and what about objects that are set at runtime in, eg, pageBeginRender? No, there's far too much that requires tapestry to be fully running to be able to execute the ognl directly. About the best that can be done is to make sure that the chain is a valid chain, and that's a matter of verifying the existence of appropriate methods (which, as I mentioned before, is problematic in some (many?) cases). In any event... I'll think on it a bit. Robert > OGNL can be executed directly from java code. So, rather than just > calling the methods, just execute the ognl... That checks the ognl and > the methods at the same time. > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thu 8/3/2006 8:03 AM > To: Tapestry users > Subject: Re: This would be a handy tool > > That would be an awesome tool. I've been thinking about some sort of > utility along those lines, especially since I've been revamping a ton of > templates in the last few days (to use less ognl)... it would probably be > worth my time to create something like this... at the very least some sort > of "dynamic property verifier". There are some weird/fringe cases, > though, that would be really nasty to handle... things like: > > <!-- this is fine, but... --> > <div jwcid="@RenderBlock" block="ognl:components.block" > param1="ognl:someProperty"/> > > <div jwcid="[EMAIL PROTECTED]"> > <span jwcid="@Insert" > value="ognl:components.block.inserter.bindings['param1'].object.foo.bar.baz"/> > </div> > > The insert value would be problematic: the system wouldn't know what type > of object param1 is because the the value "inserter" isn't known until > runtime. Granted, such an ognl call would be better as: ognl:value, where > value does all of the "heavy lifting" in java to cut down on the > reflection required to insert a simple value. But the point is that there > are these fringe cases that are essentially impossible to resolve, except > at runtime. The tool could possible verify as much as it can verify, and > then you the user would be notified of not only the errors, but also the > "unverifiables" (like the insert value above). Thoughts? > > Robert > >> I don't know about you folks, but the permgen space thing causes me to >> reload my app server all the time (the time lost waiting for >> startup/shutdown is matched by the time gained by being able to enable >> caching, i think), and spring/hivemind initialization takes a fair >> while these days. >> >> One of the things I've noticed about Tapestry is that I spend an >> enormous amount of my time tracking down silly little template syntax >> errors which cause runtime exceptions, and this is made worse by the >> turnaround time of the compile/deploy/test cycle. I don't know if it >> is possible, but it sure would be handy to have a utility which would >> parse a template, generate a java source file with a single method >> that calls every method that will be called by the template. I could >> compile against it and actually let the compiler do its job, instead >> of having to wait for the runtime system to discover a missing method >> (or rather, a typo in an ognl string). >> >> Just a thought. Unfortunately, it seems like the kind of thing that >> wouldn't be terribly high on the developer priorities, but it sure >> would ease my life. >> >> --sam >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
