I'll be kicking off my participation in the No Fluff Just Stuff symposium series this year on Sunday April 6th. I'll be talking about Tapestry, testing and design patterns.
I'm especially looking forward to the Tapestry session, of course, as I have so much more to say on Tapestry this year than last. But I also enjoy the testing talks (it's a pair of talks), perhaps because I'm not as emotionally invested in EasyMock and TestNG as I am in Tapestry.
I've been rapidly closing the gap between where Tapestry 5 is and where it needs to be for a stable release.
Today I added in index pages; literally, pages named Index.
In the past, you could create a Start page and it would be used for any request that just specified the servlet context but didn't identify a specific page. That was great ... at the top level. It's also supported for backwards compatibility (even I am not that cruel).
However, the preferred method is to call that page Index. Further, you can place Index pages in subfolders as well. Tapestry can reference such a page using just the folder name.
That's great so far, but nobody wants to have a bunch of classes with the same name, even in different folders. No problem; the standard "name stripping" occurs. Thus, you might have an ecommerce application and three pages : com.myco.pages.order.OrderIndex, com.myco.pages.order.OrderVerify and com.myco.pages.order.OrderSubmit. The names of these three pages will be "order/Index", "order/Submit" and "order/Verify" (the redundant parts are stripped out). Lastly, Tapestry will create URLs of the form ".../context/order", ".../context/order/submit" and ".../context/order/verify".
In other words, short, sensible URLs and no compromises in your code. And, as always, any extra path info beyond the page name is treated as page activation context, made available to the page via the "activate" event handler method.
I'm very happy with this change; I also think Tapestry's built-in rules for URLs are really strong and appealing; I simply don't see customizing the built-in rules to be a priority, or frankly, of any great value.
Tapestry 5 features continue to come together rapidly; the latest is HTTPS support.
It's very simple: mark a page as secure ...
@Secure
public class ProcessOrder
{
. . .
}
... and Tapestry takes it from there. Every request for that page will automatially use an HTTPS protocol URL. Any attempt to circumvent HTTPS will result in an HTTPS redirect; there's no way to access the page without HTTPS. Links from a secure page to an insecure page use the standard "http" protocol ... so Tapestry handles the whole cycle, from insecure to secure and back again.
That's about it; behind a firewall there's a little bit more configuration to allow Tapestry to know how to properly build the complete URL (the URL with protocol, server name and maybe port) since (behind a firewall) the servlet API doesn't properly report the information the way the client web browser needs it.
I'm hitting a bit of a quandary with response to testing: I'm losing some faith in unit testing, or at least busywork unit testing relative to integration testing.
At issue is the way Tapestry is constructed; there's a lot of small moving parts that work together (integrate together might give you some foreshadowing). Sometimes testing the small pieces won't accomplish much. Case in point:
public class SecureWorker implements ComponentClassTransformWorker
{
public void transform(ClassTransformation transformation, MutableComponentModel model)
{
Secure secure = transformation.getAnnotation(Secure.class);
if (secure != null)
model.setMeta(TapestryConstants.SECURE_PAGE, "true");
}
}
This piece of code looks for the @Secure annotation on a component class, and records a bit of meta data that will be used elsewhere.
In the past I've written a chunk of tests even for something as simple as snippet; Following that pattern, I'd write two tests: 1) what if the annotation is missing? 2) what if the annotation is present? I'd use mock objects to ensure that the correct methods of the correct dependencies are invoked in each scenario. However, to write those tests, even leveraging existing base classes to manage the mock objects I'd need, would require several times as much test code as the production code I want to test.
But what would that prove? This bit of code will be useless without a large number of other pieces yet to be written: code that uses that meta data and forces the use of secure HTTPS links and so forth. Code that integrates this worker into the chain of command for processing component classes. Code that verifies that requests for pages that are marked as secure are, in fact, secure.
In other words, to verify the behavior I need to validate that all of those pieces are working together, that they are all integrated.
That doesn't mean I'm calling for the abandonment of unit tests. What I'm saying is that pointless unit tests don't accomplish much. I've found that unit tests are invaluable for testing edge cases and error conditions. Even the most rabid test driven pundits don't expect you to unit test your accessor methods ... I think tiny classes like this SecureWorker fall under the same general umbrella. I intend to focus my efforts on the integration tests that will encompass this code in concert with other code. And maybe write a few unit tests along the way, as long as they actually have value.
Update: It's not that I can't write the test, it's that doing so is not always worth the effort. Here's a similar test I wrote in the past:
public class SupportsInformalParametersWorkerTest extends InternalBaseTestCase
{
@Test
public void annotation_present()
{
ClassTransformation ct = mockClassTransformation();
MutableComponentModel model = mockMutableComponentModel();
SupportsInformalParameters annotation = newMock(SupportsInformalParameters.class);
train_getAnnotation(ct, SupportsInformalParameters.class, annotation);
model.enableSupportsInformalParameters();
replay();
new SupportsInformalParametersWorker().transform(ct, model);
verify();
}
@Test
public void annotation_missing()
{
ClassTransformation ct = mockClassTransformation();
MutableComponentModel model = mockMutableComponentModel();
train_getAnnotation(ct, SupportsInformalParameters.class, null);
replay();
new SupportsInformalParametersWorker().transform(ct, model);
verify();
}
}
Great: this detects whether @SupportsInformalParameters is on the class ... but I have other integration tests that actually stress the behavior when the annotation is present and when the annotation is absent. Ultimately, that tests both of these cases, and the code that ensures that this code is even executed, and the desired behavior of the component (with and without the annotation). Failures are unlikely to occur in this code, but likely in other code. What is the value of this test? Not even code coverage, and the integration tests hit both cases already.
I've been doing a lot of work using Prototype for the Ajax support in Tapestry 5. I use Prototype because it is generally easy to use, easy to bundle with Tapestry and reasonably well documented.
I've been gradually using new features as I need them and as I grow more comfortable with Prototype. I just started using some custom events (related to synchronizing some data when a form is submitted).
Here's an important note: custom events, used with the fire() function must contain a colon. this.form.fire("prepareforsubmit") will do nothing. this.form.fire("form:prepareforsubmit") will properly invoke observers. This is not yet documented, though the ironically named blog Painfully Obvious clued me in.
Well over a year ago, I had to start moderating comments on this blog, due to a couple of (or more likely, a single) pathetic individual(s) who were using the comments feature in an attempt to upset me with derogatory comments about Tapestry and about myself. Let's call this person "Jed". Jed is truly wierd and sad ... that anyone would find this kind of harrassment appropriate points to an injured and emotionally crippled mind.
Today I got back to my desk to see the latest comment from this twit ... and he'd gone nuclear: he made remarks about my wife.
That goes far past merely sad, and deep into the desperate and cowardly. I've been posting articles, blogs and comments for over ten years and have never posted anything anonymously. And where I have attacked a technology before, and even made statements I later regret, I've always done so openly and honestly. Jed hides behind anonymity to cause injury he would in no way dare make in person.
I have no problems with criticisms of Tapestry or myself because I have appropriate faith in my technical acumen and accomplishments. But I would never, even in jest, stoop to the levels this lowlife scumbag has taken.
The best course of action is just to ignore him, as I do when he writes inflammatory mails on the Tapestry mailing lists. I won't gratify his deplorable need for attention by going into more detail about who he is or what he wrote. But someone out there may actually know "Jed" and should take him aside and tell him to act like an adult, or at least, not like a baboon.
The Develop in Java web site has a short review of Alexandar's book. They liked it:
I liked this book and found the writing style to be informative and easy to read. If you have little or no knowledge of Tapestry 5 and you are interested in it (or just want to decide if you should be using it for your applications), then this is the book for you.
I've been mentally compiling a few tiny rough edges in IntelliJ. The difference between IntelliJ and Eclipse is that I can use IntelliJ's JIRA, add an issue, an expect a response. Every time I've done this, I've gotten a response in a couple of hours, either pointing out an existing fix, confirming my problem, or pointing out an alternative solution. I just don't get that feeling with Eclipse ... most bugs I've entered over the years into their Bugzilla system have never been resolved to my satisfaction.
And Bugzilla in general? That's pretty much raising the bar against anyone who doesn't have a high tolerance for wierdness and frustration.
Update: Case in point, I can respect their reasoning even if I don't agree, and I got a response in four minutes.