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]
