p1ch1intro.lyx

#LyX 2.0 created this file. For more info see http://www.lyx.org/
\lyxformat 413
\begin_document
\begin_header
\textclass hobo
\use_default_options true
\master hobo.lyx
\begin_modules
logicalmkup
\end_modules
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman default
\font_sans default
\font_typewriter default
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100

\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\float_placement H
\paperfontsize default
\spacing single
\use_hyperref false
\papersize default
\use_geometry false
\use_amsmath 1
\use_esint 1
\use_mhchem 1
\use_mathdots 1
\cite_engine basic
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\use_refstyle 1
\boxbgcolor #e1dde2
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Chapter
Chapter 1 
\begin_inset Newline newline
\end_inset

INTRODUCTION
\end_layout

\begin_layout Section
What is Hobo?
\end_layout

\begin_layout Standard
By Tom Locke
\end_layout

\begin_layout Standard
Hobo is a software framework that radically reduces the required effort
 to develop database-driven, interactive web sites and web-based applications.
 Strictly speaking, it’s more of a “half-framework” — Hobo builds on the
 amazingly successful 
\begin_inset Quotes eld
\end_inset

Ruby on Rails
\begin_inset Quotes erd
\end_inset

 and that’s where much of the functionality comes from.
 The motivation for the Hobo project can be summed up with a single sentiment:
 “Do I really have to code all this stuff up again?"
\end_layout

\begin_layout Standard
In other words Hobo is about NOT re-inventing the wheel.
 In software-engineer-speak, we call that 
\begin_inset Quotes eld
\end_inset

code reuse
\begin_inset Quotes erd
\end_inset

.
 If you mention that term in a room full of experienced programmers you’ll
 probably find yourself the recipient of various frowns and sighs; you might
 even get laughed at.
 It all sounds so simple - if you’ve done it before just go dig out that
 code and use it again.
 The trouble is, the thing you want to do this time is just a bit different,
 here and there, from what you did last time.
 That innocuous sounding “just a bit different” turns out to be a twelve-headed
 beast that eats up 150% of your budget and stomps all over your deadline.
 Re-use, it turns out, is a very tough problem.
 Real programmers know this.
 Real programmers code it up from scratch.
\end_layout

\begin_layout Standard
Except they don’t.
 Ask any programmer to list the existing software technologies they drew
 upon to create their Amazing New Thing and you had better have a lot of
 time to spare.
 Modern programming languages ship with huge class libraries, We rely on
 databases that have unthinkable amounts of engineering time invested in
 them, and our web browsers have been growing more and more sophisticated
 for years.
 Nowadays we also draw upon very sophisticated online services, for example
 web based mapping and geo-location.
 We add features to our products that would otherwise have been far beyond
 our reach.
\end_layout

\begin_layout Standard
It turns out the quest for re-use has been a great success after all—we
 just have to change our perspective slightly, and look at the infrastructure
 our application is built on, rather than the application code.
 This is probably because our attitude to infrastructure is different—you
 like it or lump it.
 If your mapping service doesn’t provide a certain feature, you just do
 without.
 You can’t dream of coding up your own mapping service and having some maps
 is better than no maps.
 
\end_layout

\begin_layout Standard
\begin_inset Flex Emph
status collapsed

\begin_layout Plain Layout
We’ve traded flexibility for reach, and boy is it a good trade.
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Programmers get to stand on the shoulders of giants.
 Small teams with relatively tiny budgets can now successfully take on projects
 that would have been unthinkable a decade ago.
 How far can this trend continue? Can team sizes be reduced to one? Can
 timelines be measured in days or weeks instead of months and years? The
 answer is yes, if you are willing to trade flexibility for reach.
\end_layout

\begin_layout Standard
In part, this is what Hobo is about.
 If you’re prepared for your app to sit firmly inside the box of Hobo’s
 “standard database app”, you can be up and running with startlingly little
 effort.
 So little, in fact, that you can almost squeeze by without even knowing
 how to program.
 But that’s only one part of Hobo.
 The other part comes from the fact that nobody likes to be boxed in.
 What if I am a programmer, or I have access to programmers? What if I don’t
 mind spending more time on this project? 
\end_layout

