Proposal: MVC separation - son of custom views

[billf]

Hi All

I know that there is a patch related to custom views in the pipeline
but this proposal is another step on from that.

I am proposing an additional approach that enables those things that
(I consider) are view-related to be moved from the model and
controller to the view. In addition, it provides separation of html
form from model related logic such as validation and db updating.

There are still some areas to be covered but I have written a page
that, hopefully, explains the ideas at

http://www.wellbehavedsystems.co.uk/web2py/examples/mvc.html

All comments gratefully accepted.

[mdipierro]

Bill,

if I had seen this one year, it is possible web2py would have looked
this this.
Now we need to maintain backward compatibility so we cannot change it.
Anyway, the structure you propose can be implemented on top of web2py
as a module.
If you code it, please share it with us. It could be used to build a
better T2.

Massimo

[Daniel Guryca]

Hey totally agree with you !

It is too bad not to be able to define my own fully customized forms
within a view,
operate over them in a controller but still need to have a necessary
relation to a database model !

Logic should be defined in a controller and presentation in a view.

Daniel

[mdipierro]

You can have custom forms. You always could. Since version 1.48
(posted today) it is even easier:

#in model:

db.define_table('mytable',SQLField('myfield'))

#in controller:

def index():
form=SQLFORM(db.mytable)
if form.accepts(request.vars,session):
response.flash='form accepted'
return dict(form=form)

#and in view:

{{extend 'layout.html'}}

<form>
<label>{{=db.mytable.myfield.label}}</label>
<input name="myfield" value="{{=form.latest.myfield}}" />
{{if form.errors.myfield:}}{{=form.errors.myfield}}{{pass}}
<input type="submit" />
{{=form.hidden_fields()}}
</form>

Massimo

On Nov 10, 2:04 pm, "Daniel Guryca" <dun...@gmail.com> wrote:
> Hey totally agree with you !
>
> It is too bad not to be able to define my own fully customized forms
> within a view,
> operate over them in a controller but still need to have a necessary
> relation to a database model !
>
> Logic should be defined in a controller and presentation in a view.
>
> Daniel
>

[billf]

Massimo

As you say, the proposal can be implemented as a module so as to not
compromise backwards-compatibility.

I am happy to come up with some code but it would be really helpful if
people could contribute their 2 cents early on to ensure a good
"alternative" approach.

[achipa]

Two cents withheld due to misbehaving DNS/server :)

[seeker]

I just read your article Bill.

That is a damn fine bit of thinking!

I hope your ideas can be progressed.

Thanks.
Jan

[billf]

Thank you for your kind comment.

I have made a few changes to the "spec" described in a change log at
the top of the page.

[achipa]

Am I the only one who gets "Firefox can't find the server at
www.wellbehavedsystems.co.uk" ?

[billf]

I've just clicked on the link in your post and the page displayed in
Firefox (not that that helps you I suppose). I'm afraid you can't use
an IP as it's shared hosting.

If you have done a "Clear Private Data" to clear the cache and it
still doesn't work then I'm stumped. Sorry.

I would upload a copy to Google Groups pages or files but I don't know
how to - can't find an "upload" link anywhere. Do I need more
permissions to do that?

On Nov 11, 10:10 am, achipa <attila.cs...@gmail.com> wrote:
> Am I the only one who gets "Firefox can't find the server atwww.wellbehavedsystems.co.uk" ?

[seeker]

Just a thought:
(Please don't shoot me for mentioning this; I say it with Web2Py's
best interest in mind)

In general I have been very much in favour of Massimo's philosophy of
maintaining backward compatibility.
However, part of me wonders whether this is an indefinitely
sustainable idea. I am concerned that, in the long run, it will cause
the project to stagnate.

Would it not perhaps be a better idea to follow the example of Ubuntu
(and others). They regularly release new versions for all who wish to
remain current; but every now and then they release 'special' versions
which are supported for a reasonably long period of time.

In general technology (and ideas) develop so fast that very few
systems would require really long term compatibility to be maintained
and the benefit of evolution may just outweigh the benefits of not
evolving at all.

Please note that I am by no means advocating a radical re-design of
Web2Py with every release though.

Like I said; just a thought.

[billf]

Seeker

I think you have a good point but, playing devil's advocate, if you
want to establish yourself in an enterprise section of the market it
is a disadvantage to give users the ultimatum "if you want X then you
have to change Y".

Perhaps, an alternative is to deprecate methods and classes so that
users are warned and tend to rewrite over a period of time so that
"old" code withers. I have seen this work with Java but I don't know
if it would have the same effect with Python.

In the context of my proposal, perhaps SQLFORM would be marked
@deprecated with users guided towards Resource.

[seeker]

Again ... good thinking.

[achipa]

