Blog Categories

Books
Bulgaria News
Computer History
Content Management Systems
Ex-pat Tips
Gov't IT
Iraq
Linux
Interests
My Music
Open Source
Travels
Wireless

MVC notes

From: Lee Borkman [mailto:bjork@bjork.net]
Sent: Tuesday, June 25, 2002 5:33 AM
To: fusebox@topica.com
Subject: Re: Question on MVC



Hi Kevin,


In broad terms, as I understand it...


* Each Model corresponds to a thing/object/entity in the application domain.
* Each Controller corresponds to a category of user
* Each View corresponds to a category of presentation (eg, HTML, Flash)


The Controller functions are those things that a User will want the
application
to do.  These Controller functions are implemented by calling Model
functions to
read/write data, and View functions to present the results in an appropriate
format.


It has been argued before that Fusebox is an inherently MVC-like approach.
You
can consider fuseactions to be Controller functions, qry_ fuses are the
Model
functions, and dsp_ fuses are the View functions.  In the MVC approach that
Hal
has been writing about, Controller fuseactions are implemented by calling
Model
and View *fuseactions*, instaed of mere Model and View fuses.  This allows a
stricter separation of Model, View and Controller functions, by giving them
their own distinct circuits.


In other words, Fusebox already provides much of the separation of
responsibility that an MVC pattern gives.  You can, if you wish, go a step
further, as Hal is suggesting, and implement MVC explicitly using FB3 and an
intelligent division of circuits.  You will find this kind of approach
further
increases the power and scalability that you already get from using Fusebox.


Does that make any sense?


LeeBB




----- Original Message -----
From: Kevin Roche 




> Hi,
>
> I am trying (and failing) to get my head around the MVC model.
>
> I am having difficulty seeing why or how to structure an MVC model for the
> redesign on an exsiting application that we plan to move from FB2 to FB3.
I
> have a feeling that it would help with some of the problems we have with
the
> current version which is used by lots of different types of users.
>
> What I noticed in the e-mail below is that Patrick has arranged the
folders
> below model to represent objects and that below controller to represent
> users. The things below view are like collections of objects or ways to
look
> at them.
>
> Is this always true ?
>
> Am I right ? or completely up the creek ?
>
> Kevin
>
>
> -----Original Message-----
> From: Patrick McElhaney [mailto:pmcelhaney@bizjournals.com]
> Sent: 26 March 2002 20:21
> To: fusebox@topica.com
> Subject: RE: MVC Pattern
>
>
> > Brian wrote:
> >
> > Patrick McElhaney wrote:
> > > parent
> > >   model
> > >     products
> > >     orders
> > >   view
> > >     catalog
> > >     cart
> > >     checkout
> > >     orderstatus
> > >   controller
> > >     shopper
> >


Re: MVC question


    * From: Jeff Peters
    * Subject: Re: MVC question
* Date: Tue, 21 May 2002 11:22:32 -0700


That's what the SuperQ() function is about.  You can place the 
fuseaction in the parent of the three, then call it by:
SuperQ(fuseaction)


- Jeff


On Tuesday, May 21, 2002, at 01:45 PM, craig girard wrote:


> I have a question concerning MVC I am hoping someone might be able to 
> shed
> some light on.  In the example documentation on techspedition.com Hal 
> shows
> there being three roles for using the fictional site.  Those roles are
> Admin/CSR/Guest.
>
> He also shows there being three controller directories , one for each 
> role.
>
> What I am curious about is, what do you do when you have a fuseaction 
> that
> all three roles can use exactly the same?  Do you replicate this 
> fuseaction
> across each controller?  That would seem inefficiant.  Would you place 
> the
> fuseaction in the Guest controller and have the other two access this
> fuseaction from there?  If so, how does the flow for this work.
>
> I am lazy and trying to get out of replicating logic that is used by all
> user roles.  What is the best way to go about this?
>
> Thanks,
>
> Craig

Last update: 10/31/2002; 12:12:00 PM.