\begin_layout Standard
We would like this “flexibility for reach” tradeoff to be a bit more fluid.
 Can I buy back some flexibility by adding more programming skills and more
 time? In the past this has been a huge problem.
 Lots of products have made it incredibly easy to create a simple database
 app, but adding flexibility has been an all-or-nothing proposition.
 You could either stick with the out-of-the-box application, or jump off
 the “scripting extensions” cliff, at which point things get awfully similar
 to coding the app from scratch.
\end_layout

\begin_layout Standard
This, we believe, is where Hobo is a real step forward.
 Hobo is all about choosing the balance between flexibility and reach that
 works for your particular project.
 You can start with the out-of-the box solution and have something up and
 running in your first afternoon.
 You can then identify the things you’d like to tweak and decide if you
 want to invest programming effort in them.
 You can do this, bit by bit, on any aspect of your application from tiny
 touches to the user-interface all the way up to full-blown custom features.
\end_layout

\begin_layout Standard
In the long run, and we’re very much still on the journey, we hope you will
 never again have to say “Do I really have to code all this up again?”,
 You’ll only ever be coding the things that are unique to this particular
 project.
 To be honest, that’s probably a bit of a utopian dream, and some readers
 will probably be scoffing at this point—you’ve heard it all before.
 But if we can make some progress, any progress in that direction, that’s
 got to be good, right? Well, we think we’ve made a ton of progress already,
 and there’s plenty more to come!
\end_layout

\begin_layout Subsection*
Pre-Hobo
\end_layout

\begin_layout Standard
A brief look at the history leading up to Hobo might be helpful to put things
 in context.
 We’ll start back in ancient times — 2004.
 At that time the web development scene was hugely dominated by Java with
 its “enterprise” frameworks like EJB, Struts and Hibernate.
 It would be easy, at this point, to launch into a lengthy rant about over-engin
eered technology that was designed by committee and is painful to program
 with.
 But that has all been done before.
 Suffice it to say that many programmers felt that they were spending way
 to much time writing repetitive “boilerplate” code and the dreaded XML
 configuration files, instead of focusing on the really creative stuff that
 was unique to their project- not fun and definitely not efficient.
\end_layout

\begin_layout Standard
One fellow managed to voice his concerns much more loudly than anyone else,
 by showing a better way.
 In 2004 David Heinemeier Hansson released a different kind of framework
 for building web apps, using a then little-known language called Ruby.
 A video was released in which Hansson created a working database-driven
 Weblog application from scratch in less than 15 minutes.
 That video was impressive enough to rapidly circulate the globe, and before
 anyone really even knew what it was, the Ruby on Rails framework was famous.
\end_layout

\begin_layout Standard
Like most technologies that grow rapidly on a wave of hype, Rails (as it
 is known for short) was often dismissed as a passing fad.
 Five years later the record shows otherwise.
 Rails is now supported by all of the major software companies and powers
 many household-name websites.
\end_layout

\begin_layout Standard
So what was, and is, so special about Ruby on Rails? There are a thousand
 tiny answers to that question, but they all pretty much come down to one
 overarching attitude.
 Rails is, to quote its creator, opinionated software.
 The basic idea is very simple: instead of starting with a blank slate and
 requiring the programmer to specify every little detail, Rails starts with
 a strong set of opinions about how things should work, conventions which
 “just work” 95% of the time.
 “Convention over Configuration” is the mantra.
 If you find yourself in the 5% case where these conventions don’t fit,
 you can usually code your way out of trouble with a bit of extra effort.
 For the other 95% Rails just saved you a ton of boring, repetitive work.
\end_layout

\begin_layout Standard
In the previous section we talked about trading flexibility for reach.
 Convention over configuration is pretty much the same deal: don’t require
 the programmer to make every little choice; make some assumptions and move
 swiftly on.
 The thinking behind Hobo is very much inspired by Rails.
 We’re finding out just how far the idea of convention over configuration
 can be pushed.
 For my part, the experience of learning Rails was a real eye-opener, but
 I, immediately, wanted more.
\end_layout

\begin_layout Standard
I found that certain aspects of Rails development were a real joy.
 The “conventions”—the stuff that Rails did for you—were so strong that
 you were literally just saying what you wanted, and Rails would just make
 it happen.
 We call this “declarative programming”.
 Instead of spelling out the details of a process that would achieve the
 desired result, you just declare what you want, and the framework makes
 it happen.
