Forum: Ruby on Rails Application Design

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Jules J. (Guest)
on 2006-01-14 14:53
Hi Railsers,

How do you design your applications? Do you start coding HTML? Start
with the controllers/models? Start in a program like
photoshop/gimp/illustrator/inkscape?

I start in inkscape, it's a SVG editor. I sketch all the views of my
application, and then I create the views that belong to one controller
in RHTML. After that, I do the models/controller, and move on to the
next set of views.

How do you do create your applications?

Jules
Jarkko L. (Guest)
on 2006-01-14 22:01
(Received via mailing list)
On 14.1.2006, at 14.53, Jules J. wrote:

> Hi Railsers,
>
> How do you design your applications? Do you start coding HTML? Start
> with the controllers/models? Start in a program like
> photoshop/gimp/illustrator/inkscape?
>
> I start in inkscape, it's a SVG editor. I sketch all the views of my
> application, and then I create the views that belong to one controller
> in RHTML. After that, I do the models/controller, and move on to the
> next set of views.

Hey Jules,

That's a perfectly valid order and promoted by 37signals, too. Maybe
put writing the tests after your views are ready and you'll be
übercool, doing both test driven [1] and sketch first [2]
development ;-)

//jarkko

[1] http://www.43things.com/things/view/7384
[2] http://www.43things.com/things/view/35612
Gregory S. (Guest)
on 2006-01-16 19:55
(Received via mailing list)
On Sat, Jan 14, 2006 at 01:53:05PM +0100, Jules J. wrote:
} Hi Railsers,
}
} How do you design your applications? Do you start coding HTML? Start
} with the controllers/models? Start in a program like
} photoshop/gimp/illustrator/inkscape?
}
} I start in inkscape, it's a SVG editor. I sketch all the views of my
} application, and then I create the views that belong to one controller
} in RHTML. After that, I do the models/controller, and move on to the
} next set of views.
}
} How do you do create your applications?

I design the database first, sometimes with an ER diagram and sometimes
with straight SQL DDL. I'm a firm believer in getting the data model
right
(or very close to right) before coding on top of it. I'm also a firm
believer in using the right tool for the job, so I make a point of using
the database schema for what RDBMSs do best (i.e. data integrity such as
foreign key constraints). I'll generally set up a separate rails test
app
with just scaffolding to test and play with the schema.

Once I'm moderately confident of my schema, I use rails to create the
models. I don't use the scaffolding for a real app, since I find that
it's
pretty pointless to have one controller per model and with some
regularity
there is a need for a controller or two that has nothing to do with a
single model. I'll use rails to generate my controllers, then add stub
action methods by hand. (This assumes that I've already figured out
roughly
what operations, a.k.a. controller actions, the user will need.)

I then start adding business logic to the model classes. If I had the
discipline for TDD, I'd also be writing tests for the business logic.
There
is sometimes value to creating standalone business object classes that
deal
with one or more models, but my needs are usually met by putting the
business logic directly in the model. Once I feel like all of the
business
logic for some action is implemented, I'll write the respective
controller
method. Again, if I had the discipline for TDD, I'd be writing tests for
the actions as well. I'll work on a rough draft of the action's view at
this point as well, with the intention of making it pretty later.

When I speak of a rough draft of a view, that doesn't mean sloppy HTML.
It
means simple, concise HTML with essentially no formatting elements
(divs,
spans, class attributes, styles, etc.). Non-AJAX JavaScript is also
saved
for later. Once I'm done with the functionality, the views get my full
attention, including a single, app-wide stylesheet and occasional
controller-specific stylesheets. If possible, I try to use the same
layout
for the entire app.

When I draw stuff for design, it tends to be on a whiteboard. If it is
intended to become documentation, however, I'll manually copy from the
board into xfig.

} Jules
--Greg
James B. (Guest)
on 2006-01-16 20:29
(Received via mailing list)
Gregory S. wrote:
>
> I design the database first, sometimes with an ER diagram and sometimes
> with straight SQL DDL. I'm a firm believer in getting the data model right
> (or very close to right) before coding on top of it.


Interesting.  Unless the data model is, in essence, the application
(e.g., the typical "show my catalog of stuff on the web" sort of thing)
I prefer to start with behavior and class responsibility, and have that
drive what data are needed, and where, and how/what data need to be
stored.

And that process usually starts with use cases and the UI.

