Web App Frameworks

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