The line must be drawn otherwise after a while it will be harder (and
messier) to make any progress because of all the backwards
compatibility issues (see Microsoft), especially in a relase often
type OSS project. The simplest and cleanest solution, done in many OSS
projects is well-planned deprecation and two stable branches. One is
the backwards compatible one (1.x in web2py case) and the other is not
and has all the revolutionary ideas (let's call that 2.x). The trick
is not to ditch 1.x right after you release 2.0 but to backport from
the 2.x branch what is backportable and of course do bugfixes for 1.x,
and have a well defined guide for migration from 1.x to 2.x. I agree
you must not *force* people to upgrade, but saying that everything has
to be backwards compatible across *all versions* is like saying we
don't want do significant improvements and introduce drastically new
technologies. Also, the longer 'stretch' of backwards compatibility
exists, the harder it will to eventually introduce change (think DOS
and win32 api, x86 assembler). Apache and the linux kernel had two
stable branches, python will also have something similar (plus the
transitional 2.6), so I guess it is a valid option.

[carlo]

I totally share your thoughts, it should be great to have a web2py
3000 as a new branch. The problem is whether Massimo has enough
resources to support two branches of his creature.

carlo

[achipa]

Usually another person is appointed as maintainer for those cases. As
no extensive changes are likely to happen in the 'oldstable' branch
it's just basically someone who is trusted and familiar with web2py
enough to do bugfixes and backports, which is a lot less effort than
doing spearhead development which is usually done by the original
author or team. It's like Linus always working on the actual/dev
kernel and Alan Cox, Andrew Morton or whoever maintining the
previously released stable branches.

[billf]

I'm not being precious but it seems that this thread has been
"hijacked" to discuss branches when I really want feedback re my
proposal :-)

[Keith Edmunds]

On Tue, 11 Nov 2008 02:10:23 -0800 (PST), attila...@gmail.com said:

> Am I the only one who gets "Firefox can't find the server at
> www.wellbehavedsystems.co.uk" ?

No, you're not. Every time I try to read a document on Bill's website, I
have to flush my DNS cache (note: not my browser cache). I haven't looked
into why, but it's the only site I have to do that with.

Keith

--
Keith Edmunds

+-------------------------------------------------------------------------+
| Tiger Computing Ltd | Helping businesses make the most of Linux |
| "The Linux Specialists" | http://www.tiger-computing.co.uk |
+-------------------------------------------------------------------------+

[billf]

Ugh! If anyone can help me stop that I'd be grateful. I don't get
the problem. I copied the meta lines from another page - could there
be something in there that some clients don't like?

Any help gratefully received.

On Nov 11, 6:25 pm, Keith Edmunds <k...@midnighthax.com> wrote:

[Wes James]

take out the meta lines and then put them back in one by one - people
may need to empty cache to get new data...

-wj

[Wes James]

All i get in safari is a box with a question mark and the source of
the page looks like this:

<html>
<head><title>Well-behaved Systems</title></head>
<body>
<img src="banner.gif" title="Well-behaved Systems" alt="Well-behaved Systems"/>
</body>
</html>

On Tue, Nov 11, 2008 at 12:13 PM, billf <billf...@blueyonder.co.uk> wrote:
>

[Timothy Farrell]

My firefox has no trouble but, it does render in quirks mode (which is ironic for "wellbehavedsystems").

See more about quirks mode vs. standards mode here:

http://www.alistapart.com/articles/beyonddoctype/

-tim

[billf]

Wes

The home page is a do-nothing page. The doc can be found at

http://www.wellbehavedsystems/web2py/examples/mvc.html

On Nov 11, 7:21 pm, "Wes James" <compte...@gmail.com> wrote:
> All i get in safari is a box with a question mark and the source of
> the page looks like this:
>
> <html>
> <head><title>Well-behaved Systems</title></head>
> <body>
> <img src="banner.gif" title="Well-behaved Systems" alt="Well-behaved Systems"/>
> </body>
> </html>
>

[Timothy Farrell]

It's amazing how critical that ".co.uk" is.

http://www.wellbehavedsystems.co.uk/web2py/examples/mvc.html

[billf]

Oops - thanks Timothy :-)

Well some can get the page and some can't. Can achipa or Keith or
anyone who gets the problem try storing the source locally (if they
can access it at all!) and see if they still get the problem? and if
so take out stuff to find the offending article?

On Nov 11, 7:34 pm, Timothy Farrell <tfarr...@swgen.com> wrote:
> It's amazing how critical that ".co.uk" is.http://www.wellbehavedsystems.co.uk/web2py/examples/mvc.html
> billf wrote:Wes The home page is a do-nothing page. The doc can be found athttp://www.wellbehavedsystems/web2py/examples/mvc.htmlOn Nov 11, 7:21 pm, "Wes James"<compte...@gmail.com>wrote:All i get in safari is a box with a question mark and the source of the page looks like this: <html> <head><title>Well-behaved Systems</title></head> <body> <img src="banner.gif" title="Well-behaved Systems" alt="Well-behaved Systems"/> </body> </html> On Tue, Nov 11, 2008 at 12:13 PM, billf<billferr...@blueyonder.co.uk>wrote:Ugh!  If anyone can help me stop that I'd be grateful.  I don't get the problem.  I copied the meta lines from another page - could there be something in there that some clients don't like?Any help gratefully received.On Nov 11, 6:25 pm, Keith Edmunds<k...@midnighthax.com>wrote:On Tue, 11 Nov 2008 02:10:23 -0800 (PST),attila.cs...@gmail.comsaid:Am I the only one who gets "Firefox can't find the server atwww.wellbehavedsystems.co.uk" ?No, you're not. Every time I try to read a document on Bill's website, I have to flush my DNS cache (note: not my browser cache). I haven't looked into why, but it's the only site I have to do that with.Keith-- Keith Edmunds+-------------------------------------------------------------------------+ |    Tiger Computing Ltd    |  Helping businesses make the most of Linux  | |  "The Linux Specialists"  |      http://www.tiger-computing.co.uk    | +-------------------------------------------------------------------------+
>
>  tfarrell.vcf
> < 1KViewDownload

