On Tue, Nov 18, 2008 at 2:03 PM, billf <[EMAIL PROTECTED]> wrote:
> 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.
This discussion could easily confuse and decay into non-pertinent
perspectives....
I will simply say this way:
The presentation shows what the client / user knows / expects.
The logic / controller level will do application specific things
(validation, temporary calculations, etc.), and map the user's view of the
data to the designed (persisted) data representation.
The data layer will hide the details of the representation. At one level,
DAL does this for us. But at another, optimizing data design as your
application evolves (or it's scope changes) would be best to limit, not
involve change from the controllers. Design / performance concerns may
modify this, but that is a separate topic.
The starting position is that DAL is most of what you need for isolation, so
you don't need to worry too much. And that is a good _starting_ position.
>
> >
> > 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.
SQLFORM is a convenience function - a helper; nothing says the controller
has to use it; it's just handy if that's all you need. You would not be
happy if you did NOT have 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.
I think we're mixing design choices with architectural (layer / MVC;
structural!) discussions. Perhaps it's best to keep these separate.
>
>
> >
> >
> > > 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
-~----------~----~----~----~------~----~------~--~---
