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
On Mon, Dec 29, 2008 at 7:39 PM, James Ashley <james.ash...@gmail.com>wrote:
>
> 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
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
