[Moo] Re: A "controller" class? How to design really complex functionality.

[Daniel Lohse]

Can we have a look at that "Controller Class"? Please? :)
On 2009-11-05, at 5/November, 12:37 AM, Ryan Florence wrote:

So far this controller class is exactly what the doctor ordered, I guess I just sent the email out to see if I was on the right track.

Like you, I typically have a few classes and connect them through events right there in domready. But on this page those event handlers were getting gruesome, and I don't like seeing that much logic in my domready. I prefer to just create class instances and leave it at that.

Ryan Florence

[Writing TextMate Snippets] ( http://blog.flobro.com/ )

On Nov 4, 2009, at 4:21 PM, evan wrote:

I don't abstract my classes out as far as I have seen Aaron do in some

of the clientcide plugins. I tend to keep each "widget/control" as a
single class and then any interaction that will need to take place
between classes I do through custom events. I usually only need to

create a few events on each class to set up the interactions I need. I

also usually use a domready event to instantiate my classes and make
the connections through the events. If things got a little more
complex I could see moving it in to a controller class.

The complexity of a project has a lot to do on how I end up doing
things. I also change my mind on each project and usually try
something new. I am still hunting for that one solution that I will
use each time.


On Nov 4, 2:09 pm, Ryan Florence <rpflore...@gmail.com> wrote:

Most public facing websites I do are pretty basic, with a handful of

unrelated classes instantiated (a gallery, some menu navigation, maybe

some ajax fun).  You know, a fancy "brochure" website.

But when developing web applications I've ended up either created a do-

everything-class that has tens if not hundreds of methods; or
splitting up each piece of the page into separate classes with a lot
of events used to communicate with each other.

The do-everything-class just feels wrong.

10-20 classes on a page with all sorts of `onWhatever` functions makes

a mess out of my domready code.

Is there a happy medium?  Like a "controller" class?

So I'd instantiate all the classes, and then pass them in to the
controller class and from there define how and when they communicate
with each other?

Simple Example to better illustrate the concept:

A photo gallery has
  1) a carousel full of thumbnails with next and previous buttons

2) and an image viewer that loads an image, zooms in and zooms out.

When a thumbnail is clicked, the image viewer should load the image.

In the end will be some theoretical methods:
  - loadImage
  - next
  - previous
  - zoomIn
  - zoomOut

I could either
  1) create a single class that does everything or
  2) have a class for the image viewer with loadImage, zoomIn, and
zoomOut, and then a carousel class with an onSelect event, used to
send a message to the viewer class to load the correct image.

I'm currently doing number 2 on a project but all the onWhatevers are

starting to drive me nuts and I'm tempted to go back to a do-

everything class. But I just thought about creating a class to handle all the communication between my classes. So I could just pass in the

two class instances (carousel and image viewer) to the controller

class and then define inside there what to do onSelect of a thumbnail.

Is that making sense? Again, the photo viewer is a simple example to

illustrate a problem. I don't need any links to good photo viewers.
Any tips, articles, thoughts?

Ryan Florence

[Writing TextMate Snippets] (http://blog.flobro.com/)