Yarko
Basically I agree with everything you say. There are always going to
be some grey areas but that's life.
For example, I could argue that hiding changes to the model could be
handled by the model (as opposed to the controller as you suggest) by
exposing a "legacy" view. (I'm talking generally rather than just
web2py).
Also, you say the controller/logic includes "setting up the
interface". It depends what you mean. If you mean collating the data
required by the interface then I agree. If you mean defining some
aspects of the presentation of the interface then I don't agree.
I am currently finishing coding and testing an extension (for want of
a better word) to web2py that, I believe, supports most of your
requirements. As soon as it is robust, I will post the files.
On Nov 17, 11:15 pm, "Yarko Tymciurak" <[EMAIL PROTECTED]> wrote:
> 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)- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