[Yarko T]

still get "not found" on that....  something's going on there...

[aprendiz]

Hi,

think it should be

http://www.wellbehavedsystems.co.uk/web2py/examples/mvc.html

.

On 11 nov, 20:58, "Yarko T" <yark...@gmail.com> wrote:
> still get "not found" on that....  something's going on there...
>

> On Tue, Nov 11, 2008 at 1:56 PM, billf <billferr...@blueyonder.co.uk> wrote:
>
> > Oops - thanks Timothy :-)
>
> > Well some can get the page and some can't.  Can achipa or Keith or
> > anyone who gets the problem try storing the source locally (if they
> > can access it at all!) and see if they still get the problem?  and if
> > so take out stuff to find the offending article?
>
> > On Nov 11, 7:34 pm, Timothy Farrell <tfarr...@swgen.com> wrote:
> > > It's amazing how critical that ".co.uk" is.
> >http://www.wellbehavedsystems.co.uk/web2py/examples/mvc.html
> > > billf wrote:Wes The home page is a do-nothing page. The doc can be found

> > athttp://www.wellbehavedsystems/web2py/examples/mvc.htmlOnNov 11, 7:21 pm,

[Yarko T]

thanks!  that works!

[Keith Edmunds]

On Tue, 11 Nov 2008 11:56:12 -0800 (PST), billf...@blueyonder.co.uk
said:

> Can achipa or Keith or
> anyone who gets the problem try storing the source locally (if they
> can access it at all!) and see if they still get the problem?

The problem (for me, at least) is NOT the page itself, but the DNS entry
for www.wellbehavedsystems.co.uk - I can fix the problem by flushing the
local DNS cache here.

If I get time, I'll try to see why it's happening.

Keith

--
Keith Edmunds

+-------------------------------------------------------------------------+

[billf]

Many thanks.

On Nov 11, 10:00 pm, Keith Edmunds <k...@midnighthax.com> wrote:
> On Tue, 11 Nov 2008 11:56:12 -0800 (PST), billferr...@blueyonder.co.uk

> said:
>
> > Can achipa or Keith or
> > anyone who gets the problem try storing the source locally (if they
> > can access it at all!) and see if they still get the problem?
>
> The problem (for me, at least) is NOT the page itself, but the DNS entry

> forwww.wellbehavedsystems.co.uk- I can fix the problem by flushing the

[seeker]

Hi Bill,

Getting back to the original topic:
Is there no possible way of having Resources peacefully co-existing
with the rest of Web2Py and still be part of the core without breaking
backward compatibility?

[billf]

seeker

Good question. The current "spec" proposes that the Resource approach
will sit alongside the existing web2py core and there will be NO
backward-compatibility problems.

If the developer chooses to use the Resource approach then there are a
couple of consequences:

1) The constructs in the controller and view are different - see
examples

2) Certain current attributes will be ignored.

For example, e.g. labels and comments in the model. These are
considered view-related and are passed to the as() method from the
view. There is a helper method to assist using current models which
creates a dict from the model and that dict can be passed to as().
For example:

{{=resource.as(labels=_get_field_attributes(db.person,'label'))}}

Keep the question coming :-)

[billf]

I am coding the Resource "extension" that this thread refers to and I
have a design question.

Currently SQLForm takes an optional upload argument that specifies a
controller/function to be used when uploading files.

In the Resource approach, there is no SQLForm. The controller creates
a resource, e.g. a db record, that is passed to the view. The view
can then call a Resource method - as() - to get a representation of
the Resource, e.g. as an HTML form.

My question is: "which element of MVC should specify the upload
argument?"

My current feeling is that the controller should specify this when
creating the resource. It doesn't seem correct to specify this in
either the model (which doesn't know the use context) or the view
(which should only be concerned with presentation). But that's just
my opinion and I would like to hear any alternatives.

Supplementary questions:
1) Must the upload link be a controller/function or could it be any
url?

2) Would it be useful optionally to specify different a controller/
function/url for each resource fields?

