> I have always felt that the only true way to test is live.
Certainly. :) Such a tool would in no way eliminate the need to live
testing. It would merely (hopefully) cut down on typos. ;)
Consider, for example, my recent set of refactoring I did.
A lot of stuff like:
ognl:visit.user.login
got cut to:
.html:
ognl:login
.java
public String getLogin() {
return getVisit().getUser().getLogin();
}
The logic hasn't changed one iota; only ognl's involvement has changed. I
did this on lots and lots and lots and lots of pages and components; it
would be nice to have an automated way of verifying I didn't make any
typos in the process. Particularly greivous is the case of multiple typos
on the same page: hit the page, get an exception, fix the problem, hit the
page, get another exception, fix the problem, etc., etc., etc. Having some
automated way of finding all of the typos at once is all I'm really after.
:)
Robert
>
>
> -----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]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