\end_layout

\begin_layout Standard
The trouble was that Rails achieved these heights in some areas, but not
 all.
 In particular, when it came to building the user interface to your application,
 you found yourself having to spell things out the long way.
\end_layout

\begin_layout Standard
It turned out this was very much a conscious decision in the design of Ruby
 on Rails.
 David Heinemeier Hansson had seen too many projects bitten by what he saw
 as the “mirage” of high-level components:
\end_layout

\begin_layout Standard
\begin_inset Box Shaded
position "t"
hor_pos "c"
has_inner_box 1
inner_pos "t"
use_parbox 0
use_makebox 0
width "90col%"
special "none"
height "1in"
height_special "totalheight"
status open

\begin_layout Plain Layout
\begin_inset Flex Emph
status collapsed

\begin_layout Plain Layout
I worked in a J2EE shop for seven months that tried to pursue the component
 pipe dream for community tools with chats, user management, forums, calendars.
 The whole shebang.
 And I saw how poorly it adapted to different needs of the particular projects.
\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Flex Emph
status collapsed

\begin_layout Plain Layout
On the surface, the dream of components sounds great and cursory overviews
 of new projects also appear to be “a perfect fit”.
 But they never are.
 Reuse is hard.
 Parameterized reuse is even harder.
 And in the end, you’re left with all the complexity of a Swiss army knife
 that does everything for no one at great cost and pain.
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Standard
I must say I find it easy to agree with this perspective, and many projects
 did seem, in hindsight, to have been chasing a mirage.
 But it’s also a hugely dissatisfying position.
 Surely we don’t have to resign ourselves to re-inventing the wheel forever?
 So while the incredibly talented team behind Rails has been making the
 foundations stronger, we’ve been trying to find out how high we can build
 on top of those foundations.
 Rather than a problem, we see a question — why do these ideas work so well
 in some parts of Rails but not others? What new ideas do we need to be
 able to take convention over configuration and declarative programming
 to higher and higher levels? Over the last couple of years we’ve come up
 with some pretty interesting answers to those questions.
\end_layout

\begin_layout Standard
In fact one answer seems to be standing out as the key.
 It’s been hinted at already, but it will become clearer in the next section
 when we compare Hobo to some other seemingly similar projects.
\end_layout

\begin_layout Subsection*
The Difference
\end_layout

\begin_layout Standard
There are a number of projects out there that bear an external resemblance
 to Hobo.
 To name a few, in the Rails world we have Active Scaffold and Streamlined,
 The Python language has Django, a web framework with some similar features.
\end_layout

\begin_layout Standard
All of them (including Hobo) can be used to create so called “admin interfaces”.
 That is, they are very good at providing a straightforward user-interface
 for creating, editing and deleting records in our various database tables.
 The idea is that the site administrator, who has a good understanding of
 how everything works, does not need a custom crafted user-interface in
 order to perform all manner of behind-the-scenes maintenance tasks.
 A simple example might be editing the price of a product in a store.
 In other words, the admin interface is a known quantity: they are all largely
 the same.
\end_layout

\begin_layout Standard
Active Scaffold, Streamlined, Django and Hobo can all provide working admin
 sites like these with very little or even no programming effort.
 This is extremely useful, but Hobo goes much further.
 The big difference is that the benefits Hobo provides apply to the whole
 application, not just the admin interface, and this difference comes from
 Hobo’s approach to customization.
\end_layout

\begin_layout Standard
Broadly speaking, these “admin site builder” projects provide you a very
 complete and useful out-of-the-box solution.
 There will be a great number of options that can be tweaked and changed,
 but these will only refine rather than reinvent the end result.
 Once you’ve seen one of these admin-sites, you’ve pretty much seen them
 all.
 That’s exactly why these tools are used for admin sites - it generally
 just doesn’t matter if your admin site is very alike any other.
 The same is far from true for the user-facing pieces of your application—those
 need to be carefully crafted to suit the needs of your users.
 
\end_layout

\begin_layout Standard
Hobo has a very different approach.
 Instead of providing options, Hobo provides a powerful parameterization
 mechanism that lets you reach in and completely replace any piece of the
 generated user-interface, from the tiny to the large.