On Nov 11, 7:56 pm, billf <billferr...@blueyonder.co.uk> wrote:
> Oops - thanks Timothy :-)
>
> Well some can get the page and some can't.  Can achipa or Keith or
> anyone who gets the problem try storing the source locally (if they
> can access it at all!) and see if they still get the problem?  and if
> so take out stuff to find the offending article?
>
> On Nov 11, 7:34 pm, Timothy Farrell <tfarr...@swgen.com> wrote:
>
> > It's amazing how critical that ".co.uk" is.http://www.wellbehavedsystems.co.uk/web2py/examples/mvc.html

> > billf wrote:Wes The home page is a do-nothing page. The doc can be found athttp://www.wellbehavedsystems/web2py/examples/mvc.htmlOnNov 11, 7:21 pm, "Wes James"<compte...@gmail.com>wrote:All i get in safari is a box with a question mark and the source of the page looks like this: <html> <head><title>Well-behaved Systems</title></head> <body> <img src="banner.gif" title="Well-behaved Systems" alt="Well-behaved Systems"/> </body> </html> On Tue, Nov 11, 2008 at 12:13 PM, billf<billferr...@blueyonder.co.uk>wrote:Ugh!  If anyone can help me stop that I'd be grateful.  I don't get the problem.  I copied the meta lines from another page - could there be something in there that some clients don't like?Any help gratefully received.On Nov 11, 6:25 pm, Keith Edmunds<k...@midnighthax.com>wrote:On Tue, 11 Nov 2008 02:10:23 -0800 (PST),attila.cs...@gmail.comsaid:Am I the only one who gets "Firefox can't find the server atwww.wellbehavedsystems.co.uk" ?No, you're not. Every time I try to read a document on Bill's website, I have to flush my DNS cache (note: not my browser cache). I haven't looked into why, but it's the only site I have to do that with.Keith-- Keith Edmunds+-------------------------------------------------------------------------+ |    Tiger Computing Ltd    |  Helping businesses make the most of Linux  | |  "The Linux Specialists"  |      http://www.tiger-computing.co.uk   | +-------------------------------------------------------------------------+
>
> >  tfarrell.vcf
> > < 1KViewDownload

[voltron]

I think any URL should be able to handle files, as is specified by
REST. Web2py should read the content type and HTTP verb as in


www.mydomain.com/myfiles/Mynewfile

"PUT /myfiles/Mynewfile HTTP/1.1
Host: www.mydomain.com
Content-Type: file type
Content-Length: file length
"

The combination of PUT( create resource) + file type is the ticket I
think. Specifying a different function or URL would not be useful if
you intend for it to be fully RESTful, for example:

/employees # main resource
/employees/voltron or /employees?user_name =voltron # GET shows the
user voltron with stat 200 or 404
/employees/voltron or /employees?user_name =voltron # PUT creates a
new user voltron with 201 or 405, 401, 402 etc

These are all handled by the same controller, which maps to the
resource

[voltron]

Would it be possible to simplify the flow by just stating a resource
takes a dictionary of values and attributes and the enumerations
Collection, Record, List should conform somehow? My reasons:

1. Web2py hast its own database idioms for collection types for the
DAL, that would mean we have to more
2. Its not so pythonic to me as python already has a host of
enumerations like lists,tuples and dictionaries

[billf]

Voltron

I don't think you answered the original question which was basically
"if you are going to specify a link in a page then is specifying that
link the responsibility of the the model, the controller or the view?"

RE your other points:

"All URLs should be able to handle files/REST/PUT": at this point, the
Resource approach is intended to keep the existing web2py controller/
function structure but "tidy up" the mvc separation. My next mission,
should i choose to accept it :-), will be to develop a RESTful
structure - initial thoughts at
http://www.wellbehavedsystems.co.uk/web2py/examples/rest.html and
rest_alt1.html But that is a bigger change as it changes the
controller/action structure.

"Simplify...a resource [just] takes a dictionary of values and
attributes": I think there are 2 issues: a) presenting a common
Resource interface (accepts, persists, as) when python doesn't really
do interfaces (as I understand it) and b) where to put the logic/data
that is being moved.

In Java, I would probably have a Resource interface that was
implemented by classes that extended the existing web2py structures
(record=SQLStorage, list=SQLRows, collection=not sure). In Python,
tho' I am still learning, putting everything in one class called
Resource (if that is your suggestion) doesn't seem right to me as each
kind of resource implements the interface differently. As I don't want
Resource to be a lot of "if type=='record else" statements, having
different classes seems better. I don't see these classes a
enumerations - they merely associate logic with existing
enumerations. I suppose my question back would be "what is a more
pythonic way of meeting the design requirements?"

[Peter]

Massimo, I'm trying to use this technique, as follows:

Controller:
def inschrijving():
vrouw=db(db.t2_person.id==t2.person_id).select()[0]
form=SQLFORM(db.t2_person,vrouw)
if form.accepts(request.vars,session):
response.flash='OK.'
return dict(form=form)

