Server side includes and Python.

2006-01-22 Thread Graham Dumpleton

A few weeks back I created a JIRA entry relating to integrating server
side includes with Python. The entry is:

  http://issues.apache.org/jira/browse/MODPYTHON-104

I finally got around to having a go at implementing it and have some
initial code now working. The point of this email is to get feedback on
the approach used and whether anyone has any alternate suggestions of
how it should in practice work, or any other ideas for that matter.

For those who might not know what server side includes are all about,
see:

  http://httpd.apache.org/docs/2.0/mod/mod_include.html

Effectively, what it is is an Apache output filter that will look for
SGML (HTML/XML) comments in content returned by a handler or as may be
found in a static file. It will identify specially tagged comments and
process them to yield new content which will be inserted in place in the
output instead of the original comment. The filter even supports
conditionals and is able to trigger sub requests and CGI scripts.

To cater for other sources of input, the filter can be extended to
support additional tags. For example, mod_perl adds the tag "perl",
allowing one to use:

  

  

Now, there is no reason that support for Python can't also be added and
it is actually quite straightforward to do. The only question that needs
to be answered is how it would be used. What one would get out of it is
a simple template mechanism which uses only mod_python and existing
features of Apache itself, and which can also be used in conjunction
with other modules like mod_perl as well.

Now for how the syntax would work. What I have got going at the moment
are the following two scenarios:

  

  

  

  
  


  

  

This first will run "eval" with the result being converted into a string
and included direct into the output.

The second will run "exec" instead. In this case there is no result and
thus filter.write() has to be used to generate the output.

In both cases, the "filter" object is pushed into the local variable
set and would be accessible.

When using "exec", multiple lines of Python code can be provided. As
usual Python indentation is always fun, and as such, when providing
multiple lines of code, you can't have leading whitespace unless it is
truly required for nesting.

  

  

  

  

  

Having to include all the code in the HTML isn't fun and it is actually
better to separate it out anyway.

To do that, one simply has to perform an import of the required module
and execute some function contained in it or access data and write it 
out.




If the target module is already the subject of automatic module 
reloading

as implemented by mod_python, you might instead use:



For "eval", one could provide a short cut mechanism whereby one could 
specify

the module in which the code should be evaluated.



Ie., this is essentially equivalent to having said:

  from mod_python import apache
  module = apache.import_module("sys")
  filter.write(str(eval("version", module.__dict__, {"filter":filter})))

The "module" short cut wouldn't exist for "exec" as any module imports 
then
performed would pollute the global name space of the specified module, 
which

may not be desirable.

As you can see, various things are possible but what is the minimum that
should be provided?

In the interests of discouraging a lot of code inside of a HTML file and
thus protecting people from themselves, should the "exec" variant above
be discarded, leaving just the "eval" variant? This would have the 
effect

of forcing users to put complex code into separate modules and simply
triggering calls of the separate code.



The only hard bit is how one should treat the response from the function
called. One could say that if the result of the eval is 'None' then no
output is written and if it was a function which was called, it is 
assumed

that the called function did that by writing back to the filter object.

In other words, the result of the eval isn't simply converted to a 
string.
This would only be done if result is not 'None', which 'None' truly 
meaning

no output.

Anyway, that is all there is to it.

Given that the intent here is to try and get this functionality rolled 
into
mod_python, any feedback would be most appreciated. No consensus 
probably

means it would get rejected.

Thanks.

Graham





[jira] Commented: (MODPYTHON-104) Allow Python code callouts with mod_include (SSI).

2006-01-22 Thread Graham Dumpleton (JIRA)
[ 
http://issues.apache.org/jira/browse/MODPYTHON-104?page=comments#action_12363559
 ] 

Graham Dumpleton commented on MODPYTHON-104:


See python-dev mailing list thread:

  http://www.mail-archive.com/python-dev@httpd.apache.org/msg01013.html

for possible syntax and issues. Hopefully feedback will be forthcoming from 
that. :-)

> Allow Python code callouts with mod_include (SSI).
> --
>
>  Key: MODPYTHON-104
>  URL: http://issues.apache.org/jira/browse/MODPYTHON-104
>  Project: mod_python
> Type: New Feature
>   Components: core
> Reporter: Graham Dumpleton
>  Fix For: 3.3

>
> The mod_include module supporting server side includes (SSI), provides a 
> means of registering new element tags which trigger callouts to other code in 
> separate Apache modules. This is used for example in mod_perl to allow Perl 
> language code to be used with server side includes:
>  
>   
> An equivalent feature for Python was previously asked about on the mailing 
> list back in 2004:
>   http://www.modpython.org/pipermail/mod_python/2004-January/014832.html
> Since it seems entirely reasonable that such integration of mod_python and 
> mod_include would be possible, thought it would be good to log it as a 
> possible new feature.
> Because of SSI's support for basic conditionals, includes and other callout 
> mechanisms, would be a good quick and dirty way of doing templating without 
> having to resort to PSP, or other high level templating systems.

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



Re: please set up a mod_python core group

2006-01-22 Thread Greg Stein
On Wed, Jan 18, 2006 at 08:01:07PM -0500, Jorey Bump wrote:
>...
> >So, please, take a few moments to decide amongst yourselves who
> >should have binding votes on mod_python (i.e., who has earned it),
>...
> I vote that Grisha gets all three votes. Benevolent dictatorship is the 
> Python way, after all.

But that isn't how Apache works. Therefore, it is a non-starter.

Cheers,
-g

-- 
[EMAIL PROTECTED] ... ASF Chairman ... http://www.apache.org/


Re: please set up a mod_python core group

2006-01-22 Thread Greg Stein
On Thu, Jan 19, 2006 at 03:04:43PM -0500, Gregory (Grisha) Trubetskoy wrote:
> 
> On Thu, 19 Jan 2006, Jorey Bump wrote:
> 
> >+1 here, but since the build process and typical MPM differs among 
> >platforms, could we see a list that this group represents?
> 
> This group would not represent any platforms when acting in _this_ 
> capacity. One of the group's responsibility would be to decide whether 
> sufficient number of platforms were represented by tests done by anyone on 
> this mailing list (including anyone from this group, of course).

Right. The +1 votes for a release simply represents the view, "is this
codebase ready for a release?" Whatever measures may apply is
completely irrelevant. If those with binding votes want to say +1 just
because it is Tuesday, then fine. But they're responsible for the
outcome, so I'm sure they'll want to take a little more caution.

What we're talking about is "who sets the direction? who has the final
say? who defines what mod_python is really about?"

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


Re: Server side includes and Python.

2006-01-22 Thread Deron Meranda
I like the SSI feature.  It would fill a nice gap between using
plain HTML files and having to go to a more featured template
or engine.  Some things are simple enough that the SSI concept
should be enough, and having Python would be nice.

I do need to give your proposal some more thought before I can
properly comment, but it looks interesting so far.

One thing I think that *should* be very easy to do in an SSI setting
is HTML-escaping.  I shouldn't have to do something like
'from cgi import escpe'.  Perhaps adding another parameter, like

 

where esc is a built-in escaping filter: h=html, u=url, x=xml
(difference between h and x is how it escapes quote chars).

Another question.  How are character sets handled?  If the
output is a Unicode string, how does it get encoded?  Should
it always asume say UTF-8, or can it determine the actual
character encoding for this reponse somehow?

Also, my vote is that None should result in no output.
--
Deron Meranda