\end_layout

\begin_layout Standard
This difference leads to something very significant: it gets you out of
 making a difficult all-or-nothing decision.
 An admin site builder does one thing well, but stops there.
 For every piece of your site you need to decide: admin interface or custom
 code? With Hobo you can start using the out-of-the-box UI as a rough prototype,
 and then gradually replace as much or as little as you need in order to
 get the exact desired user experience.
\end_layout

\begin_layout Standard
Again, we find ourselves back at the original idea: making a tradeoff between
 flexibility and reach.
 The crucial difference with Hobo, is that you get to make this trade-off
 in a very fine-grained way.
 Instead of all-or-nothing decisions (admin-site-builder vs.
 custom-code), you make a stream of tiny decisions.
 Should I stick with Hobo’s automatically generated form? Sidebar? Button?
 How long would it take me to replace that with something better? Is it
 worth it?
\end_layout

\begin_layout Standard
There is a wide spectrum of possibilities, ranging from a complete out-of-the-bo
x solution at one end to a fully tailored application at the other.
 Hobo lets you pick any point on this spectrum according to whatever makes
 sense right now.
 Not only that but you don’t have to pick a point for the app as a whole.
 You get to make this decision for each page, and even each small piece
 of each page.
\end_layout

\begin_layout Standard
Let's get back to the question: “How can the ideas of declarative programming
 be taken to higher and higher levels?”.
 We mentioned before that one answer to this question is crucial: The approach
 we have taken to customization.
 It’s not what your components can do.
 It’s how they can be changed that matters.
 This makes sense—software development is a creative activity.
 Developers need to take what you’re giving them and do something new with
 it.
\end_layout

\begin_layout Standard
It is this difficulty of customization that lies at the heart of concerns
 with high-level components.
 David Heinemeier Hansson again:
\end_layout

\begin_layout Standard
\begin_inset Box Shaded
position "t"
hor_pos "c"
has_inner_box 1
inner_pos "t"
use_parbox 0
use_makebox 0
width "90col%"
special "none"
height "1in"
height_special "totalheight"
status open

\begin_layout Plain Layout
\begin_inset Flex Emph
status collapsed

\begin_layout Plain Layout
…high-level components are a mirage: By the time they become interesting,
 their fitting will require more work than creating something from scratch.
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Standard
The typical story goes like this: you need to build something that “surely
 someone must have done before?”; you find a likely candidate - maybe an
 open-source plugin or an application that you think you can integrate;
 then as you start the work of adjusting it to your needs it slowly becomes
 apparent that it’s going to be far harder than you had anticipated.
 Eventually you end up wishing you had built the thing yourself in the first
 place.
\end_layout

\begin_layout Standard
To the optimist however, a problem is just an opportunity waiting to be
 taken.
 We’re hitting a limit on the size of the components we can build—too big
 and the effort to tailor them makes it counter-productive.
 Turn that around and you get this.
 
\begin_inset Quotes eld
\end_inset

If you can find a way to make customization easier, then you can build bigger
 components.
 If it’s the “fitting” that’s the problem, let’s make them easier to fit!
\begin_inset Quotes erd
\end_inset

 That’s exactly what we’re doing.
\end_layout

\begin_layout Subsection*
The Future
\end_layout

\begin_layout Subsubsection*
Bigger library
\end_layout

\begin_layout Standard
Obviously the whole point in discovering the secrets of how to build high-level
 components, is to build high level components! In other words there are
 two distinct aspects to the Hobo project: getting the underlying technology
 right and then building some cool stuff with it.
 Hobo 1.3 will ship with a decent library of useful “building blocks” to
 get your app up and running quickly, but there’s so much more to see.
 This is where the magic of open-source needs to come into play.
 The better Hobo gets, the more developers will want to jump on-board, and
 the bigger the library will grow.
\end_layout

\begin_layout Standard
Although the underlying framework is the most technically challenging part
 of the project, in the long run there’s much more work to be done in the
 libraries.
 Writing the code is just part of the story.
 All these contributions will need to be documented and catalogued, too.
 
\end_layout