View (inschrijving.html):
{{extend 'layout.html'}}
<form>
<label>{{=db.t2_person.name.label}}</label>
<input name="name" value="{{=form.latest.name}}" />
<label>{{=db.t2_person.landcode.label}}</label>
<input name="landcode" value="{{=form.latest.landcode}}" />
{{if form.errors.landcode:}}{{=form.errors.landcode}}{{pass}}
<input type="submit" value="Save"/>
{{=form.hidden_fields()}}
</form>

I can't get much closer to the snippet that you posted than this? ;-)

Problem: nothing happens if I click submit (no flash message, no
update in db).
Among much else, I've tried:
- adding "action" and "method' attributes to form;
- form.accept with "formname=None" instead of session;
- form.accept without any second argument
-- no luck with any of them.

What am I doing wrong??

Cheers,
-Peter

On Nov 10, 9:15 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> You can havecustomforms. You always could. Since version 1.48
> (posted today) it is even easier:
>
> #in model:
>
> db.define_table('mytable',SQLField('myfield'))
>
> #in controller:
>
> def index():
>     form=SQLFORM(db.mytable)
>     if form.accepts(request.vars,session):
>          response.flash='form accepted'
>     return dict(form=form)
>
> #and in view:
>
> {{extend 'layout.html'}}
>
> <form>
> <label>{{=db.mytable.myfield.label}}</label>
> <input name="myfield" value="{{=form.latest.myfield}}" />
> {{if form.errors.myfield:}}{{=form.errors.myfield}}{{pass}}
> <input type="submit" />
> {{=form.hidden_fields()}}
> </form>
>
> Massimo
>
> On Nov 10, 2:04 pm, "Daniel Guryca" <dun...@gmail.com> wrote:
>
> > Hey totally agree with you !
>
> > It is too bad not to be able to define my own fully customizedforms
> > within a view,
> > operate over them in a controller but still need to have a necessary
> > relation to a database model !
>
> > Logic should be defined in a controller and presentation in a view.
>
> > Daniel
>
> > On Mon, Nov 10, 2008 at 2:23 PM, billf <billferr...@blueyonder.co.uk> wrote:
>
> > > Hi All
>
> > > I know that there is a patch related tocustomviews in the pipeline
> > > but this proposal is another step on from that.
>
> > > I am proposing an additional approach that enables those things that
> > > (I consider) are view-related to be moved from the model and
> > > controller to the view.  In addition, it provides separation of html
> > > form from model related logic such as validation and db updating.
>
> > > There are still some areas to be covered but I have written a page
> > > that, hopefully, explains the ideas at
>
> > >http://www.wellbehavedsystems.co.uk/web2py/examples/mvc.html
>
> > > All comments gratefully accepted.

[mdipierro]

try add

<input name="id" value="{{=form.record.id}}" type="hidden" />

[Peter]

Massimo, thanks for the incredibly fast turnaround -- on a Sunday
even. ;-)

I've done some more experimenting. This works beautifully on my
PRODUCT table. I do have to add the name="id" to the form, as you
suggested, to prevent a "user is tampering with form" error.

BUT I keep having the same problem as described above with my
T2_PERSON extended table. Adding the name="id" field makes no
difference.

If you have any further ideas, please let me know... Somehow related
to T2??
Cheers,
-Peter

In db.py:
db.define_table('t2_person',
SQLField('name',length=40,requires=IS_NOT_EMPTY()),
SQLField('password','password',requires=CRYPT()),
SQLField('email',requires=IS_EMAIL()),
SQLField('registration_key',length=64),
SQLField('voornaam'),
SQLField('achternaam',length=50),
SQLField('adres',length=100),
SQLField('plaats',length=50),
SQLField('postcode',length=10),
SQLField('landcode',db.land),
SQLField('telnr',length=15),
SQLField('foto','upload'),
SQLField('created_by_ip'),
SQLField('created_on','datetime'))

db.t2_person.name.requires=IS_NOT_EMPTY()
db.t2_person.landcode.requires=IS_IN_DB(db,'land.id','%(landnaam)s')
db.t2_person.email.requires=[IS_EMAIL(),IS_NOT_IN_DB
(db,'t2_person.email')]
db.t2_person.password.requires=[IS_NOT_EMPTY(),CRYPT()]
db.t2_person.exposes=
['name','email','password','voornaam','achternaam','adres','plaats','postcode','landcode','telnr','foto']
db.t2_person.displays=
['name','email','voornaam','achternaam','adres','plaats','postcode','landcode','telnr','foto']
...
...
from applications.mijnmoem.modules.t2 import T2
t2=T2(request,response,session,cache,T,db)

[Peter]

Oh -- forgot to say: the same SQLFORM for a t2_person embedded in the
view with {{=form}} DOES work.
So it seems there's a relationship between the t2 stuff and this
specific way to build a custom form?

Just to reiterate, the problem is still this: >> nothing happens if I

click submit (no flash message, no
update in db). <<

Cheers,
-Peter

[mdipierro]

I see. You need

form=SQLFORM(db.t2_person,vrouw,fields=[....])

instead of

form=SQLFORM(db.t2_person,vrouw)

else you have errors in fields that are not visualized by the custom
form. You can check this by printing:

