Message-ID: <1056747008.20108.1406778419805.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_20107_1742122258.1406778419804" ------=_Part_20107_1742122258.1406778419804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Tynamo's mission is to provide implementations for different asp= ects of a full web application stack that offer reasonable out-of-= the-box functionality and are easy to customize. We are intent on proving t= hat web applications based on Java can simultaneously be high perfo= rming, easy to implement and fun to develop. We leverage existing = technologies where possible and provide integrations with proven, clean and= compact libraries rather than limit ourselves only to standard Java (JSRs)= . Tynamo is both comprehensive and modular so you are free to choose the pa= rts you like from our full stack. And finally, we like Tapestry and our mod= ules use Tapestry IoC extensively.=20 =20
+ issues on the github milestone 0.4.0.=20
For release notes, I'm thinking in the future I'm just going to link to = the Github milestone for the release. Let's practice: tapestry-routing 0.1.0 milestone.=20
Release Notes - tapestry-security-0.6.0
* [TYNAMO-147] - Make tapestry-security compatible wi= th tapestry-5.4
* [TYNAMO-236] - Migrate tapestry-security to tapestr= y 5.4 beta
** Github issue
#1: Implem= ent a new default CookieRememberMeManager for creating smaller rememberme c= ookies (how do you get "release notes" out from Github?)= =20
The Tynamo Team.=20
Yes, we just might have forgotten to announce "a few" releases= we've made. We got busy, what can you say? Besides our marketing dudes nev= er do anything anyway. Let's start the year with a bang and correct the sit= uation right now (after taking the marketing department behind the shed). H= ere's a recap of the previously unannounced releases we've made in the last= four months:
We finally implemented a built-in full text search. The Hibernate versio= n is using HibernateSearch because it's ah so automatic and nice. Only thin= g is that it's local only. For the JPA version, we fully integrated Elastic= Search, the best thing since full-text bread. I dare say our integration is= better than the one that Play framework has to offer. It seamlessly integr= ates with SQL-based search and is easy to extend. tapestry-model continues = to be better suited only for the more experienced Tapestry users. One day w= e'll write proper documentation for it and surprise you all.
A fix for TYNAMO-183 forced our hand because = of some dependencies on 5.3 so we decided to push out 0.5.0 a bit early. We= 'll get the rest of the improvements in later. We are also dropping support= for T5.0/5.1 but hey it's open source. If you find a bug in the earlier re= leases, send it to us and we'll patch it.
TYNAMO-129, or rememberMe with rollingtokens ma= de it as a new submodule of federatedaccounts. There's just no reason to us= e those puny, insecure and ordinary remember me cookies anymore. More at my= blog post on RememberMe with rolling tokens.
First, the younger JPA version of the well battle-tested seedentity libr= ary pulled next to the hibernate-seedentity, turned her head and waved, the= n sprinted ahead laughing, leaving the hibernate guy sobbing in dust (in te= rms of features).
I still think it's the coolest little library out there and just wouldn'= t be possible to implement without the lovely distributed configuration of = Tapestry. You aren't still modifying your html text content in an offline t= ext editor, are you? Now I just need to integrate conversation and inline i= mage support.
Want to secure your data instances? This one works so well it's annoying= .=20
In the past five years, I worked on a number of greenfield projects.= In three out of four, we ended up choosing Grails - it is very hard to den= y the market & mindshare , the expansive documentation, the big name co= mpany behind the project, the large community, a massive number of plugins = (for pretty much anything that you'd want), the end-to-end stack (so, you d= on't have to choose your ORM, DI, etc) and the ease of getting started with= a Grails project.
However, after working on a couple of these Grails projects for a fe= w years, the latest project I got involved with , I chose Tapestry. In some= cases, I've missed some of the niceties that Grails brings out of the box,= but without too much effort I've been able to replicate them fairly easily= .
The biggest reasons for picking Tapestry over Grails on this latest = project have been:
On the first issue, if you will be using Groovy for your pages, you = will be in the same boat as Grails. Personally, I wouldn't recommend it - T= apestry already pushes the envelope on Java quite a bit, so your Java code = ends up being very short and sweet already. In the past, I had attempted to= use Scala in a tapestry app, and ended up having to just deal w/ some of t= he mismatches between the language and the framework and my pages ended up = looking up like the same old java pages I would have had but with a differe= nt syntax.
On the second issue, there is the grails resources plugin that tries= to pull resources kinda like Tapestry, but using it requires this artifici= al separation into resource bundles which seems to be a PITA and somewhat m= ind bending.
On the abundance of Grails plugins - after using a bunch for the pro= jects I was working on, it turned out that many were not well maintained so= we hadto take over and maintain them ourselves. Sometimes, they're a good = starting point, but in the end ended up less of a factor than I initially t= hought.
I originally very much enjoyed the Grails build system (running on t= op of Gradle); however, with a pretty simple project setup, Maven seems to = bejust as straightforward. If you wanted Gradle, you could use that for you= r Tapestry app, and be on-par w/ Grails.
On the latest project that I chose Tapestry for , I have been very h= appy with my choice. On a few occasions I've run into some frustrations (e.= g. for rendering emails, I ended up having to use Freemarker, whereas with = Grails the template rendering for emails comes for 'free' ; I had to build = my own equivalent of the Grails "console" plugin where you can ru= n Groovy commands inside of your running application); however, in all case= s, the solution has turned out to be more elegant than I had expected (albe= it, it required deeper tweaks in the framework than I had expected).= p>
Persistent login cookies are the cookies that are stored with your b= rowser when you click the "remember me" button on the login form.= I would like to be able to say that such cookies are obselete, and we have= a better way of handling user logins, but they aren't, and we don't.<= /p>
The following recipe for persistent cookies requires no crypto more = powerful than a good random number generator.
With all this in mind, I've always implemented rememberMe based on rolli= ng tokens in the various web applications I've worked on. However, I've nev= er attempted to provide it as a reusable module until one day a few months = ago while I was working on federatedaccounts it hit me: rolling tokens can = be thought of as just another "remote" authentication provider th= at can be federated with the main account. For some months now, we've happi= ly been using tynamo-federatedaccounts-rollingtokens in production. I added= some quick documentation for it at the end of the generic tynamo-federatedaccounts guide= a>, have (secure) fun with it!=20
Release notes, concisely:
Read more at tap= estry-routing guide and enjoy!=20
Read more at tapestr= y-security guide and enjoy,