\begin_layout Standard
We’ve started putting the infrastructure in place with “The Hobo Cookbook”
 website (
\begin_inset CommandInset href
LatexCommand href
target "http://cookbook.hobocentral.net"

\end_inset

) - a central home for both the “official” and user-contributed documentation.
\end_layout

\begin_layout Subsubsection*
Performance improvements
\end_layout

\begin_layout Standard
It would be remiss not to mention that all these wonderful productivity
 gains do come at a cost - a Hobo application does have an extra performance
 overhead compared to a “normal” Rails application.
 Experience has shown it’s not really a big problem - many people are using
 Hobo to prototype, or to create a very niche application for a small audience.
 In these cases the performance overhead just doesn’t matter.
 If you do have a more serious application that may need to scale, there
 are well known techniques to apply, like prudent use of caching.
\end_layout

\begin_layout Standard
This argument is pretty much the same as that told by early Rails coders
 to their Java based critics.
 It’s much better to save a ton of development time, even if it costs you
 some of your raw performance.
 The time saved can be used to work on performance improvements in the architect
ure of the app.
 You, typically, end up with an app that’s actually faster than something
 built in a lower-level, “faster” language.
\end_layout

\begin_layout Standard
From another perspective—it was four or five years ago that Rails was getting
 a lot of pushback about performance.
 In those four or five years, Moore’s Law has made our servers somewhere
 between five and ten times faster.
 Since Rails was fast enough in 2005, Hobo is, certainly, fast enough today.
\end_layout

\begin_layout Standard
Having said all that, it’s always nice to give people more performance out-of-th
e-box and postpone the day that they have to resort to app-specific efforts.
 Just as Rails has focused a lot on performance in the last couple of years,
 this is definitely an area that we will focus on in the future.
\end_layout

\begin_layout Subsubsection*
Less magic
\end_layout

\begin_layout Standard
One of the most common criticisms leveled against Hobo is that it is “too
 magic”.
 This usually comes from very experienced developers who like to know exactly
 how everything works.
 Because Hobo gives you so much out-of-the-box, initially you’ll be scratching
 your head about where it all comes from.
 Fortunately, this is just a matter of the learning curve.
 Once you’ve oriented yourself, it’s pretty easy to understand where the
 various features come from and where to look when you need to customize.
\end_layout

\begin_layout Standard
As Hobo has developed, we’ve definitely learned how important it is to make
 things clear and transparent.
 The changes from Hobo 0.7 to 0.8 removed a great deal of hard-to-understand
 “magical” code, a trend that will continue.
 We’re very confident that future versions will be able to do even more
 for you, while at the same time being easier to understand.
 It’s a challenge—we like challenges!
\end_layout

\begin_layout Subsubsection*
Even higher level
\end_layout

\begin_layout Standard
One of the really interesting things we’ve learnt through releasing Hobo
 as open source, has been that it has a very strong appeal to beginners.
 It is very common for a post to the “hobo users” discussion group to start
 “I am new to web programming” or “This is my first attempt to create a
 web app”.
 With Hobo people can see a finished result is within their reach, a powerful
 motivator!
\end_layout

\begin_layout Standard
Now that we’ve seen the appeal to beginners, it’s really interesting to
 find out how far we can push.
 We’ve already seen simple Hobo applications created by people that don’t
 really know computer programming.
 Right now, these people are really rather limited, but perhaps they can
 go further.
\end_layout

\begin_layout Standard
Hobo has ended up serving two very different audiences: experienced programmers
 looking for higher productivity, and beginners looking to achieve things
 they, otherwise, couldn’t.
 Trying to serve both audiences might sound like a mistake, but, in fact
 it captures the essence of Hobo.
 Our challenge is to allow the programmer to choose his or her own position
 on a continuous spectrum from “incredibly easy” to “perfectly customized”.
\end_layout

\begin_layout Standard
Hopefully this introduction has whetted your appetite and you’re keen to
 roll up your sleeves and find out how it all works.
 While this section has been a bit on the philosophical side, the rest of
 the book is eminently practical.
 From now on we’ll dispense with all the highbrow pontificating and teach
 you how to develop stuff.
 Enjoy!
\end_layout

\begin_layout Section
Fundamentals
\end_layout

\begin_layout Standard
The Hobo developers have taken the DRY (Don’t Repeat Yourself) paradigm
 to a new level by identifying repetitive architectural patterns in data-driven
 web sites and particularly within Rails applications.
 