{{=form.errors}}

Massimo

[Peter]

Check -- that did the trick.

I didn't know that specifying the fields in the SQLFORM had this
effect on the scope of the update. You live and learn...

Thanks for the support!
-Peter

[James Ashley]

For the backwards-compatibility conversation:

This doesn't break backwards compatibility at all, AFAICT. It just
introduces an alternative way of doing things.

Of course, that can be a bad idea. It's no longer as obvious which is
the "right" way. It's extra surface area to maintain.

I'll second (or third...whichever) implementing this as a module.
Give it a chance to evolve a bit. If enough people are using it if/
when the time comes to do web2py 3000, maybe it should be merged into
the trunk then.

Now, on to my thoughts (not that they're worth all that much...but you
did ask for feedback).

On Nov 11, 10:12 am, billf <billferr...@blueyonder.co.uk> wrote:
> I'm not being precious but it seems that this thread has been
> "hijacked" to discuss branches when I really want feedback re my
> proposal :-)

I'm mostly brainstorming here. Please forgive (or just skip) my
rambling. :-)

I like the idea. It seems like something that's worth bouncing around
and picking through to make sure there aren't any gaping holes, but
the first read-through seemed pretty good to me.

The only thing that I see (so far...this is really the first time I've
noticed this thread) is the specification of how to get to the guts of
the resources. I tend to skip SQLFORM completely and just have my
views access my models as seems appropriate (not very clean, I know.
But my current project is definitely more of a cowboy hack/slash fest
than anything I'd call "Enterprise"). SQLFORM is great for a quick-
and-dirty throw-something-together, but it rarely suits even my needs.

Of course, over-specifying something like this can lead us into the
dangers of the backwards-compatibility handcuffs, especially if the
specs get set in stone too soon.

3 options come to my mind for this scenario:

1) Iterate over a resource. If the resource is just one record, it
returns that record. If it's multiple records, it returns one record
at a time. You can access individual fields from the record directly,
by name (which is pretty much what I do now). This is pretty broken
if you'd like to have a form to edit single records, then switch to a
grid to edit multiple records.
2) Have custom "as" methods, on an as-needed basis. "Render as a
collection of div/span elements, showing these columns, sorted by
these 3 columns."...which is probably exactly what you had in mind for
collections.
3) Associate "snippet" templates with the resource. Pretty much
exactly like regular templates, but they are limited in scope to the
record. I've worked with this sort of thing a lot in aspx pages. It
can be very powerful, but also very difficult to get right (need
templates for optional headers/footers, then for the individual rows,
and how do you handle things if, for example, you want alternating
rows to have a different background color?)

I'm sure I've missed a few.

Anyway, your idea is probably cleaner than the SQLFORM approach, but
MVC purists could still whine about it. After all, the resource
object is almost its own MVC object. Except, in this case, the
'controller' is whatever calls as() to tell the model which of its
views to render.

The theory seems to go that the top-level controller, in this case,
should call as(), since it's responsible for deciding which view to
render (and the view should know absolutely nothing about any
models). It passes the rendered result into whichever view it's
chosen, and that view just shows the rendered result, as appropriate.
This helps the designers keep the top-level view as dumb as possible.

There isn't anything stopping anyone from doing that, but it really
seems to me that calling it from the top-level view just makes more
sense. For one thing, it makes the presentation much more flexible.

Not that any of that really has anything to do with your proposal. As
usual, developers are free to [mis-] use any tools that are placed
into their hands.

Heh. You probably should have asked for well-considered thoughtful
feedback. ;-)

Regards,
James

[Yarko Tymciurak]

Hi Bill -

I see you put a lot of work / thought into this...

It seems like it's in the right direction.   I just read this now (wasn't able to before, then didn't hear anything about it).

Here's some initial thoughts:

-  I think separating storage from updating persistent data is a good thing;  I think this is a needed improvement at several levels;

-  I think you need to think through this some more - work some use cases, and sort out how this would look, and if the idioms and behaviours are coherent and make sense;

-  I think you went too far in a few places, that is not improving (perhaps even the other way - making things less clear).   For example, labels and comments: trying to change this serves no constructive function whatsoever.   To see this, consider Python documentation in Sphinx / ReStructuredText:   the text and functional directives are separate from the rendering engine.   That is, a tabular data is defined (appropriately) at the Sphinx equivalent of the "data" - in the source;   this is because it conveys form (not format), and specific information necessary to communicate that form.    Taken a little further,  the benefit of an admonition against label / comment as "view" can be tested more clearly this way:   define a table with obfuscated field names (as sometimes SQL causes us to mildly do):  something like table_define(Field('a1'), Field('a2'), Field('a3'), ....).    Arguing that the correct label should be specified in "view" is clearly wrong in this case - the separation of concern serves no purpose, and introduces potential for error.

And therein lies the benefit (your way, OR current web2py way) for "label" and "comment" - it is self-documenting the data structure, it's intent nearest the source.   It is not a presentation-thing; it's an informative-thing, not unlike Sphinx-source that defines that something should be shown in a table relationship.

