From: Hugh Sasse <hgs@...>
Date: 2008-11-11T22:02:27+09:00
Subject: Re: implementing mvc - using observer pattern - beginner to OOP

---476953799-728599941-1226408234=:5236
Content-Type: MULTIPART/MIXED; BOUNDARY="-476953799-728599941-1226408234=:5236"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---476953799-728599941-1226408234=:5236
Content-Type: TEXT/PLAIN; charset=utf-8
Content-Transfer-Encoding: 8BIT



On Tue, 11 Nov 2008, Adam Akhtar wrote:

> Thank you so much for your help clearing that up. Im much closer to 
> understanding how things fit together. Id just like to confirm 
> somethings (please dont think im asking you to the write the code for 
> me, im not, i just like to be a bit more certain before writing out 
> lines of code ;-) )
> 
> > 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.
> 
> 
> Ok so I have three classes now.
> DB which encapsulates the DB and all the tables (at the moment there is 
> only one for tasks, in the future Id have anohter for categories, 
> projects etc)
> 
> Task_Controller which handles the menu navigation logic and any logic 
> such as what to do with a task when a user marks it as complete etc. It 
> will have DB related tasks such as Create, Read, Update, Delete.
> 
> Task_UI which will have basically all the output to the screen such as 
> menu text, prompts etc.

Sounds OK to me.
> 
> >From this
> 
> >> def add_task
> >     new_task = UI.new_task_form
> >     DB. add_task(new_task)
> >> end
> 
> Question 1
> it seems your implying my class Task_Controller should define an 
> instance of the DB and the UI within it, is that correct?

Yes, and I should have lowercased those, as they should be instance
methods not class methods.  Having Upppercase variables makes that
unclear.
> 
> Question 2
> Presuming Im correct about that, what is the relationship of the db to 
> the view? When the DB is updated is it the DBs job to inform the view 
> for it to update or does it inform the controller or .... C. do nothing 
> at all　and just let the controller tell the view to update when it 
> thinks its best.

I think there are varying schools of thought on this, because it
depends what is easiest to do.  For your case, I'd go through the
controller.  The controller will ask the DB for info, for updates,
and so on, so it should get the responses.  It may need to filter
the information to pick out the pertinent stuff.  That way you can
change the DB to SQLite3 or whatever later, and only the DB and
controller will be affected, if you've not managed to keep all the
effects inside the DB classes.

IIRC "Head First Design Patterns" (a good book, if you accept the
cognitive psychology that drives the quirky style) I think says that
often the Model (database) can just send stuff to the UI.  But you
are mainly concentrating on separation of concerns for this work, so
unless performance becomes a problem, I'd go through the controller.

> 
> 
> >   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
> 
> ok so i shouldnt create an instance of task in the UI. Rahter just 
> return a bunch of fields (a hash \ array? )which contain the input from 

Yes, you can wrap them into a similar object, but they may not be valid
things to create a real Task.  When do you want this to end: 30-FEB-2009
for example.

> the user and let the controller figure out what each field represents 
> and whether its valid input. The controller will create a Task instance 
> and then pass it to the DB.

Yes
> 
> Question 3
> When the UI presents say a form for a task to the user to fill is it 
> good practice to have things like
> 
> userinput = gets.chomp
> 
> in the UI or should that be handled by the controller. Im wondering to 
> what degree logic and presentation are seperated.

I'd say that's entirely in the court of the UI.  Why? Because it would
do different stuff if it was a web form, Tk dialogue box, interface
operated by a blink-switch ....


        Hugh
---476953799-728599941-1226408234=:5236--
---476953799-728599941-1226408234=:5236--