This module has been a long time in the making - the initial commit of the basic functionality was added about 6 months ago when I had just finished working on a JDO based app running on Google App Engine. The module was inspired by the tapestry-jpa module at Tynamo.
JDO as a standard is a curious beast. It was the first attempt at building solid ORM functionality for the Java platform, there were a bunch of solid implementations out there (Apache JDO, Kodo, etc); however, it somehow never managed to catch fire like Hibernate. For a while, at least for me, it felt like the standard was on its way out, giving way to JPA; yet, it keeps coming back: Google App Engine JDO support, MongoDB JDO API through DataNucleus, etc.
In a nutshell, tapestry-routing allows you to provide your own custom mapping between Tapestry pages and URLs.
Did you ever wanted to change the order of the path params in an URL? now you can!
Let's say you have a page: pages.projects.Members which have 2 parameters in its activation context: (Long projectId, Long memberId) and you want the URL for that page to look like /projects/1/members/1 Just add the @At annotation to you page, like this:
tapestry-routing Dispatcher will take care of recognizing incoming requests and dispatching the proper render request
tapestry-routing PageRenderLinkTransformer will do the rest of the work, it will transform every Link for a page render request formatting it according to your route rule.
We really need some feedback, so please give it a try:http://tynamo.org/tapestry-routing+guide
TYNAMO-74 - Support inline Facebook oauth permission screen
Here's what Alejandro (the co-founder of Tynamo) had to say about the module:
I don't know if we should release this module, It's so easy to use that's not fair for people that suffered the Facebook nightmare. I want people to suffer as I DID!!! Damn it Kalle!! Excellent work!
Also check out the live example of federatedaccounts. Enjoy!
Notice how above I first blamed the browsers for not solving the problem, but then ended up sharing the blame with OAuth. That's because a) the UI redressing problem is not specific to OAuth and b) UI redressing is a super-tricky problem to solve. Simply displaying the URL of an iframe (even if browser assisted) is not nearly enough because that too can be easily redressed (see more at http://www.webmonkey.com/2008/10/a_look_at_the__clickjacking__web_attack_and_why_you_should_worry/). Browser developers do are trying to do something about the problem but they just don't agree on exactly what is the right measure (see e.g http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016286.html).
To improve usability without asking for user's credentials in the same Oauth authorization dialog, Facebook could potentially allow passing a one-time valid user authentication token with the Oauth request, but in some ways that would only shift the responsibility somewhere else. There's an open standard for that as well, called OpenID, and you can by all means use OpenID together with OAuth as demonstrated by Google . Unfortunately though, the window redressing attack is just as big of a problem for OpenID as it is for OAuth. Since OpenID was originally meant for authentication only (though the attribute extensions make it partly an authorization technique) you cannot shift the responsibility any further. I'm not advocating the use of hybrid OpenID+Oauth model either - it may just increase complexity without improving user experience. However, we may be throwing the baby out with the bath water by never allowing Oauth dialogs to be shown in iframes. Certainly the authorization server has to be able to authenticate the end user one way or another, but handling an Oauth callback in an iframe is perfectly secure if you never ask the user's password in the same dialog. Anyhow, with the current standards there's no way out without major security implications, so browsers and ultimately, newer standards need to provide a better, more secure solution.
With 600 million users and counting, it's the new Internet. Yes, I'm talking about Facebook. Whether you love it or hate it, these days you have to have a Facebook strategy. Every other site is doing Facebook, Twitter and Google integrations and why not, your fledgling little website wouldn't need more than 1/1000th of their users to make it a success. So why is that everybody needs to suffer on their own through implementing various versions of Oauth & other open authorization standards? With that suffering in mind, tynamo-federatedaccounts, a module for supporting remote authentication and merged (federated) authorization, was born.
I've been using various versions of more specialized implementations of the same concept before, but tynamo-federatedaccounts is the first attempt at generalizing Oauth & similar work flows to an easy-to-use package. The module is based on Tynamo's tapestry-security, a stable and well-maintained security package based on Apache Shiro for Tapestry5 applications. At this point, I'm looking for early user feedback for the current implementation and APIs. I've put together a simple, live demonstration to showcase it. Also check out the documentation for tynamo-federatedaccounts.
I'm happy to announce that Pierce T. Wetter has joined the ranks of Tynamo. Of course, as one of the original contributors to tapestry-jpa, he's not really a new committer, but hey we'll take it, so welcome on board Pierce! In regards to JPA, I believe we have some quite exciting stuff to introduce in the coming months.
Lately, I've had noticeably more people asking me about Tapestry and why one should choose it over the other (Java) web frameworks. To me, Tapestry is a good compromise, just like Java is. Linus Torvalds, my fellow country man, has famously said "performance almost always matters". There are so many aspects to web development, and performance is often seen as one of the smallest of your problems because in the end "it always comes down to the database". However, a high performing framework solves many other problems. Today, a typical, reasonably well-implemented Java web application on a modest hardware can serve hundreds of concurrent requests, thousands of concurrent users and tens of thousands of users a day from a single server. Most start-ups never need to worry about the scaling out problem until they actually have the money to pay for it. Unfortunately, you can also easily make the implementation horribly slow, suffering from scalability problems from the get-go and even more unfortunately, it's easier to go wrong with some Java frameworks than with others. For what Tapestry offers, the performance of the framework itself, both in terms of cpu and memory consumption is simply phenomenal. Performance matters.
However, I really don't want to make this post about Tapestry's performance. As soon as you mention one thing about a particular framework, people tend to place it in that category and forget about everything else. What I really like to give as an answer to people who ask why one should use Tapestry is this: because it is well-balanced and comprehensive. There are a lot of other web frameworks that are optimized with a certain thing in mind and in that narrow field, they typically beat the competition. It's difficult though to be a good all-around contender but that's exactly what Tapestry is all about. Tapestry doesn't force you to a certain development model - such as using sessions, always post, single url, ajax-only, thick RIA etc. If you just need to handle a specific case, such as building a single-page, desktop-like application for web, you could pick GWT, Flex or Vaadin, but if you are a building a generic, mixed static/dynamic content site with multiple pages you'd undoubtedly pick entirely different set of tools. Tapestry though, is an "enabling" technology - you could use it together with all three aforementioned RIA frameworks. You could also use and people have used Tapestry-IoC alone in non-web desktop applications. Not a whole lot of other "web" frameworks can claim suitability for such diverse use cases. Sadly, comprehensiveness of a framework can be a somewhat difficult area to objectively compare so each framework usually resorts to toting their best features to prove their superiority over others.
One criteria I personally use a lot in comparing effectiveness of competing solutions is their expressiveness and succinctness. Now, everybody knows that Java is a butt-ugly language (though it makes up on other departments, like performance and comprehensiveness). Today's Java is far from your grandfather's Java a few years back and Tapestry makes the best use of the more advanced, modern JVM techniques available today, such as bytecode manipulation, annotation-based meta programming and introspection without reflection. Tapestry code is purposefully remarkably succinct. Minimal effort required for creating Tapestry components makes it easy to refactor your application logic into reusable elements, rather than having to repeat yourself. Patterns in object-oriented languages are a well studied and accepted principle, but only a few (IoC) frameworks besides Tapestry IoC manages to have a framework level support for implementing common ones, such as chain of command, strategy and pipelines.
For Tynamo, I've said it before but I just don't think we could have achieved the same CRUD functionality with any other framework. Certainly anything can be done, but the cost of it would have both been far higher and we would have needed to build much more infrastructure. When we moved from Tapestry 4 to Tapestry 5 (and from Trails to Tynamo), it was amazing to see how we were able to simplify our implementation and remove huge amounts of code while keeping the concept unchanged and making it all more modular at the same time. Using a different stack, you could probably get closest to what tapestry-model is with a combination of Wicket and Spring, but allowing the same level of extensibility would undoubtedly be more cumbersome. Back in Trails, we actually had one person working on a pure Spring (MVC + core) implementation of the same concept but it died a slow death. As the documentation states, tapestry-model produced "default model is highly customizable, you can change pretty much anything you need, and make the changes specific to type, page or instance - a feature that very few other CRUD frameworks offer". The big difference is that when you need to customize the model, you don't have to rewrite it all, you'll be just customizing the pages and overriding components as needed.
Perhaps we've gone a bit overboard with modularity, but since it's just that simple with Tapestry, most of our modules are independently usable but seamlessly work together in the same web application as soon as you add them to the classpath. Today, Tynamo is much more than just tapestry-model, the CRUD framework. Tapestry-security, tapestry-conversations and tapestry-resteasy are all steadily gaining popularity and based on the page views, it seems that tapestry-security is poised to become our most popular module offering at some point. On that note, I have a few new supplemental modules for tapestry-security coming up which should be of interest to others as well, but more on that in a separate post. For now, I hope I've been able to give some answers to why at Tynamo, we think we've made the right choice with Tapestry and I'm confident that 2011 will be the best year yet both for Tapestry and Tynamo!
What's that? Did the little Tynamo elf just leave an early Christmas gift for all the Tapestry people who have been so good boys and girls the whole year? Indeed, Tynamo is announcing one more module, tynamo-archetype 0.1.0 this year before focusing on our own wish list. It seems fitting that we released our very first Tynamo archetype just a year ago and now, 0.1.0 is all ready to go with tynamo-model 0.1.0, T5.2.x and other bells and whistles. Read more from Quick start.
Enjoy! We'll take a little break from announcements now, see you again around T5.3
Hey, wouldn't it be great if you could just reload your RESTful service classes live while developing them? Oh that's right, that's exactly what tapestry-resteasy 0.2.1 allows you to do! This is T5.2.x specific maintenance release, updating the JAX-RS dependency to JBoss' resteasy GA release 2.0.1. Read more at tapestry-resteasy guide.
- TYNAMO-64 - Live Class Reloading for REST services
Ta daa! This time we are announcing a dual release of tapestry-security, versions 0.2.1 for T5.1.x and 0.3.0 for T5.2.x! Probably not much of a surprise anymore as I've hinted at numerous occasions about the new releases but announcing still has its place since major dependencies changed. Most importantly, these versions pull in and integrate with Apache Shiro 1.1.0, the first Shiro release as a top level Apache project. I'm also happy to report that some of Tynamo-born annotations made their way to Shiro core so tapestry-security doesn't need to supplement Shiro annotations with our own extensions anymore. If you were using previous tapestry-security releases, you are advised to upgrade immediately as there were some security vulnerabilities in Shiro 1.0.0-incubating (which don't directly affect tapestry-security but you should still upgrade).
Tapestry-security 0.3.0 uses the brand new T5.2.4, the best Tapestry release yet. 0.2.1 and 0.3.0 are functionally equivalent, the only difference is that 0.3.0 moved onto newer APIs (thanks Massimo) and we started using some T5.2 features in the tests ourselves. Testament to the backwards compatibility of Tapestry 5.x, tapestry-security 0.2.1 will work for T5.2 just the same but it pulls in T188.8.131.52 and is tested against that version. Both versions will be maintained going forward but 0.3.x will start using more of T5.2 features in the future. Read more at tapestry-security guide. Release notes are for both versions except for TYNAMO-66:
- TYNAMO-56 - tapestry-security sources missing from central repo
- TYNAMO-61 - tynamo-security: bypass security check during application start
- TYNAMO-66 - Update tapestry-security to use T5.2.x APIs
- TYNAMO-55 - Rewrite ShiroExceptionHandler for T5.2
- TYNAMO-62 - Update tapestry-security to use Shiro 1.1.0 APIs
Tynamo project is at it again, this time bringing you tapestry-model 0.1.0 release! If you've followed the development of tapestry-model or even (gasp!) using it, you already know that this release marks a major step forward, laying the groundwork for making the module even more customizable and flexible in a variety of use cases. This release is tested with T5.2.2 and going forward, development of tapestry-model will focus mostly on supporting and utilizing features of T5.2.x. Read more at http://tynamo.org/tapestry-model+guide
- TYNAMO-12 - The Composition component creates duplicates if
the parent/child relationship is implemented following the Hibernate
- TYNAMO-13 - Can't use more than one Composition component per page.
- TYNAMO-16 - Enums annotated with @NotNull are showing the blank option.
- TYNAMO-27 - EditComposition component doesn't know know how to
deal with enum types
- TYNAMO-32 - byte-blobs are not working
- TYNAMO-45 - The Blob component throws an exception when
rendering the Show page
- TYNAMO-6 - Create a Tapestry annotation DescriptorDecorator
- TYNAMO-17 - Implement our own BeanModelSource
- TYNAMO-20 - The archetype should work out of the box with any
IDE and without any mvn commandos.
- TYNAMO-21 - Document how to remove the "tapestry-model-web" dependency
- TYNAMO-26 - The palette for @OneToMany should show only