The other smaller thing I saw which I like better as currently is:   your resource field suggestion of "link_to="   I think is a decay from the current  idiomatic (and more appropriately suggestive)  t2.action()....

Action is the appropriate web2py suggestion.

I think if you review your thoughts with an eye for keeping the most useful of web2py idioms, and adding an improvement class (which certainly you are suggesting) then this can be much closer to the current web2pym, and will also be more likely to take root - as people will naturally prefer that which is easier to read, build logic around if it is in harmony with the most helpful aspects that currently exist.

Give us a demo class to try and comment on, and have a few people try to use - I think you'll get more pragmatic comments then.

Kind regards,

Yarko

[billf]

Yarko

Many thanks for your thoughtful comments - definitely the best so
far. I will read through a few more times, update the "spec" and
notify folk via a post here.

I think my hosting company have recently sorted out some dns problems
so hopefully folks wont have a problem accessing the "spec" pages in
future.

Re progress on an example class: a lot is coded but other stuff took
over. Most of the time taken has been to ensure that default
behaviour, e.g. no view exists or generating a default form, work as
expected.

Hopefully more soon,
Bill

[billf]

Yarko

I finally got around to looking at your comments in detail with the
following results.

1) Re labels: I'm not totally convinced by the "labels are model"
argument but my implementation (when it arrives if ever) will use (per
field) 'view label' over 'model label' over 'field name'.

Your argument that model labels overcome obscure field names is, IMHO,
an argument for a new SQLField attribute 'dbname' that allows the
web2py internal fieldname to be different from the actual dbname - I
have suggested this several times and I think it would really help
making legacy tables more readable in code.

2) Comments are not part of the model anyway and I don't see that
replacing the 'col3' passed to SQLFORM with 'comments' passed from the
view is a problem.

3) Still looking at the linkto= suggestion.

4) Got back on the coding horse and hope to have some alpha code
v.soon.

Regards,
Bill

[Yarko Tymciurak]

Hi Bill -

Sorry - I was sort of in shock when read my own comments (remind me not to right when I'm tired!) - but I am glad you could understand them.

On Fri, Jan 2, 2009 at 1:32 AM, billf <billf...@blueyonder.co.uk> wrote:

Yarko

I finally got around to looking at your comments in detail with the
following results.

1) Re labels: I'm not totally convinced by the "labels are model"
argument but my implementation (when it arrives if ever) will use (per
field) 'view label' over 'model label' over 'field name'.

The argument I was making was about your admonition that labels and comments should be presentation / view things - I absolutely disagreed with that, and suggested you stick to improvements, and designing your portion of what you wanted to improve.

 

Your argument that model labels overcome obscure field names is, IMHO,
an argument for a new SQLField attribute 'dbname' that allows the
web2py internal fieldname to be different from the actual dbname -  I
have suggested this several times and I think it would really help
making legacy tables more readable in code.

I would rather not mix up this discussion - other changes are other changes.   I only suggest that comments and labels are a "form" rather than a "format" thing, and therefore  I think it would be detrimental to try to move them / change them for reasons related to "what belongs in view?  what belongs in controller?  what belongs in model?" - they are closer to model, and as such I suggested you leave that part alone.

Your argument here seems to say you REALLY don't like them and just want to change them, never mind to what - just something.   Fine - but separate that out to a different argument / different effort / different thread.   I suggested that topic (removing / changing current labels / fields) doesn't "fit" as part of this.

2) Comments are not part of the model anyway and I don't see that
replacing the 'col3' passed to SQLFORM with 'comments' passed from the
view is a problem.

I think you are being too literal - comments as used are descriptive, about the intent of the data item, and as such are about "form" not format.   I would not change this for now, focus instead on separating out the commitment of data change so that there is explicit controller level control - this is the clearest, most beneficial step.  When that's complete, then attack other parts.

3) Still looking at the linkto= suggestion.

action... is my strong preference - better communicates what is being hooked up.

 

4) Got back on the coding horse and hope to have some alpha code
v.soon.

Looking forward...

Regards,

Yarko

[Yarko Tymciurak]

mmm....

On Fri, Jan 2, 2009 at 2:06 AM, Yarko Tymciurak <yar...@gmail.com> wrote:

Hi Bill -

Sorry - I was sort of in shock when read my own comments (remind me not to right when I'm tired!) - but I am glad you could understand them.

.... to write when I'm tired!).....

.....

2) Comments are not part of the model anyway and I don't see that
replacing the 'col3' passed to SQLFORM with 'comments' passed from the
view is a problem.

I think you are being too literal - comments as used are descriptive, about the intent of the data item, and as such are about "form" not format.   I would not change this for now, focus instead on separating out the commitment of data change so that there is explicit controller level control - this is the clearest, most beneficial step.  When that's complete, then attack other parts.

