Web App Frameworksaka The Luke and Josh Variety Hour
servlets are terrible• Way too many System.out.println’s
• Tightly coupled
• Umm... sessions
• The ultimate DIY
web frameworks are cool• Fewer System.out.println’s
• Hide the gross stuff (sessions...)
• Lots of free stuff
• Steep learning curve :(
the basics• Model (the stuff)
• View (the pretty face)
• Controller (the middleman)
model (the stuff)• Persistent data
• Trucks, POs, etc.
controller (the middleman)• Pull data / I can has trucks?
• Push data / save the truck’s state
view (the pretty face)• Show the trucks
• Edit the trucks
SeamIt’s pretty cool I guess
seam model• Model = Java object + annotations
• Truck.java
seam controller• Controller = Java object + annotations
• YardController.java
seam view• View = XHTML
• trucks.xhtml
Ruby on RailsWhy it is Always the Right Answer
rails• “Web development that doesn’t hurt.”
• Based very strongly on the Ruby scripting language
• Heavily Object-Oriented
• Dynamic type
• Basically, it’s scripting for the web.
• Well-developed programming paradigm
• Huge community support and documentation
paradigm• RESTful design
• REpresentative State Transfer
• Designs data control into the four natural states of HTTP communication
• Not specific to Rails, just the adopted paradigm
• States: The CRUD Model
UD
• CRUD
• POST
• Create
• GET
• Read
• PUT
• Update/Create
• DELETE
• Delete
• HTTP
• CRUD
• POST
• Create
• GET
• Read
• PUT
• Update/Create
• DELETE
• Delete
• HTTP
• CRUD
• POST
• Create
• GET
• Read
• PUT
• Update/Create
• DELETE
• Delete
HTTP CRUDPOST CreateGET ReadPUT Update/CreateDELETE Delete
paradigm
• Reasons for RESTful design• Clean, meaningful organization• Organized by action• Concise way of sending data• Improves consistency and data integrity• Simplified interface design• Three components
• View data• Create new entry• Edit existing entry
HTTP CRUDPOST CreateGET ReadPUT Update/CreateDELETE Delete
design• How It Looks: an MVC example
• The Model, Part I
design• The Model, Part II
design• The Views
design• The Views: Partials
design• The Views: New
design• The Controller: Part 1
design• The Controller: Part 2
why rails is better
• Single-Source Solution… mostly• Install Ruby and RoR and you’re ready to start.• The total MVC solution is wrapped up in Rails, no need for:
• JBoss framework• Seam• Hibernate• JSF• Richfaces
• This includes JavaScript/AJAX functionality. All Ruby code which is rendered to HTML/Javascript later.
why rails is better• Integration across platform much smoother, all Ruby/Rails code, no
need for other layers.
• Because of this, it’s faster.• More control over finer details of:
• Server environment• Development or Production
• Database setup – lots of options• Optimization – lots of opportunities for this
• Large number of plugins• Can get a bit over-the-top if not careful.
downfalls• Still gaining adoption on a large scale• Very strict definitions (namely database naming conventions)
• A bad thing?• Optimization is not automatic, programmer needs to do a lot to optimize• Takes smart programming to gain in efficiency
• A bad thing?• Not as many sweet built-in GUI features
Last WordUse Ruby on Rails... it’s amazing
Questions?
references• http://www.seamframework.org/Documentation/GettingStarted• http://livedemo.exadel.com/richfaces-demo/richfaces/message.jsf?s=glassX• http://www.infoq.com/articles/jboss-seam• http://rubyonrails.org/- Ruby on Rails site• http://www.railsbrain.com/ - Rails documentation• http://railscasts.com/ - Rails Tutorials via Screencast • http://railsforum.com/ - Rails help / discussion forum