Re "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."
Sure, but that doesn't make it a good MVC class. One simple example:
SQLFORM is instantiated in the controller and gets the labels to be
used in the form from one of two places - its constructor or the model
- both of which are bad MVC separation IMHO. My aim in these
discussions is to find a concensus on how to replace these "features".
RE "I think we're mixing design choices with architectural (layer /
MVC;
structural!) discussions. Perhaps it's best to keep these separate."
I don't think I'm mixing design choices with architectural
discussions. But if you think that I am then we probably won't get
much further at this time :-)
- Hide quoted text -
On Nov 18, 8:26 pm, "Yarko Tymciurak" <[EMAIL PROTECTED]> wrote:
> 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- Hide quoted text -
>
> - Show quoted text -- 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
-~----------~----~----~----~------~----~------~--~---
