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
On Dec 30, 4:05 am, "Yarko Tymciurak" <yark...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
