Making SQLFORM (or anything) "good MVC" isn't the point, I think.
When you need simple, direct data form to user (as admin does), it's a
design choice to use this convenience function - in that case, strict MVC is
just not of primary importance - basically, we don't care that much (because
we don't need to) for admin! And you do still have separation - it's
sufficient for certain cases.
I think a discussion of when to use SQLFORM , and when some alternative
might be a better choice (and perhaps how to make SQLFORM more broadly
useful without losing it's convenience) is what I'm after.
On Tue, Nov 18, 2008 at 3:04 PM, billf <[EMAIL PROTECTED]> wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
