And the purpose of separation is to prevent "unnatural design coupling."
Some things may be "naturally coupled" across layers, such as a login. But
what about student name? Student name is part of the data structure, used
in logic, and presented in a friendly way... What if, at the data level,
you decide to change - and store student name as "given_name / family_name".
If controller hides that detail, then presentation doesn't need to know,
and you are free to modify your data structure (perhaps to meet other new
requirements) without the "ripple" (need for changes in many places) effect
of inappropriate design coupling.
That, essentially, is the point of MVC.
A way I like to think of MVC - rename it logically - is:
DATA Layer (a.k.a. model) - has to do with data design, and details of
persisting data (table specific stuff; stuff for getting things out of /
into database, constraints that have been designed to be in the persisted
data, etc.);
LOGIC (a.k.a. controller(s)) - all the stuff you've (correctly) described as
application logic - the guts of your solution's behavior; this includes some
level of preparation of forms (that is - setting up the interface for what
will be accepted as input to the application);
PRESENTATION (a.k.a. view) - things that have to do with grabbing data to
display, wrapping it in presentation-like things (divs), and things you've
decided to run at the client.
Think of these as literal layers - a stack, e.g. view should never access /
assume / know about anything in the model, even if it "seems silly not to" -
it will create a coupling that will create brittleness, and could bite you
badly later.
Presentation has to get stuff from logic, and present things to it;
logic has to validate, combine, and choose things to store, and give things
to be presented (like a consistent "student name");
data has to connect w/ the physical data store, ensure that the stored items
meet constraints, are consistent with the storage type, etc.
They have (and set up) interfaces between each other. They should access
each other only in their interfaces (in what they choose / need to expose).
Yes, you put application logic in the controller - but literally, there is
logic in each of these layers, it is concerned with different aspects of the
application. Sometimes I fear I harp on this too much, but it is
fundamental.
Kind regards,
Yarko
On Mon, Nov 17, 2008 at 3:24 PM, Timothy Farrell <[EMAIL PROTECTED]> wrote:
> You're almost there.
>
> Yes, put all of the if/then logic in the controller, that what controllers
> are made for.
>
> The purpose of MVC separation is make the View and Controller completely
> abstracted pieces.
>
> Ideally, doing any HTML work in the controller is an MVC violation.
> Instead you should pass a list of strings (of scholarships in this case) to
> your view. Like so:
> schols = []
> schols.append('Random Free Money')
>
> return dict(schols = schols)
>
> And then in your view, loop over the list with the appropriate markup.
>
> -tim
>
>
> Wes James wrote:
>
> Is the best place to create data for views in the controller. For
> instance, after a student enters some initial data, I need to look at
> that data and determine what scholarships they might be eligible for.
> Along with the student data and a scholarship table, I need to do a
> bunch of "if then" logic. Would I put that in the controller?
>
> For instance, the student is a female, in such and such major and is a
> senior. For each scholarship I must then look at the DB and determine
> the requirements and if they are eligible, tack that Scholarship name
> in to: response.schols += "<li>This Scholarshiip</li>" and then do
> respons.total += db.scholarship_amount. And then in my form do:
>
> <output>
> You are eligible for these scholarships:
>
> {{=response.schols}}
>
> You could receive as much as ${{response.total}} for the school year.
> </output>
>
>
> Is this correct?
>
> thx,
>
> -wj
>
>
>
>
>
> --
> Timothy Farrell <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> Computer Guy
> Statewide General Insurance Agency (www.swgen.com)
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