\end_layout

\begin_layout Itemize
Rapid implementation of dynamic AJAX interfaces in your application with
 no extra programming.
 Switchable themes.
 Customize and tweak your application structure and layout to meet any design
 goals.
\end_layout

\begin_layout Itemize
Powerful mark-up language, DRYML, combines rapid development with ultimate
 design flexibility.
 
\end_layout

\begin_layout Standard
The DRY paradigm is about finding the right 
\begin_inset Flex Emph
status collapsed

\begin_layout Plain Layout
level of abstraction
\end_layout

\end_inset

 for the building blocks of an application in order to reduce cookie-cutter
 repetitive programming.
 
\end_layout

\begin_layout Standard
Rails starts with a Model-View-Controller (MVC) architecture built with
 Ruby code, using the Ruby metaprogramming power.
 
\end_layout

\begin_layout Standard
Hobo takes this paradigm further and in two directions.
 It provides rapid prototyping with modules that provide an integrated user
 login and permissions system, automated page generation, automated routing,
 built-in style sheets, and an automated database migration and synchronization
 system.
 Hobo also provides a powerful markup language called DRYML that provides
 an almost limitless method for building custom tags at ever-higher levels
 of abstraction.
\end_layout

\begin_layout Standard
Sometimes these patterns are at a very high level such as the need for a
 user login capability and othertimes they are at a lower level such the
 requirement to grab a set of records for display.
\end_layout

\begin_layout Standard
The Hobo framework philosophy is that many of the features of a data-driven
 site should be able to be declared and need no other coding, at least for
 the first set of iterations.
 Let’s take a database query as an example.
 The developers of Rails realized that many queries had similar structures
 and therefore there should be no need to code complex SQL queries.
 Rails implements find methods to deal with this challenge.
 But—in the view template—you still need to write the code to loop through
 the records when you need to display them.
\end_layout

\begin_layout Standard
Hobo views writing this kind of code as a ubiquitous repetitive pattern.
 This, Hobo allows you to declare that you want to display a collection
 of records in a single command.
\end_layout

\begin_layout Standard
As we have mentioned many times before, Hobo provides a new language called
 DRYML (Don’t Repeat Yourself Markup Language) to develop menus, views,
 forms, and page navigation.
 The components of DRYML, as you would expect, are tags.
 Hobo comes with a library of predefined DRYML tags called the Rapid Tag
 Library.
 This library is used to render the default menus, pages, and forms you
 have used in the tutorials.
 
\end_layout

\begin_layout Subsection*
Levels of Abstraction 
\end_layout

\begin_layout Standard
As we discussed above, finding the right level of abstraction in implementing
 coding constructs is the key to programming productivity and application
 maintainability.
 But anyone who has ever coded knows that programming is a messy business.
 Sometimes it is just easier to code at a low level of abstraction.
 This is the dominant way of developing applications today.
 It is simpler not to create reusable components or snippets because something
 always seems to need changing.
 You think you will waste more time fixing your components than just starting
 over.
\end_layout

\begin_layout Standard
The approach that Rails takes, and Hobo even more so, is to have code that
 lets multiple levels of abstractions coexist in the code.
 This is potentially the best of both approaches.
 
\end_layout

\begin_layout Standard
\begin_inset Flex Emph
status collapsed

\begin_layout Plain Layout
Build higher and higher levels of abstraction in your tool set but maintain
 the ability to code at a detail level for development flexibility.
 
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Wherever possible, Hobo provides additional capabilities over Rails for
 declaring what you want rather than forcing you to write procedural code.
 It is therefore important to understand what is going on procedurally behind
 the scenes in both Rails and Hobo so you know what to do.
 
\end_layout

\begin_layout Standard
In this chapter we will emphasize which component--model, view or controller--is
 doing what, and when it is doing it.
 We will also emphasize what the various Hobo constructs are doing and how
 within the architecture of Rails.
\end_layout

\begin_layout Standard
We are going to go through the Hobo approach at a couple of levels but first
 we will list them and give a brief introduction.
\end_layout

\begin_layout Standard
Now we are going to approach the major topics at a shallow level first and
 then circle back and go in deeper after we get a few things out of the
 way first.
