Re: [Web-SIG] Session Handling in python
theres a mod_python FAQ entry on this which names several packages for session management: http://www.modpython.org/FAQ/faqw.py?req=showfile=faq03.008.htp the first one mentioned is my own, which can adapt to mod_python, CGI and WSGI interfaces. mohammad babaei said: Hi, what is the best way for Session Handling in python for production use ? regards ___ 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/mike_mp%40zzzcomputing.com ___ 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] Standardized configuration
While I'm not following every detail of this discussion, this line caught my attention - Ian Bicking said: Really, if you are building user-visible standard libraries, you are building a framework. only because Fowler recently posted something that made me think about this, where he distinguishes a framework as being something which employs the inversion of control principle, as Paste does, versus a library which does not: http://martinfowler.com/bliki/InversionOfControl.html . I know theres a lot of discussion over A Framework ? Not a Framework? lately, largely in response to the recent meme more frameworks == BAD that seems to be getting around these days; perhaps Fowler's distinction is helpful...I hadn't thought of it that way before. ___ 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] JavaScript libraries
what kind of features are you looking for in these javascript libraries ?
I see sarissa is just the XMLHttpRequest method tied to writing the guts
of DOM objects, and then some more elaborate DOM inspection methods that
seem less useful.
it seems to me that the server-neutral javascript part of AJAX is
nothing more than a single function to connect an XMLHttpRequest and feed
it to a callback function, and perhaps a couple of generic callback
functions, i.e. execute the javascript returned and write the HTML
returned into this DOM element. everything else is specific to a
particular application and/or server side approach.
I went and took the single connection function from the Sajax demo and
built a bunch of stuff off of that... once you can connect and get data,
document.getElementById('foo').innerHTML = blah can draw anything
anywhere you want.
I was meaning to look into Sarissa (http://sarissa.sourceforge.net/doc/)
which
was mentioned somewhere at some point fairly recently. It doesn't
interact
with specific server-side functionality, but we can whip that up quite
easily, can't we? ;-)
Wouldn't it be interesting if the web-sig community picked a
JavaScript library they all liked and mass invaded/contributed to it
;) Gees, with the WSGI thing, and the JavaScript thing, we'd
definitely be going in the right direction!
Best Regards,
-jj
--
I have decided to switch to Gmail, but messages to my Yahoo account will
still get through.
___
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/mike_mp%40zzzcomputing.com
___
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] JavaScript libraries
Now I am beginning to find some time for my happy workflow hacking... and things have changed a lot, it seems. I think it's about time for it to happen. It may seem a little bit simplistic of my part, but I truly believe that the programmer's nirvana can only be attained when we manage to hide the dozen different tools that are necessary today behind a single comprehensive framework. It makes no sense to me that we have to learn Python, JavaScript, HTML, CSS SQL -- at a minimum! -- to become productive in this profession. I can see the great value of abstracting away javascript events into a clean Python layer, so that custom application logic from client to server back to client again is coded in pure Python. All the Ajax libraries are trying to achieve this in various ways. I would agree less with regards to HTML and CSS, where I'd rather have HTML designers bringing their pre-made pages to me (and also allowing them to maintain the layout)...its less like a low level application library and more like the graphical facade placed on an application. Of course if someone ever designed a graphical WYSIWYG HTML/CSS editor that could do everything any designer ever wanted, and it generated sets of Python objects, that might make it more practical. With SQL an excessive amount of abstraction on the query side makes it hard to analyze and optimize queries, factor out performance bottlenecks, or to interface well with DBAs who would prefer to dictate the style and shape of queries from a pure SQL perspective. Abstration of the object-relational properties of result sets are a lot easier to manage, if you can flexibly define the information that should come out of those result sets. I think the query side of SQL wont be totally ignorable until true object databases begin gaining widespread acceptance. ___ 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] Re: Just lost another one to Rails
- I agree completely, that's why I'm adding yet another framework to the mix! (I'm waiting for someone to stand up at PyCon and say, Web App People's Front? We're the People's Front of Web Apps!) I think the term framework is becoming a little vague as well. there is the notion of framework as, the entire front-to-back approach to serve HTTP requests via Python, then there is the architectural approach that is used on top of an existing web API, and then there are templating languages which have varying degrees of pluggability into existing systems. I know that I chimed in with Myghty as well heres what I did!. But really, its 90% a templating language you can use with whatever framwork you want, and 10% an architectural approach which you can use more or less of. In all cases it requires a web API of some kind and doesnt try to replace that. And as far as templating languages for Python, I had a great need for it. The only other powerful options for python-embedded-html seemed to be Cheetah and Spyce, both of which did not fit the bill for me. I'm all for WSGI being as much of a standard as we should be embracing. But the Python community is a lot more varied than the Ruby one; people are thinking way out in their own boxes and have their preferred way of doing things (i.e. like people who only want to do python-generated HTML)...instead of reacting to and imitating the Ruby community, we should be presenting the world with our own community, where here are our favorite ways of doing web applications, but there are several varieties of how we do it. In the Python world, you have to use your brain a little bit. ___ 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
