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 -~----------~----~----~----~------~----~------~--~---