\end_layout

\begin_layout Section
Rails and Hobo
\end_layout

\begin_layout Standard
Hobo
\begin_inset Index idx
status open

\begin_layout Plain Layout
Hobo
\end_layout

\end_inset

 is a set of Rails plug-ins, which means that Hobo adds additional custom
 code to Rails, and coexists with Rails.
 So, essentially a Hobo application is a Rails application with additional
 capabilities.
 However, these additional capabilities are substantial, and can be conceptualiz
ed into two categories: 
\end_layout

\begin_layout Enumerate
Operational (“Run Time”) Enhancements 
\end_layout

\begin_layout Enumerate
Developer Tool Enhancements
\end_layout

\begin_layout Standard
\begin_inset Flex Strong
status collapsed

\begin_layout Plain Layout
Operational Enhancements.
\end_layout

\end_inset

 Take a look at the data flow for a typical operating application built
 with a Model-View-Controller (MVC) framework:
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\noindent
\align center
\begin_inset Graphics
	filename figures/figure1.png
	width 90col%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
Data flow for a typical Application using a MVC framework
\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

\end_layout

\end_inset


\end_layout

\begin_layout Standard
Now let’s look at how Rails and Hobo fit into the MVC framework:
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\noindent
\align center
\begin_inset Graphics
	filename figures/figure2.png
	width 90col%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
Data flow for a Rails application
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\noindent
\align center
\begin_inset Graphics
	filename figures/figure3.png
	width 90col%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
Data flow for a Hobo application
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Standard
Here are a few talking points:
\end_layout

\begin_layout Itemize
The Hobo Model Controller
\begin_inset Index idx
status open

\begin_layout Plain Layout
Hobo Model Controller
\end_layout

\end_inset

 takes the place of the Action Controller in Rails.
 
\end_layout

\begin_layout Itemize
The Hobo Model Controller has access to information from both Hobo Permissions
 and Hobo Lifecycles that allow it to decide what should be displayed and
 for whom.
 
\end_layout

\begin_layout Itemize
\begin_inset Index idx
status open

\begin_layout Plain Layout
Hobo Rapid
\end_layout

\end_inset

Hobo Rapid pages are rendered using DRYML, which is passed to the DRYML
 “processor” that translates more declarative DRYML into standard Rails
 eRB (embedded Ruby) that is then rendered with Action View in Rails.
\end_layout

\begin_layout Section
Hobo Enhancement
\begin_inset Index idx
status open

\begin_layout Plain Layout
Hobo Enhancement
\end_layout

\end_inset

 Summary
\end_layout

\begin_layout Subsubsection*
Fields
\begin_inset Index idx
status open

\begin_layout Plain Layout
Hobo Fields
\end_layout

\end_inset

 
\end_layout

\begin_layout Standard
A big difference between Hobo and Rails is that in Hobo fields are declared
 in the model, whereas in Rails they are declared in the migrations.
 In our opinion it is more intuitive and DRY to maintain all of the model
 code in one place, creating or changing the database design by editing
 the 
\begin_inset Flex Emph
status collapsed

\begin_layout Plain Layout
model
\end_layout

\end_inset

, letting Hobo build the migration code necessary to make any required changes.
 You can look in one place to see everything about a model.
 You don’t need to jump to the 
\begin_inset Flex Code
status collapsed

\begin_layout Plain Layout
schema.rb
\end_layout

\end_inset

 file.
\end_layout

\begin_layout Standard
The Hobo “resource” generator creates models, controllers, and views:
\end_layout

\begin_layout LyX-Code
\begin_inset Flex Strong
status collapsed

\begin_layout Plain Layout
> hobo generate resource
\end_layout

\end_inset

 [parameters]
\end_layout

\begin_layout Standard
Any changes to field definitions or associations in the model can be propagated
 throughout the application with the Hobo “migration” generator:
\end_layout

\begin_layout LyX-Code
\begin_inset Flex Strong
status collapsed

\begin_layout Plain Layout
> hobo generate migration
\end_layout

\end_inset

 [parameters]
\end_layout

\begin_layout Standard
There is no need to edit the migration file.
 The migration generator handles this for you.
\end_layout

\begin_layout Standard
If you only need to create a model without other resources, use the Hobo
 model generator:
