Re: [Web-SIG] Bowing out (was Re: A trivial template API counter-proposal)
[Alan Kennedy] Looking at this in an MVC context ... [Phillip J. Eby] As soon as you start talking about what templates should or should not do (as opposed to what they *already* do), you've stopped writing an inclusive spec and have wandered off into evangelizing a particular framework philosophy. Sorry if my message seemed unreasonable. My approach to such matters is to attempt to start from best design practice, keeping a keen focus on the best way to do things in the future, relegating poorly-architected legacy systems, e.g. active page systems, to being a secondary concern. Also, my take on active page systems is that they could easily be encompassed by an MVC model. The View is the active page, the Model is the namespace in which the active page is rendered and the Controller is the thing that does the rendering. [Phillip J. Eby] At this point it has become clear to me that even if I spent my days and nights writing a compelling spec of what I'm proposing and then trying to sell it to the Web SIG, it would be at best a 50/50 chance of getting through, and in the process it appears that I'd be burning through every bit of goodwill I might have previously possessed here. .. I'd rather save whatever karma I have left here for something with a better chance of success. I'm sorry to hear that. [Phillip J. Eby] Good luck with the spec. Well, I'm currently designing and implementing a View and ViewResolver in Spring for a customer, so I'll be keeping a note of requirements as I go, and will attempt to come up with a generic design which is suitable for a a templating standard. But it will be a few weeks before I can spec that, document it and start doing sample implementations which I can open source. Regards, Alan. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Bowing out (was Re: A trivial template API counter-proposal)
I'm not sure what you're talking about here. Are you talking about WSGI? Or the templating effort? I've tuned out the templating discussion. I think you and others did a fantastic job with WSGI. (Based on my experience I do think it needs more work in the future, but that's beside the point.) Despite some skepticism about the templating effort, I certainly planned to evaluate it when it settled down. For the record, I am very interested in inclusive specs and other means to collaborate. Keep up the good work! I do think that the pioneering work you are doing with setuptools is far more important for Python, so I'd be happy to see you focus on that. :) Jim Phillip J. Eby wrote: At 08:02 PM 2/5/2006 +, Alan Kennedy wrote: Looking at this in an MVC context, the application is responsible for populating the Model (user namespace), and selecting which View (template-media-type) is suitable for return to the user. Templates should not vary media types. HTTP headers do need to be set for different templates/media-types. But that should be the responsibility of the HTTP application, not the template, which should be unaware of the application contect in which it is running, except for the contents of the Model/user-namespace. As soon as you start talking about what templates should or should not do (as opposed to what they *already* do), you've stopped writing an inclusive spec and have wandered off into evangelizing a particular framework philosophy. OTOH, before I first proposed WSGI in 2003, nobody here seemed especially interested in writing inclusive specs anyway, and I rather get the impression they still aren't now, my insistence (as Ian calls it) notwithstanding. What I've been trying to do with both WSGI and with this spec is to create something that deals with the *actual* complexity and diversity of Python web frameworks as they exist today, rather than reducing the diversity to match whatever the currently popular paradigm is. This wasn't a popular approach when I introduced WSGI, either, but in the case of WSGI it was easy to point to all the previously-failed attempts at standardizing request/response objects due to people not taking backward compatibility into account. At this point it has become clear to me that even if I spent my days and nights writing a compelling spec of what I'm proposing and then trying to sell it to the Web SIG, it would be at best a 50/50 chance of getting through, and in the process it appears that I'd be burning through every bit of goodwill I might have previously possessed here. And, although I believe that the approach currently being taken to this spec is divisive of the community, I have to admit that since my attempts at education about the issues hasn't been particularly successful, it would appear that continuing to argue about it is no less divisive than what I'm arguing against. (For that matter, it's not even clear to me any more that most of the people on whose behalf I'm fighting would even realize yet why the future I want would be beneficial for them.) I really expected more people to see the benefits of the WSGI embedding approach, though, and although I've gotten a few private mails of support, it isn't anywhere near the level I thought it would be. Given the intense pressure that some parties are putting on having a spec *right* now, I don't feel that I can reasonably deliver a competing spec without interfering with my work and personal commitments in the next few weeks. Since I've already been using most of my Python community contribution time in the last week arguing about this, at this point it seems the community would be better served by me devoting that time to working on setuptools, rather than continuing to fight for a vision that hardly anybody else believes in. And, I'd rather save whatever karma I have left here for something with a better chance of success. Good luck with the spec. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/jim%40zope.com -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Bowing out (was Re: A trivial template API counter-proposal)
At 09:08 AM 2/7/2006 -0500, Jim Fulton wrote: I'm not sure what you're talking about here. Are you talking about WSGI? Or the templating effort? I've tuned out the templating discussion. Just the templating effort, and that only for the time being. I just don't feel I have enough time to devote to trying to compete in that area, since my take on it is very much against the grain of the popular approach. Despite some skepticism about the templating effort, I certainly planned to evaluate it when it settled down. I'm not complaining about you personally tuning out; it's just that I ended up being a sole advocate for stuff I thought Zope would need in order to utilize the template standard as a basis for views, without being certain of the details or whether you (i.e. zope.com and .org) actually cared (due to you having disappeared after your initial comment). (This of course also goes for other view-based and active page frameworks that have similar issues, but whose architects weren't around to comment in the first place.) I do think that the pioneering work you are doing with setuptools is far more important for Python, so I'd be happy to see you focus on that. :) I'd be especially interested in your thoughts on my current API for finding plugins posts on the distutils-sig, as I gather you're working in that area with Zope at the moment. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Bowing out (was Re: A trivial template API counter-proposal)
On Tuesday 07 February 2006 10:20, Phillip J. Eby wrote: Despite some skepticism about the templating effort, I certainly planned to evaluate it when it settled down. I'm not complaining about you personally tuning out; it's just that I ended up being a sole advocate for stuff I thought Zope would need in order to utilize the template standard as a basis for views, without being certain of the details or whether you (i.e. zope.com and .org) actually cared (due to you having disappeared after your initial comment). (This of course also goes for other view-based and active page frameworks that have similar issues, but whose architects weren't around to comment in the first place.) I phased out as well and decided to comment on a draft. The amount of E-mails just overwhelmed me. But I agree as well, that the egg work is more important. :-) BTW, did we reach a conclusion on the user logging issue. We really, really need to solve that somehow. Anything you can come up with is fine by me; I'll trust you do the right thing. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Bowing out (was Re: A trivial template API counter-proposal)
Phillip J. Eby wrote: Despite some skepticism about the templating effort, I certainly planned to evaluate it when it settled down. I'm not complaining about you personally tuning out; it's just that I ended up being a sole advocate for stuff I thought Zope would need in order to utilize the template standard as a basis for views, without being certain of the details or whether you (i.e. zope.com and .org) actually cared (due to you having disappeared after your initial comment). (This of course also goes for other view-based and active page frameworks that have similar issues, but whose architects weren't around to comment in the first place.) Maybe the reason those voices are missing -- I now realize -- is that there aren't many active page frameworks left. Spyce was, but since then I believe a more traditional controller-driven API has been added -- I don't know if the active part has been extracted from Spyce or not, but at least that portion is optional (and if you are embedding Spyce into another framework it is likely you won't want that part). Cheetah supports both models, but the active page model has long been discouraged. Webware's PSP is unmaintained. I suppose mod_python's PSP is similar as well, but I never got the impression anyone was championing that for anything. Both Myghty and Django have active-page-like ways of working with them, but because they have both techniques available there's still a fairly solid conceptual separation of the framework/controller and the template language. That's not to say active pages shouldn't be supported, but I think most of the people here see templates as generic content-builders as more fundamental than templates as web apps. Active pages then are an application of templates, not to be confused with the template itself. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Bowing out (was Re: A trivial template API counter-proposal)
At 11:12 AM 2/7/2006 -0600, Ian Bicking wrote: Maybe the reason those voices are missing -- I now realize -- is that there aren't many active page frameworks left. All the more reason to encourage an approach that allows migrating existing code written using those systems! :) I think it's also the case that active page systems are a useful stepping stone for people seeking to move up from PHP and ASP while learning Python, but now you're going to get me doing advocacy again. :) ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Bowing out (was Re: A trivial template API counter-proposal)
On Tue, 07 Feb 2006 11:12:04 -0600, Ian Bicking [EMAIL PROTECTED] said: Maybe the reason those voices are missing -- I now realize -- is that there aren't many active page frameworks left. Spyce was, but since then I believe a more traditional controller-driven API has been added Yes, but you can still write plain active-page stuff if you wanted to. -- I don't know if the active part has been extracted from Spyce or not, but at least that portion is optional (and if you are embedding Spyce into another framework it is likely you won't want that part). I'm not exactly sure what you have in mind here, but the active-page- ness of Spyce isn't really optional the way I think of it. Views still correspond one-to-one with .spy active pages. The new part is it's easy to put the controller in a separate .py file. (Spyce has always been able to import vanilly .py code, so separating out the model isn't new.) -Jonathan -- C++ is history repeated as tragedy. Java is history repeated as farce. --Scott McKay ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Bowing out (was Re: A trivial template API counter-proposal)
On Tue, Feb 07, 2006 at 11:12:04AM -0600, Ian Bicking wrote: Maybe the reason those voices are missing -- I now realize -- is that there aren't many active page frameworks left. Yup. SkunkWeb too, which like Myghty also started out as a port of Mason, now has a controller framework, with active pages as a fallback. But for that purpose -- for little content-oriented crusts left out of the application -- active pages sure come in handy, so giving them some extra consideration here is probably still worthwhile. -- Jacob Smullyan pgpz3bA0EYtsG.pgp Description: PGP signature ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
