Responses below
On Nov 18, 6:04 pm, yarko <[EMAIL PROTECTED]> wrote:
> On Nov 18, 10:41 am, billf <[EMAIL PROTECTED]> wrote:
>
> > 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).
>
> Yes.... at some level.... at another level, the view should know
> nothing about the model.
I'm not saying that the (presentation) view knows anything about the
model just that the change to the model could be catered for by a
(database/model) view, i.e. even the controller might not need to know
that the persistence model has changed.
>
> In the simple case, this decays to something looking like this:
>
> view: index.html:
>
> {{ =person }}
>
> controlller: default.html::index()
>
> ...
> person = SQLFORM( db.person)
>
> and SQLFORM is the utility function that operates as the controller
> interface to the data layer.
>
Assuming you are referring to the current SQLFORM, this seems to me
the key area for debate. An SQLFORM is created by the controller and
pre-determines what the view can do, i.e. it creates an html form.
Until the recent patch, the view couldn't even extract the current
value of a field without navigating through a tree of html helpers. I
agree that something must act as the bridge between the view and the
model, I just think that SQLFORM is not the way to do it.
My approach is to use a class (Resource) to act as the bridge between
view and data. The resource is constructed by the controller and the
controller can apply constraints, i.e. limit what the view can do but
in a functional not a presentational way. So, for example, the
controller can specify that a resource cannot be deleted but couldn't
say that the view could only output an html form. The controller could
receive an update request without a form being displayed (as web2py
can now) but doesn't have to create an SQLFORM to process that request
- it just creates the resource, updates it with the request and, if
valid, persists it.
>
>
> > Also, you say the controller/logic includes "setting up the
> > interface". It depends what you mean.
>
> by interface, I mean the traditional programming meaning: the
> classes, functions and attributes that are intended to be accessed by
> the views.
>
> > If you mean collating the data
> > required by the interface then I agree. If you mean defining some
> > aspects of thepresentationof the interface then I don't agree.
>
> I'm not sure what you mean - presentation and programming interfaces
> are somewhat separate things...
>
Too many uses of the word "interface" (as in "user interface", API) -
I agree with you.
> Regards,
> Yarko
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
