Play Framework 2.0 Beta & integration into Typesafe Stack(groups.google.com) |
Play Framework 2.0 Beta & integration into Typesafe Stack(groups.google.com) |
I believe we have one of the largest Play code bases. And I still enjoy it.
I picked it out of a line up, I tested Django, Rails, Cake, Java EE and buncha other stuff. I had just a month to pick a platform and budget limits for 4 staff and 2 years. So far I only needed just a gfx designer and I still do all coding myself.
Ask me anything about Play.
Why not a Clojure stack ? Is Play itself, or Scala ?
I didn't do Clojure because I didn't know Java til this year. I last did C++ in 2002, closest language.
- Class reloading magic?
- Hibernate wrapping/hacking?
Some other specific issues you workarounded but feel should be fixed in the framework?
I heavily use its Jobs to keep ajax responsive. I do full-text autocompletion off of Postgres' native seaorch against 65k products. Works great. Its a great piece of software, see chat demo for Comet example.
However, I'm pretty nervous about 2.0, due to the tight coupling with Scala. I still have a bad taste in my mouth from trying to use Lift, and I did not care for sbt at all.
While typesafe templates seem like a good thing, I can't recall ever having bugs that would have been caught by them, and it looks like it will eliminate the magical boilerplate-free parameter passing from the current version of Play.
I would chalk it up to terrible terrible documentation, and being unable to read the example code that I did find due to the Scala practice of using random characters as method names. e.g. something = x % y %% z ||| a
The documentation was really the worst, though. Maybe it's improved in the last year.
Now the complexity of frameworks like Spring and Hibernate drive people away from Java because setting up a simple website is such a chore. It seems like libraries like Play and Stripes aim for the middle ground that makes web platforms like Rails and Django so popular.
Admittedly, they serve different audiences. It seems like frameworks like Play are better aimed at simple public websites and not "enterprise web services" or whatnot. And that's fine.
</pointless-rambling>
This isn't a bad thing as hibernate is an extremely powerful and complete ORM which I trust allot more than any of the half baked ones.
If you want to use hibernate properly I recommend reading "Java Persistence with Hibernate" It explains the framework very well including the logic behind allot of the things that feel strange or over engineered with it.
Play makes Java (or Scala) web development a light and fun experience.
I have two models, with a third model to represent the relationship (can't just use @ManyToMany as the relationship has attributes). The primary key on the relationship model is a composite primary key of two other models. When I add a new relationship model to the @OneToMany set on one of the first models, can I get the relationship model's key to change automatically, or do I have to do it manually?
e.g. with three models like (psuedo-Java-Scala coming up)
class Order(val customerName)
@OneToMany
Set<OrderItem> items;
class Item(itemDescription)
@OneToMany
Set<OrderItem> orders;
class OrderItem(val quantity)
@Id
@PrimaryJoinColumn
@ManyToOne
Order order;
@Id
@PrimaryJoinColumn
@ManyToOne
Item item;
OrderItem oi;
oi.item = bananas;
order.items.add(oi);
order.save(); // This saves oi, but with a null value for order_id
oi.order = order; //This seems redundant, but the save is wrong without it.
It seems like I have to do it manually, but to my mind adding it to the Set should be enough information to change the keys. Is my thinking wrong or am I using JPA wrong?I implemented my own ORM (http://joist.ws) a few years ago to solve this and my other JPA/Hibernate annoyances. It works really well, modulo the fact that I suck at docs/promotion/etc. so it doesn't have many users (working on that).
Also note that, specific for the playframework, someone seems to have implemented the necessary magic in a plugin:
http://www.playframework.org/modules/associations
Which is nifty, other than I'm slightly wary of the "magic that happens via runtime class rewriting" that seems to be Play's standard way of doing things. The results are admittedly impressive, but it seems like you're coupling yourself to yet-another-runtime-environment/container for things to work right.
Hibernate is generally far more concerned with being flexible and robust than it is with being DRY or providing a perfect database abstraction. You really do still have to think about your data from the point of view of the DBMS regards 'Owning' Associations etc.
One thing with Play! is that it does try to over abstract hibernate a little bit and turn it into ActiveRecord which is fine for simple things but hibernate is not like ActiveRecord!