Hugh Sasse
11/11/2008 10:22:00 AM
On Tue, 11 Nov 2008, Adam Akhtar wrote:
> Hi thanks for the replies. I looked into MVC and i think its proably
> overkill for what im doing and probably stretching my abilities too far
It only needs to be a really simple controller.
> at this stage though does look like a good pattern. One think I dont
> understand is what the controller would actually do in my case where im
> just using the command line. I feel like i only need a model and then a
It would take requests from the UI and only access the database when it
needs to. It will handle the business logic of what gets added and
removed. The UI would concentrate on how stuff looks to the user.
The idea, as you said that you want to get the hang of OO, is that each
class has a well-defined role. If two classes are in each other's pockets
then that is not good, because a change in one means a change in the other.
If two becomes 8, then this gets truly horrible.
The code that handles the money in your bank shouldn't care what cheques
look like when they are printed. But you want some logic in there that
handles what goes to a cheque when it's printed. If the bank decides
that cheques should have a blue background this year, rather than yellow,
then you don't want to change the code that sends the amounts to the
cheque printer.
> view/controller wrapped into one.
>
> Well ive decided to just scrap mvc and just get the thing working. I
> created two classes. One is a database class which wraps up kirbybase (a
> flat file db plugin for ruby) and the second is basically the U.I i.e.
> menu logic, getting input and presenting menus and stuff.
>
> Im just not sure how to code their communication to each other.
That communication is the role of the controller.
>
> class DB
> ..
> ..
>
> def insert (task)
> ...
> #some kirybbase calls here.
> ..
> end
>
> end
>
>
> class UI
>
> blahblahblah
>
> def menu
> puts "|A| to add a task"
> ...
> ...
> end
>
This bit below goes in your controller. It's a DB, so you will want to handle
Create, Read, Update, Delete for the tasks. That's probably enough to start
with, and Read and Update mean you'll need to search for tasks, so that
means you'll need to Tell the UI to display them.
> def navigation
> menu
> input = gets.chomp
> case input
> when "A"
> add task
> etc
> etc
> etc
> end
>
>
>
>
> def add_task
new_task = UI.new_task_form
DB. add_task(new_task)
> end
>
> def add_task_to_db(new_task)
> **what goes here?
# Nothing, it's already in the DB code. Isn't it?
> end
>
This bit belongs in the UI
> def new_task_form
> puts "Enter title for task"
# don't put this here: new_task = Task.new
> # new_task.title = gets.chomp
> # return new_task
# You just want the UI to return a bunch of fields. the controller
# can validate them, and tell the UI: UI.bzzzt("Try again!").
> end
>
> in add_task_to_db Im wondering the best way to pass the new_task
> completed in the UI object over to my db object. Is there someway to let
You don't, you just pass the possibly dodgy data back from the UI to
the controller. The controller checks before it stuffs a load of spam
into the DB.
> the db class see the value of new_task? Should i be using an observer
> pattern here? Should they be observing one another (if possible?)?
I don't think you need obsverver if the controller controls what is happening.
It will sequence which bits of UI show up. It might get errors from the
DB when you ask about all those tasks you didn't get round to adding. Then
it will have to tell the UI to display error messages, rather than task
lists.
>
> Im probably overlooking somthing dead simple here but im way confused.
>
> any help most appreciated.
>
HTH
Hugh