additionally,  I would like to separate discussion about "label" and "comment" on model  (and if there is or isn't a better way to express form) from what SQLFORM does or doesn't do with that, etc.

I see these as distinctly separate topics.

That is:

- There is more to the form/shape of data - that is the model - than just data table definitions (e.g. there are constraints, descriptors, etc.);  discussion of ways to represent this is one topic;

- who is / should be dependent on (getting)  and responsible for (changing, setting) the aspects of a data model is another topic.   I think the most important part of what you propose to address is making interfaces for "setting" more explicitly in the controller spaces.

- what constitutes presentation, and belongs there (formatting; presentation control logic; etc.) is also a separate discussion.

[billf]

On Jan 3, 4:10 am, "Yarko Tymciurak" <yark...@gmail.com> wrote:
> mmm....
>

> On Fri, Jan 2, 2009 at 2:06 AM, Yarko Tymciurak <yark...@gmail.com> wrote:
> > Hi Bill -
> > Sorry - I was sort of in shock when read my own comments (remind me not to
> > right when I'm tired!) - but I am glad you could understand them.
>
> .... to write when I'm tired!).....
>
> .....
>
>
>
> >> 2) Comments are not part of the model anyway and I don't see that
> >> replacing the 'col3' passed to SQLFORM with 'comments' passed from the
> >> view is a problem.
>
> > I think you are being too literal - comments as used are descriptive, about
> > the intent of the data item, and as such are about "form" not format.   I
> > would not change this for now, focus instead on separating out the
> > commitment of data change so that there is explicit controller level control
> > - this is the clearest, most beneficial step.  When that's complete, then
> > attack other parts.
>
> additionally,  I would like to separate discussion about "label" and
> "comment" on model  (and if there is or isn't a better way to express form)
> from what SQLFORM does or doesn't do with that, etc.
>

Just to clarify - when I say 'comment' I am referring to what SQLFORM
calls 'col3'. Am I correct when I say that the model doesn't
currently have a comment/cols3 attribute? It is just something passed
to SQLFORM. In my changes, I re-named 'col3' as 'comment' and have
used that name like everyone would know what I meant - sorry.

> I see these as distinctly separate topics.
>
> That is:
>
> - There is more to the form/shape of data - that is the model - than just
> data table definitions (e.g. there are constraints, descriptors, etc.);
>  discussion of ways to represent this is one topic;

I agree that the model is more than db tables - I think of it as the
'business model' and hence stuff like validation rules should be
there.

So far I haven't used v.many tables in one app and it will be
interesting to see how to best accomodate large numbers of tables (for
maintainability). Is it just a case of 'including' files containing
groups of tables?

>
> - who is / should be dependent on (getting)  and responsible for (changing,
> setting) the aspects of a data model is another topic.   I think the most
> important part of what you propose to address is making interfaces for
> "setting" more explicitly in the controller spaces.
>
> - what constitutes presentation, and belongs there (formatting; presentation
> control logic; etc.) is also a separate discussion.

I would like a separate discussion re different forms of output (xml,
csv, etc) and how to generate them in a similar way to how html is
generated, i.e. with the ability to include logic but outside the
controller function. The current design where returning a dict can
only generate html output via an x.html template seems too narrow.
But I accept that html is the 99% need and TBH I haven't got a better
idea at the moment.

[Yarko Tymciurak]

On Sat, Jan 3, 2009 at 12:40 AM, billf <billf...@blueyonder.co.uk> wrote:

.......

Just to clarify - when I say 'comment' I am referring to what SQLFORM
calls 'col3'.  Am I correct when I say that the model doesn't
currently have a comment/cols3 attribute?  It is just something passed
to SQLFORM.  In my changes, I re-named 'col3' as 'comment' and have
used that name like everyone would know what I meant - sorry.

hmmm.... I'm not that saavy around all this, but you can have:

db.t2_person.name.comment= T('Required')

and Required will appear in (?) col3 for 'name'

(see, for example, http://bazaar.launchpad.net/~mdipierro/web2conf/devel/annotate/head:/models/db.py)

That's what I was referring to when I said "lablel" and "comment"  on a db column.

> I see these as distinctly separate topics.
>
> That is:
>
> - There is more to the form/shape of data - that is the model - than just
> data table definitions (e.g. there are constraints, descriptors, etc.);
>  discussion of ways to represent this is one topic;

I agree that the model is more than db tables - I think of it as the
'business model' and hence stuff like validation rules should be
there.

yeah, this requires a little care - distinction between database level validation, and business logic - controller stuff being driven by what the business wants, model level validation being driven by what the data layer needs for consistency.

 

....

I would like a separate discussion re different forms of output (xml,
csv, etc) and how to generate them in a similar way to how html is
generated, i.e. with the ability to include logic but outside the
controller function.

...

I think this is a good, rational focus:  logic driven by presentation needs (e.g. what you need for HTML; what you need to generate csv;  what you need to generate pdf;  etc. etc.)  versus what is desired by the "business",  e.g. "I don't want them to generate PDF coupons unless they're a manager".

I look forward to seeing what you produce in this.  If you want some help. you could make a branch on either launchpad or bitbucket.  That would make it easy to test, comment.

Regards,

Yarko