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 <[email protected]> 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 > > > Regards, > Bill > > On Dec 30 2008, 4:05 am, "Yarko Tymciurak" <[email protected]> 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 <[email protected] > >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 <[email protected]> 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
