Re: Vote on whether to integrate server side include (SSI) support.
Not seeing any negatives, I am going to go ahead and commit the SSI
stuff. Comments that this is just another way to skin a cat are true,
even if a small cat. I guess the reason for doing it is to fill out
those basic features that can be filled out by using just what Apache
provides.
Anyway, I'll try and get around to writing one of my mini articles
about the feature and also use some of that for inclusion into the
mod_python documentation itself. Maybe from writing a mini article
it might become more apparent how its simplicity can be just as useful
as any other approach for getting small tasks down quickly.
Graham
On 11/03/2006, at 1:43 AM, Gregory (Grisha) Trubetskoy wrote:
I don't understand this enough to have an opinion on it, seems like
another way to skin a cat, but to really form an opinion would require
some thinking on my part at least (may be I'm getting thick with age).
I think it'd be great if those who send in +1's (or -1's) would
explain why they think this is good, and even if it's not so useful,
then is it worth being supported and maintained in the future.
Grisha
On Fri, 10 Mar 2006, Jim Gallacher wrote:
+1
Graham Dumpleton wrote:
I have had patches for adding server side include support into
mod_python ready for a while now. See:
https://issues.apache.org/jira/browse/MODPYTHON-104
In short, it would add the ability to add Python code into files
being served up through the INCLUDES output filter. More
commonly this is known as server side include (SSI). For example:
!--#python exec= from mod_python import apache import cgi import
sys parts = apache.import_module('parts') def _escape(object):
return cgi.escape(str(object)) -- html body pre
!--#python eval=_escape(str(globals().keys()))-- !--#python
eval=_escape(str(locals().keys()))-- !--#python exec= print
filter for key in filter.req.subprocess_env: print filter,
_escape((key, filter.req.subprocess_env[key])) -- !--#python
eval=parts.content()-- /pre /body /html One could say
that there is an overlap between this and the
mod_python.psp handler, but the SSI feature is a builtin feature of
Apache and it make sense to support it. Using SSI, if one was mad
enough, you could even have Python and Perl code appearing in the one
file.
Anyway, the point of this email is to get a decision on whether this
major new feature should or should not be added into mod_python.
Core developer votes obviously matter the most, but others are more
than welcome to voice an opinion.
So, is it a Yes or a No?
Graham
Re: Vote on whether to integrate server side include (SSI) support.
* Graham Dumpleton wrote: Not seeing any negatives, I am going to go ahead and commit the SSI stuff. Comments that this is just another way to skin a cat are true, even if a small cat. I guess the reason for doing it is to fill out those basic features that can be filled out by using just what Apache provides. If that's a point, you know, what would be really great in this case? To be able to register own SSI handlers using mod_python instead of (or in addition to) this generic #python thingy, which nobody really seems to be able to classify/justify. Like registering a name and a callback function with a fixed signature. What do you think? nd -- die (eval q-qq:Just Another Perl Hacker :-) # André Malo, http://www.perlig.de/ #
Re: Vote on whether to integrate server side include (SSI) support.
On 12/03/2006, at 8:25 PM, André Malo wrote: * Graham Dumpleton wrote: Not seeing any negatives, I am going to go ahead and commit the SSI stuff. Comments that this is just another way to skin a cat are true, even if a small cat. I guess the reason for doing it is to fill out those basic features that can be filled out by using just what Apache provides. If that's a point, you know, what would be really great in this case? To be able to register own SSI handlers using mod_python instead of (or in addition to) this generic #python thingy, which nobody really seems to be able to classify/justify. Like registering a name and a callback function with a fixed signature. What do you think? I did think about it but deferred the idea in preference to at least getting some basic support for use of Python code with SSI in place. In other words, to take this initial step and then see whether people even consider using server side includes a viable way of doing stuff. These days there is so much focus on full blown frameworks that I am not sure that SSI even gets used much. I could well be wrong on that point. Do you have examples of SSI tag handlers that you might implement this way if such a feature were available? I ask as it all good to speculate on such a feature, but like this generic #python tag, would it in itself be used either? Graham
Re: Vote on whether to integrate server side include (SSI) support.
On 12/03/2006, at 9:04 PM, Graham Dumpleton wrote: On 12/03/2006, at 8:25 PM, André Malo wrote: * Graham Dumpleton wrote: Not seeing any negatives, I am going to go ahead and commit the SSI stuff. Comments that this is just another way to skin a cat are true, even if a small cat. I guess the reason for doing it is to fill out those basic features that can be filled out by using just what Apache provides. If that's a point, you know, what would be really great in this case? To be able to register own SSI handlers using mod_python instead of (or in addition to) this generic #python thingy, which nobody really seems to be able to classify/justify. Like registering a name and a callback function with a fixed signature. What do you think? I did think about it but deferred the idea in preference to at least getting some basic support for use of Python code with SSI in place. In other words, to take this initial step and then see whether people even consider using server side includes a viable way of doing stuff. These days there is so much focus on full blown frameworks that I am not sure that SSI even gets used much. I could well be wrong on that point. Do you have examples of SSI tag handlers that you might implement this way if such a feature were available? I ask as it all good to speculate on such a feature, but like this generic #python tag, would it in itself be used either? BTW, I should point out that one of the reasons for not rushing straight into allowing tag handler registration is that the same can be achieved with what is provided, albeit just more verbose and still exposing the fact that Python is used. All you need to do is put your common code that the tag handler would do in a Python function, import that module and call it. That is, you don't have to enumerate the complete code within the actual file being processed by mod_includes. The function can either query filter.req.subprocess_env for input parameters, or the point in the file where it is called can extract out the required values and pass them as explicit arguments to the function being called. All you thus get by having an explicit registered tag is that that Python is used can be hidden and a user would be none the wiser. Graham
Re: [jira] Assigned: (MODPYTHON-59) Add get_session() method to request object
I'm -1 on get_session() too. The request object is supposed to be a representation of Apache's request, and get_session() just does not belong there. Grisha On Sun, 12 Mar 2006, Jim Gallacher wrote: I handn't really intended to start working on an implementation. I just don't like seeing all those issues in JIRA marked as unassigned. :) Since I created it I figured I should take some responsibility for it. Plus, it's a gentle reminder when I list my assigned issues - resolve it one way or another. I still think we need some sort of solution to the problem of people trying to create 2 session instances in the same request, but I agree that the original concept of req.get_session() was not quite right. Jim Graham Dumpleton wrote: I would rather we not go ahead with adding req.get_session() at this time. At least not how it was envisaged to be done previously. I'll come back with a bit of analysis after I review where we were up to previously. Graham On 12/03/2006, at 8:47 AM, Jim Gallacher (JIRA) wrote: [ http://issues.apache.org/jira/browse/MODPYTHON-59?page=all ] Jim Gallacher reassigned MODPYTHON-59: -- Assign To: Jim Gallacher Add get_session() method to request object -- Key: MODPYTHON-59 URL: http://issues.apache.org/jira/browse/MODPYTHON-59 Project: mod_python Type: New Feature Components: session Versions: 3.1.4, 3.1.3, 3.2.7 Environment: All Reporter: Jim Gallacher Assignee: Jim Gallacher Fix For: 3.3 Attachments: Session.py.diff.txt Users will get session instances by calling req.get_session(). If a session already exists it will be returned, otherwise a new session instance will be created. Session configuration will be handled using apache directives rather than within their code. Using this scheme means only one session instance will be created per request, which will eliminate the deadlock problems many people experience. Also, using this scheme makes it possible for sessions to be properly handled within psp pages and across req.internal_redirect() calls. Code will be commited to svn shortly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