\end_layout

\begin_layout LyX-Code
\begin_inset Flex Strong
status collapsed

\begin_layout Plain Layout
> hobo generate model
\end_layout

\end_inset

 [parameters]
\end_layout

\begin_layout Subsubsection*
Indexes
\begin_inset Index idx
status open

\begin_layout Plain Layout
Database Index
\end_layout

\end_inset

 
\end_layout

\begin_layout Standard
This is one of the newest additions to Hobo thanks to Matt Jones.
 This feature provides for automatic field generation for the foreign keys
 of related models, and an easy-to-use declarative syntax to specified single
 and multi-part keys with a model definition.
\end_layout

\begin_layout Subsubsection*
Validations
\begin_inset Index idx
status open

\begin_layout Plain Layout
Validations
\end_layout

\end_inset

 
\end_layout

\begin_layout Standard
As we have discussed elsewhere in the book, Hobo provides some useful in-line
 shortcuts for the simplest validations that Rails does not provide.
 See in red below:
\end_layout

\begin_layout LyX-Code
\begin_inset Box Shadowbox
position "t"
hor_pos "c"
has_inner_box 1
inner_pos "t"
use_parbox 0
use_makebox 0
width "100col%"
special "none"
height "1in"
height_special "totalheight"
status open

\begin_layout LyX-Code
fields do 
\end_layout

\begin_layout LyX-Code
  name :string, 
\color red
:required, :unique, :length => 32 
\end_layout

\begin_layout LyX-Code
end 
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Use standard rails validations outside the 
\begin_inset Flex Code
status collapsed

\begin_layout Plain Layout
fields…do
\end_layout

\end_inset

 block.
 This works the same as in Rails so we will not add anything new at this
 point.
\end_layout

\begin_layout Subsubsection*
Views 
\end_layout

\begin_layout Standard
Views take the most time to develop in any application and Hobo provides
 more tools here than in the other two modules to meet that challenge.
 In fact, it provides an entire language to use to develop view templates
 (a Rails web page).
\end_layout

\begin_layout Standard
Hobo views are developed entirely differently than in Rails.
 Once you define your models and controllers, Hobo is capable of automatically
 generating an entire set of views on the fly.
 This means that at the beginning of your development process you do not
 have to code a view template at all.
 Hobo automatically creates them whenever the user requests that data be
 rendered.
\end_layout

\begin_layout Paragraph*
DRYML Tags.
 
\end_layout

\begin_layout Standard
Hobo constructs view templates using Hobo’s mark-up language, called Don’t
 Repeat Yourself Markup Language.
 The tags are reusable components that perform specific processes defined
 in Ruby.
 
\end_layout

\begin_layout Standard
You build DRYML tags using a definition language and you use the tags to
 build data-driven view templates in an XML-like syntax.
 You can create your own tags and build tags from other tags.
 Hobo comes with its own library of fundamental tags called the Rapid Library.
\end_layout

\begin_layout Standard
For those of you with a Rails background, you can think of these as similar
 to Rails "helpers", but they are used with an easier XML syntax rather
 than with [Ruby embedded in the templates.]
\end_layout

\begin_layout Paragraph*
\begin_inset Index idx
status open

\begin_layout Plain Layout
Rapid Tag Library
\end_layout

\end_inset

Rapid Tag Library.
 
\end_layout

\begin_layout Standard
This library is a set of tags that deal with all aspects of view template
 specification.
 It includes tags for links, forms, input controls, navigation, logic and
 much more.
 They are DRYML tags in that they are defined with the DRYML definition
 language.
 Many rapid tags call other Rapid tags implicitly.
 For example, you may never see a Rapid <input> called explicitly in the
 auto-generated tags described below.
 
\end_layout

\begin_layout Paragraph*
\begin_inset Index idx
status open

\begin_layout Plain Layout
Rapid Generator
\end_layout

\end_inset

Rapid Generator.
 
\end_layout

\begin_layout Standard
This generator is a real time generator as opposed to the code generators
 we usually talk about in Rails development.
 Rapid creates a set of auto-generated tags that are defined by model fields
 and model relationships.
 Rapid uses these auto-generated tags to render individual view templates.
\end_layout

\end_body
\end_document