But everything tends to evolve based on user feedback and the friction
between what looked reasonable in the abstract and how well it works
when actual humans are poking around.


James B.

--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
Mufaddal K. (Guest)
on 2006-01-16 20:53
(Received via mailing list)
I have often found that regardless of the technology it is important to
work on the design by getting a good understanding of the use cases and
then start creating the database model and laying that out. Getting the
database normalized is eventually an incremental process that changes
and grows as the needs of your application changes (ie different use
cases being added or removed etc).

My two cents on this is to work on this incrementally from both sides
(the two sides being the persistence layer and the view layer).
matthew clark (Guest)
on 2006-01-17 03:01
(Received via mailing list)
I like to start with a database layout too, but I go for the minimalist
approach here as well.  Agile development demands that you do only what
is
necessary to make the current test pass.  If that means having a cusomer
table with just an "id" and "name" field, so be it.  With TDD its easy
to
flush out the db design as work progresses.  There will be time to add
address, phone, and bra size later.

The idea is to hold off making structure decisions until the last
possible
minute.  Once a data schema is set, it tends to be very inflexible.  I
want
to always leave the maximum amount of flexibility in place.

Example - does the "first name", "last name" fields go in the customer
table, or the credit card table, or both?  I've built apps all three
ways,
and untill you've gotten a lot of use cases, flushed out those cases,
and
even rewritten them with the user, it can be difficult to know which one
is
proper.
Lance B. (Guest)
on 2006-01-17 03:01
(Received via mailing list)
On 1/16/06, Mufaddal K. <removed_email_address@domain.invalid> wrote:
> I have often found that regardless of the technology it is important to
> work on the design by getting a good understanding of the use cases and
> then start creating the database model and laying that out. Getting the
> database normalized is eventually an incremental process that changes
> and grows as the needs of your application changes (ie different use
> cases being added or removed etc).
>
> My two cents on this is to work on this incrementally from both sides
> (the two sides being the persistence layer and the view layer).

I'm working on a project now where I'm trying out a completely new
approach (for me anyway).  It's based loosely on the some of the ideas
presented in Joe Gregorio's column on how to develop a REST-ful API
(http://www.xml.com/pub/a/2004/12/01/restful-web.html)

The hope is that by designing my application with a similar process,
it will help to make it much easier to expose it via a web service or
REST api.

First, I started with the domain model.  I know fairly well what the
schema should look like, and what the relationships should be.  So, I
create models using

    ./script/generate model Thingy

And I start writing tests for the model to ensure that I've got the
relationships correct, etc.

For the controllers, I have an OmniOutliner document (but you could do
it with plain text just as easily) with 4 columns - this is where I'm
stealing from the REST ideas.

Action:  This is something like "Create a new thingy" or "Get all
widgets associated with thingy"
Representation:  This is the URI for the Action, e.g. /thingy/show/[id]
Tested: A checkbox, checked if an Action has been written and tested
Method: GET, POST, DELETE or PUT

Then I create a controller (by hand as opposed to generating it, but I
suppose I could do either), and a controller test and I start doing
TDD.

I walk through the outline, and for each action in the outline I write
a test, and implement the action.  For the views, at this point, I
don't care what they look like at all.  I just know that on the "Get
thingy" action I need a div that represents the thingy, so I test for
this:

<div class='thingy' id='thingy_<%= @project.id %>'>
...
</div>

With something like this:

    assert_tag(:tag => 'div',
               :attributes => {
                 :class => 'thingy',
                 :id => 'thingyt_' + thingys(:first).id.to_s})

If I get to a controller action which requires something I haven't
implemented or considered in my domain model, I go back to that and
start writing unit tests.

It seems to be going OK so far.  I'm a little worried that I'm not
doing enough "assert_tag" assertions, so I might be missing something.
 But as a process it seems to be working.

Lance
--
Lance B.
http://lance.langwell-ball.com
Jens A. (Guest)
on 2006-01-21 16:40
(Received via mailing list)
37signals have written some good articles about application design.
And I've heard they use Rails ;-)
	http://getreal.37signals.com/

There are actually a lot more posts on the topic that aren't linked
to on that page. Their blog doesn't appear to have a search field,
but you can go to the archives
	http://www.37signals.com/svn/archives.php
and search the page for "getting real".
This topic is locked and can not be replied to.