Genshi Templates
24 views
Skip to first unread message
Timbo
Jul 24, 2008, 4:25:51 PM7/24/08
to web2py Web Framework
Massimo,
I know you built web2py's template language for specific reasons. I
already mentioned that I'm heavily invested in Genshi where I work.
Rather than adding boilerplate code to all my controller methods, I
added native support for Genshi templates to web2py.
Would you be interested in including such a patch?
It's not complete yet, but I am curious if you are interested.
-tim
I know you built web2py's template language for specific reasons. I
already mentioned that I'm heavily invested in Genshi where I work.
Rather than adding boilerplate code to all my controller methods, I
added native support for Genshi templates to web2py.
Would you be interested in including such a patch?
It's not complete yet, but I am curious if you are interested.
-tim
Massimo Di Pierro
Jul 24, 2008, 6:36:14 PM7/24/08
to web...@googlegroups.com
For sure I would like to see it.
Massimo
Timbo
Jul 25, 2008, 1:29:15 PM7/25/08
to web2py Web Framework
For lack of a better method, I've cut/pasted it below...
What you get:
- You can use any Markup Genshi template as a View (like you would a
normal web2py view)
- Genshi's include function works the same so templates can include
(and extend but it's not called that) other templates
- Genshi's HTMLFormFiller works. Include dict('HTMLFormFill' =
{'inputname':'inputvalue'} in the dict returned by your controller
- The admin interface will show what views include other templates
What you don't get:
- You can't mix template types. (Genshi can't include or extend
Web2py templates or vice versa)
- consequently there is no default template (i.e. layout.html) that
supports session.flash(), you'll have to code your own
- Genshi Templates aren't (can't be) compiled, however Genshi's
template loader does cache templates; which provides a similar
function to compilation
- Genshi Templates are slower, (not by much though, if you're really
concerned about speed here, you should be using C instead of Python)
- This patch is against 1.39 stable, NOT TRUNK. (sorry, I'm working
with stable right now; the changes are few, it might import into
trunk)
- I haven't tested SQLFORM and the like (but I don't see a good
reason why they wouldn't work)
- I've included 2 free spelling corrections. =)
- This is only for Genshi HTML/XML templates. Genshi supports Text-
based templates but this patch does not implement nor recognize them.
I'll be developing this patch further, possibly to add Text
templating, SQLFORM and some form of compilation (pickles?) if I need
it.
-tim
---------------
--- /web2py/gluon/compileapp.py-rev39.svn000.tmp Fri Jul 25 11:16:47
2008
+++ /web2py/gluon/compileapp.py Fri Jul 25 11:16:47 2008
@@ -5,7 +5,7 @@
"""
import sys; sys.path.append('../gluon')
-from template import parse_template
+from template import parse_template, isGenshiTemplate
from restricted import restricted
from fileutils import listdir
from myregex import regex_expose
@@ -17,11 +17,24 @@
import validators
from http import HTTP, redirect
import os, marshal, imp, types, doctest, logging
+try:
+ from genshi.template import TemplateLoader, Context
+ from genshi.filters.html import HTMLFormFiller
+ Genshi = True
+except:
+ logging.warning('no Genshi module, Genshi templates disabled.')
+ Genshi = False
try: import py_compile
except: logging.warning("unable to import py_compile")
error_message='<html><body><h1>Invalid request</h1>%s</body></html>'
+# Preload our template loader
+if Genshi: loader = TemplateLoader('/', auto_reload=True)
+
TEST_CODE=r"""
def _TEST():
import doctest, sys, cStringIO, types, cgi, gluon.fileutils
@@ -80,11 +93,13 @@
def compile_views(folder):
"""
- compiles all the views in the applicaiton specified by the
+ compiles all the views in the application specified by the
current folder
"""
path=os.path.join(folder,'views/')
for file in listdir(path,'.+\.html$'):
+ if isGenshiTemplate(filename=file):
+ continue
data=parse_template(file,path)
filename=os.path.join(folder,'compiled/',
('views/'+file[:-5]+'.py').replace('/','_').replace('\\','_'))
open(filename,'w').write(data)
@@ -181,7 +196,7 @@
def run_view_in(environment):
"""
- exectutes the view in resposne.view or generic.html.
+ exectutes the view in response.view or generic.html.
it tries the precompiled views_controller_funciton.pyc first.
"""
folder=environment['request'].folder
@@ -195,7 +210,6 @@
raise HTTP(400,error_message % 'invalid view',
web2py_error='invalid view')
code=read_pyc(filename)
- #response.body=restricted(code,environment,layer=filename)
restricted(code,environment,layer=filename)
else:
filename=os.path.join(folder,'views/',response.view)
@@ -205,9 +219,23 @@
if not os.path.exists(filename):
raise HTTP(400,error_message % 'invalid view',
web2py_error='invalid view')
-
code=parse_template(response.view,os.path.join(folder,'views/'),
- context=environment)
- restricted(code,environment,layer=filename)
+ viewloc = os.path.join(os.path.normpath(folder), 'views')
+ viewfullPath = os.path.join(viewloc,
os.path.normpath(response.view))
+ if Genshi and isGenshiTemplate(filename=viewfullPath):
+ tmpl = loader.load(viewfullPath)
+ ctxt = Context() # You can't construct a Context from a
mappable
+ ctxt.update(environment) # but you can update with it,
this is brain-damaged.
+ output = tmpl.generate(ctxt)
+ formfill = environment.get('HTMLFormFill')
+ if formfill and type(formfill) == types.DictType:
+ f = HTMLFormFiller(data=formfill)
+ output = output.filter(f)
+ output = output.render('html', doctype='html')
+ environment['response'].write(output, escape=False)
+ else:
+ code=parse_template(response.view,viewloc,
+ context=environment)
+ restricted(code,environment,layer=filename)
def remove_compiled_application(folder):
try:
--- /web2py/gluon/template.py-rev39.svn001.tmp Fri Jul 25 11:18:28
2008
+++ /web2py/gluon/template.py Fri Jul 25 11:18:28 2008
@@ -23,6 +23,7 @@
re_include_nameless=re.compile('\{\{\s*include\s*\}\}')
re_include=re.compile('\{\{\s*include\s+(?P<name>.+?)\s*\}
\}',re.DOTALL)
re_extend=re.compile('\{\{\s*extend\s+(?P<name>.+?)\s*\}
\}',re.DOTALL)
+re_genshi = re.compile(r'<\s*html .*xmlns:py="http://
genshi.edgewall.org/".*>',re.IGNORECASE | re.DOTALL)
def reindent(text):
lines=text.split('\n')
@@ -67,6 +68,7 @@
try: data=open(os.path.join(path,filename),'rb').read()
except IOError: raise RestrictedError('Processing View
'+filename,
'','Unable to find the file')
+
# check whether it extends a layout
while 1:
match=re_extend.search(data)
@@ -94,6 +96,20 @@
text=replace(re_html,text,lambda x:
'\nresponse.write(%s,escape=False)\n'%repr(x[2:-2]))
text=replace(re_strings,text,lambda x: x.replace('\n','\\n'))
return reindent(text)
+
+def isGenshiTemplate(filename = False, data=''):
+ '''Checks if a file or a string contains a Genshi Template.'''
+ # BUFFERSIZE: If we can find the genshi tag in BUFFERSIZE bytes
then
+ # default to False. Prevents reading through very large files
(and slowing
+ # down what needs to be a fast process.
+ BUFFERSIZE = 512
+ if filename:
+ try:
+ data = open(filename).read(BUFFERSIZE)
+ except IOError, e:
+ return False
+ return bool(re_genshi.search(data))
+
if __name__=='__main__':
print parse_template(sys.argv[1],path='../applications/welcome/
views/')
--- /web2py/gluon/myregex.py-rev39.svn001.tmp Fri Jul 25 11:18:42 2008
+++ /web2py/gluon/myregex.py Fri Jul 25 11:18:42 2008
@@ -5,6 +5,8 @@
"""
import re
+try: from genshi import template; Genshi = True
+except ImportError, e: Genshi = False
# pattern to find defined tables
regex_tables=re.compile("""^[\w]+\.define_table\(\s*[\'\"](?
P<name>[\w_]+)[\'\"]""",flags=re.M)
@@ -12,6 +14,10 @@
# pattern to find exposed functions in controller
regex_expose=re.compile('^def\s+(?P<name>(?:[a-zA-Z0-9]\w*)|(?:_[a-zA-
Z0-9]\w*))\(\)\s*:',flags=re.M)
-regex_include=re.compile('(?P<all>\{\{\s*include\s+[\'"](?P<name>[^
\']*)[\'"]\s*\}\})')
+# Genshi templates also can include other templates
+if Genshi:
+ regex_include=re.compile('(?P<all>(?:\{\{\s*include\s+[\'"]|
<xi:include\s+href=[\'"])(?P<name>[^\'"]*)[\'"]\s*(?:\}\}|(?:/>|>\s*</
xi:include>)))')
+else:
+ regex_include=re.compile('(?P<all>\{\{\s*include\s+[\'"](?
P<name>[^\']*)[\'"]\s*\}\})')
regex_extend=re.compile('^\s*(?P<all>\{\{\s*extend\s+[\'"](?P<name>[^
\']+)[\'"]\s*\}\})')
-------------
What you get:
- You can use any Markup Genshi template as a View (like you would a
normal web2py view)
- Genshi's include function works the same so templates can include
(and extend but it's not called that) other templates
- Genshi's HTMLFormFiller works. Include dict('HTMLFormFill' =
{'inputname':'inputvalue'} in the dict returned by your controller
- The admin interface will show what views include other templates
What you don't get:
- You can't mix template types. (Genshi can't include or extend
Web2py templates or vice versa)
- consequently there is no default template (i.e. layout.html) that
supports session.flash(), you'll have to code your own
- Genshi Templates aren't (can't be) compiled, however Genshi's
template loader does cache templates; which provides a similar
function to compilation
- Genshi Templates are slower, (not by much though, if you're really
concerned about speed here, you should be using C instead of Python)
- This patch is against 1.39 stable, NOT TRUNK. (sorry, I'm working
with stable right now; the changes are few, it might import into
trunk)
- I haven't tested SQLFORM and the like (but I don't see a good
reason why they wouldn't work)
- I've included 2 free spelling corrections. =)
- This is only for Genshi HTML/XML templates. Genshi supports Text-
based templates but this patch does not implement nor recognize them.
I'll be developing this patch further, possibly to add Text
templating, SQLFORM and some form of compilation (pickles?) if I need
it.
-tim
---------------
--- /web2py/gluon/compileapp.py-rev39.svn000.tmp Fri Jul 25 11:16:47
2008
+++ /web2py/gluon/compileapp.py Fri Jul 25 11:16:47 2008
@@ -5,7 +5,7 @@
"""
import sys; sys.path.append('../gluon')
-from template import parse_template
+from template import parse_template, isGenshiTemplate
from restricted import restricted
from fileutils import listdir
from myregex import regex_expose
@@ -17,11 +17,24 @@
import validators
from http import HTTP, redirect
import os, marshal, imp, types, doctest, logging
+try:
+ from genshi.template import TemplateLoader, Context
+ from genshi.filters.html import HTMLFormFiller
+ Genshi = True
+except:
+ logging.warning('no Genshi module, Genshi templates disabled.')
+ Genshi = False
try: import py_compile
except: logging.warning("unable to import py_compile")
error_message='<html><body><h1>Invalid request</h1>%s</body></html>'
+# Preload our template loader
+if Genshi: loader = TemplateLoader('/', auto_reload=True)
+
TEST_CODE=r"""
def _TEST():
import doctest, sys, cStringIO, types, cgi, gluon.fileutils
@@ -80,11 +93,13 @@
def compile_views(folder):
"""
- compiles all the views in the applicaiton specified by the
+ compiles all the views in the application specified by the
current folder
"""
path=os.path.join(folder,'views/')
for file in listdir(path,'.+\.html$'):
+ if isGenshiTemplate(filename=file):
+ continue
data=parse_template(file,path)
filename=os.path.join(folder,'compiled/',
('views/'+file[:-5]+'.py').replace('/','_').replace('\\','_'))
open(filename,'w').write(data)
@@ -181,7 +196,7 @@
def run_view_in(environment):
"""
- exectutes the view in resposne.view or generic.html.
+ exectutes the view in response.view or generic.html.
it tries the precompiled views_controller_funciton.pyc first.
"""
folder=environment['request'].folder
@@ -195,7 +210,6 @@
raise HTTP(400,error_message % 'invalid view',
web2py_error='invalid view')
code=read_pyc(filename)
- #response.body=restricted(code,environment,layer=filename)
restricted(code,environment,layer=filename)
else:
filename=os.path.join(folder,'views/',response.view)
@@ -205,9 +219,23 @@
if not os.path.exists(filename):
raise HTTP(400,error_message % 'invalid view',
web2py_error='invalid view')
-
code=parse_template(response.view,os.path.join(folder,'views/'),
- context=environment)
- restricted(code,environment,layer=filename)
+ viewloc = os.path.join(os.path.normpath(folder), 'views')
+ viewfullPath = os.path.join(viewloc,
os.path.normpath(response.view))
+ if Genshi and isGenshiTemplate(filename=viewfullPath):
+ tmpl = loader.load(viewfullPath)
+ ctxt = Context() # You can't construct a Context from a
mappable
+ ctxt.update(environment) # but you can update with it,
this is brain-damaged.
+ output = tmpl.generate(ctxt)
+ formfill = environment.get('HTMLFormFill')
+ if formfill and type(formfill) == types.DictType:
+ f = HTMLFormFiller(data=formfill)
+ output = output.filter(f)
+ output = output.render('html', doctype='html')
+ environment['response'].write(output, escape=False)
+ else:
+ code=parse_template(response.view,viewloc,
+ context=environment)
+ restricted(code,environment,layer=filename)
def remove_compiled_application(folder):
try:
--- /web2py/gluon/template.py-rev39.svn001.tmp Fri Jul 25 11:18:28
2008
+++ /web2py/gluon/template.py Fri Jul 25 11:18:28 2008
@@ -23,6 +23,7 @@
re_include_nameless=re.compile('\{\{\s*include\s*\}\}')
re_include=re.compile('\{\{\s*include\s+(?P<name>.+?)\s*\}
\}',re.DOTALL)
re_extend=re.compile('\{\{\s*extend\s+(?P<name>.+?)\s*\}
\}',re.DOTALL)
+re_genshi = re.compile(r'<\s*html .*xmlns:py="http://
genshi.edgewall.org/".*>',re.IGNORECASE | re.DOTALL)
def reindent(text):
lines=text.split('\n')
@@ -67,6 +68,7 @@
try: data=open(os.path.join(path,filename),'rb').read()
except IOError: raise RestrictedError('Processing View
'+filename,
'','Unable to find the file')
+
# check whether it extends a layout
while 1:
match=re_extend.search(data)
@@ -94,6 +96,20 @@
text=replace(re_html,text,lambda x:
'\nresponse.write(%s,escape=False)\n'%repr(x[2:-2]))
text=replace(re_strings,text,lambda x: x.replace('\n','\\n'))
return reindent(text)
+
+def isGenshiTemplate(filename = False, data=''):
+ '''Checks if a file or a string contains a Genshi Template.'''
+ # BUFFERSIZE: If we can find the genshi tag in BUFFERSIZE bytes
then
+ # default to False. Prevents reading through very large files
(and slowing
+ # down what needs to be a fast process.
+ BUFFERSIZE = 512
+ if filename:
+ try:
+ data = open(filename).read(BUFFERSIZE)
+ except IOError, e:
+ return False
+ return bool(re_genshi.search(data))
+
if __name__=='__main__':
print parse_template(sys.argv[1],path='../applications/welcome/
views/')
--- /web2py/gluon/myregex.py-rev39.svn001.tmp Fri Jul 25 11:18:42 2008
+++ /web2py/gluon/myregex.py Fri Jul 25 11:18:42 2008
@@ -5,6 +5,8 @@
"""
import re
+try: from genshi import template; Genshi = True
+except ImportError, e: Genshi = False
# pattern to find defined tables
regex_tables=re.compile("""^[\w]+\.define_table\(\s*[\'\"](?
P<name>[\w_]+)[\'\"]""",flags=re.M)
@@ -12,6 +14,10 @@
# pattern to find exposed functions in controller
regex_expose=re.compile('^def\s+(?P<name>(?:[a-zA-Z0-9]\w*)|(?:_[a-zA-
Z0-9]\w*))\(\)\s*:',flags=re.M)
-regex_include=re.compile('(?P<all>\{\{\s*include\s+[\'"](?P<name>[^
\']*)[\'"]\s*\}\})')
+# Genshi templates also can include other templates
+if Genshi:
+ regex_include=re.compile('(?P<all>(?:\{\{\s*include\s+[\'"]|
<xi:include\s+href=[\'"])(?P<name>[^\'"]*)[\'"]\s*(?:\}\}|(?:/>|>\s*</
xi:include>)))')
+else:
+ regex_include=re.compile('(?P<all>\{\{\s*include\s+[\'"](?
P<name>[^\']*)[\'"]\s*\}\})')
regex_extend=re.compile('^\s*(?P<all>\{\{\s*extend\s+[\'"](?P<name>[^
\']+)[\'"]\s*\}\})')
-------------
Massimo Di Pierro
Jul 25, 2008, 3:01:11 PM7/25/08
to web...@googlegroups.com
Give me a couple of days to study this... Thanks.
Massimo
Massimo Di Pierro
Jul 25, 2008, 3:15:32 PM7/25/08
to web...@googlegroups.com
While I look into this.... I would like to hear other people opinions
about adding something like this.
about adding something like this.
In principle I have no objection in adding this functionality but I
would not like to patch the core files for every template language
that people want to use.
Perhaps there should be a mechanism to allow genshi (and other
template) support via decorators defined in a
gluon.contrib.templates.genshi file.
Or should we consider genshi special? Is there a reason to do it the
proposed way?
Massimo
On Jul 25, 2008, at 12:29 PM, Timbo wrote:
Kyle Smith
Jul 25, 2008, 3:33:30 PM7/25/08
to web...@googlegroups.com
I think supporting multiple template engines is going to be desirable in the long run as there are always going to be people that want to use their existing views if they have a significant amount of time invested. I also think that only supporting one template is probably a mistake. There are plenty of reasons why someone might prefer mako, genshi, cheetah or some other template. By using a template loader via decorators or some other method we allow for seperation of the template from gluon by keeping it in contrib, and we allow those that want additional templates to have them. Since we have someone already adding Genshi support then that's probably the best place to start, but I don't see any reason why it should be special, or other why it would be logical to not make an easy way for any template engine to be integrated.
Kyle
Kyle
yarko
Jul 25, 2008, 5:25:20 PM7/25/08
to web2py Web Framework
+1
==> for the simple reason that it is a good way (also) to allow
evolution... supported templating to next-generation templating...
reduces the eternal "breaks backward compatibility" bind...
On Jul 25, 2:33 pm, "Kyle Smith" <kyletsm...@gmail.com> wrote:
> I think supporting multiple template engines is going to be desirable in the
> long run as there are always going to be people that want to use their
> existing views if they have a significant amount of time invested. I also
> think that only supporting one template is probably a mistake. There are
> plenty of reasons why someone might prefer mako, genshi, cheetah or some
> other template. By using a template loader via decorators or some other
> method we allow for seperation of the template from gluon by keeping it in
> contrib, and we allow those that want additional templates to have them.
> Since we have someone already adding Genshi support then that's probably the
> best place to start, but I don't see any reason why it should be special, or
> other why it would be logical to not make an easy way for any template
> engine to be integrated.
>
> Kyle
>
> On Fri, Jul 25, 2008 at 12:15 PM, Massimo Di Pierro <mdipie...@cs.depaul.edu>
> ...
>
> read more »
==> for the simple reason that it is a good way (also) to allow
evolution... supported templating to next-generation templating...
reduces the eternal "breaks backward compatibility" bind...
On Jul 25, 2:33 pm, "Kyle Smith" <kyletsm...@gmail.com> wrote:
> I think supporting multiple template engines is going to be desirable in the
> long run as there are always going to be people that want to use their
> existing views if they have a significant amount of time invested. I also
> think that only supporting one template is probably a mistake. There are
> plenty of reasons why someone might prefer mako, genshi, cheetah or some
> other template. By using a template loader via decorators or some other
> method we allow for seperation of the template from gluon by keeping it in
> contrib, and we allow those that want additional templates to have them.
> Since we have someone already adding Genshi support then that's probably the
> best place to start, but I don't see any reason why it should be special, or
> other why it would be logical to not make an easy way for any template
> engine to be integrated.
>
> Kyle
>
>
> read more »
Timbo
Jul 25, 2008, 5:30:21 PM7/25/08
to web2py Web Framework
Being new here, I understand that my opinion would be weighed
accordingly. Regardless, here goes...
Adding many templates (probably via the Buffet interface):
Pros:
- Lots of templates = more attractive as a migration target and more
flexible
- IMHO, web2py's current template language looks like PERL (very
difficult to pick up and know what's going on)
Cons:
- Less consistency = more work for the developers
- Watch out for template flamewars in the forums
- Adding a way to specify a template engine means more boilerplate
code whereas right now it's automatic (my patch maintains this)
- Will we still get automatic form validation?
Kevin, I think there is a significant jump from supporting one (or
two) template engines to supporting many. It just so happened that
Genshi and web2py native templates are so different that a simple
regexp is enough to distinguish between the two. Unfortunately this
isn't always the case. If we were to maintain the automaticness that
web2py has in selecting template engines (and I think this is very
important) then we can only reasonably support a few without adding
conventions (such as using different file extensions) or decorators
(which means more boilerplate code). History shows that the most
successful projects limit themselves to grow slowly and work on
developing the core rather than being the salad bar of projects (i.e.
emacs).
However, there is a unified way to support many different
templates...Buffet. Backward compatibility is the biggest hurdle (but
well worth it).
> ...
>
> read more »
accordingly. Regardless, here goes...
Adding many templates (probably via the Buffet interface):
Pros:
- Lots of templates = more attractive as a migration target and more
flexible
- IMHO, web2py's current template language looks like PERL (very
difficult to pick up and know what's going on)
Cons:
- Less consistency = more work for the developers
- Watch out for template flamewars in the forums
- Adding a way to specify a template engine means more boilerplate
code whereas right now it's automatic (my patch maintains this)
- Will we still get automatic form validation?
Kevin, I think there is a significant jump from supporting one (or
two) template engines to supporting many. It just so happened that
Genshi and web2py native templates are so different that a simple
regexp is enough to distinguish between the two. Unfortunately this
isn't always the case. If we were to maintain the automaticness that
web2py has in selecting template engines (and I think this is very
important) then we can only reasonably support a few without adding
conventions (such as using different file extensions) or decorators
(which means more boilerplate code). History shows that the most
successful projects limit themselves to grow slowly and work on
developing the core rather than being the salad bar of projects (i.e.
emacs).
However, there is a unified way to support many different
templates...Buffet. Backward compatibility is the biggest hurdle (but
well worth it).
> I think supporting multiple template engines is going to be desirable in the
> long run as there are always going to be people that want to use their
> existing views if they have a significant amount of time invested. I also
> think that only supporting one template is probably a mistake. There are
> plenty of reasons why someone might prefer mako, genshi, cheetah or some
> other template. By using a template loader via decorators or some other
> method we allow for seperation of the template from gluon by keeping it in
> contrib, and we allow those that want additional templates to have them.
> Since we have someone already adding Genshi support then that's probably the
> best place to start, but I don't see any reason why it should be special, or
> other why it would be logical to not make an easy way for any template
> engine to be integrated.
>
> Kyle
>
> On Fri, Jul 25, 2008 at 12:15 PM, Massimo Di Pierro <mdipie...@cs.depaul.edu>
> long run as there are always going to be people that want to use their
> existing views if they have a significant amount of time invested. I also
> think that only supporting one template is probably a mistake. There are
> plenty of reasons why someone might prefer mako, genshi, cheetah or some
> other template. By using a template loader via decorators or some other
> method we allow for seperation of the template from gluon by keeping it in
> contrib, and we allow those that want additional templates to have them.
> Since we have someone already adding Genshi support then that's probably the
> best place to start, but I don't see any reason why it should be special, or
> other why it would be logical to not make an easy way for any template
> engine to be integrated.
>
> Kyle
>
>
> read more »
Stuart Rackham
Jul 25, 2008, 6:32:05 PM7/25/08
to web...@googlegroups.com
-1
I'm wary of ``enhancements'' like this because I can't see anything
radically new or better, so it's really just a marketing thing to
attract developers who don't want to learn a new templating system or
don't like the current one.
Once you start down this road you begin breaking web2py's greatest
strengths: simplicity, elegance and consistency. These are the reasons
I'm using web2py because it's small, elegant and intellectually
manageable. You can never please everyone -- if you try you end up
pleasing no one. Plus you've now got the all problems of 3rd party
library dependence that Massimo has talked about in the past.
Massimo wrote a really good post touching on these issues:
http://groups.google.com/group/web2py/browse_thread/thread/c090560680b65db2#msg_d7e2e220f03da5b0
Every line of code adds future compatibility constraints and has to be
maintained; every new library has there own set of bugs and every new
feature adds to the web2py learning curve. So lets only add features if
they are genuinely useful, add something new that can't otherwise be
done and are seamlessly integrated into web2py.
Just my opinons though :-)
Cheers, Stuart
Massimo Di Pierro wrote:
> While I look into this.... I would like to hear other people opinions
> about adding something like this.
>
> In principle I have no objection in adding this functionality but I
> would not like to patch the core files for every template language
> that people want to use.
> Perhaps there should be a mechanism to allow genshi (and other
> template) support via decorators defined in a
> gluon.contrib.templates.genshi file.
>
> Or should we consider genshi special? Is there a reason to do it the
> proposed way?
>
> Massimo
[...]
blackthorne
Jul 25, 2008, 9:05:02 PM7/25/08
to web2py Web Framework
+1.
I agree that consistency, simplicity should be a priority by default
but I don't think we should neglect flexibility. I am not defending
Genshi, I'm defending code that doesn't force you to be stuck on all
default components.
Contrarly, to your comment I think some lines of code decrease future
constraints. I.e., implementing a configuration system that allows you
to choose the components used by web2py.
Any solution that takes advantage of work already done is valuable.
Francisco
On Jul 25, 11:32 pm, Stuart Rackham <srack...@gmail.com> wrote:
> -1
>
> I'm wary of ``enhancements'' like this because I can't see anything
> radically new or better, so it's really just a marketing thing to
> attract developers who don't want to learn a new templating system or
> don't like the current one.
>
> Once you start down this road you begin breaking web2py's greatest
> strengths: simplicity, elegance and consistency. These are the reasons
> I'm using web2py because it's small, elegant and intellectually
> manageable. You can never please everyone -- if you try you end up
> pleasing no one. Plus you've now got the all problems of 3rd party
> library dependence that Massimo has talked about in the past.
>
> Massimo wrote a really good post touching on these issues:
>
> http://groups.google.com/group/web2py/browse_thread/thread/c090560680...
I agree that consistency, simplicity should be a priority by default
but I don't think we should neglect flexibility. I am not defending
Genshi, I'm defending code that doesn't force you to be stuck on all
default components.
Contrarly, to your comment I think some lines of code decrease future
constraints. I.e., implementing a configuration system that allows you
to choose the components used by web2py.
Any solution that takes advantage of work already done is valuable.
Francisco
On Jul 25, 11:32 pm, Stuart Rackham <srack...@gmail.com> wrote:
> -1
>
> I'm wary of ``enhancements'' like this because I can't see anything
> radically new or better, so it's really just a marketing thing to
> attract developers who don't want to learn a new templating system or
> don't like the current one.
>
> Once you start down this road you begin breaking web2py's greatest
> strengths: simplicity, elegance and consistency. These are the reasons
> I'm using web2py because it's small, elegant and intellectually
> manageable. You can never please everyone -- if you try you end up
> pleasing no one. Plus you've now got the all problems of 3rd party
> library dependence that Massimo has talked about in the past.
>
> Massimo wrote a really good post touching on these issues:
>
voltron
Jul 26, 2008, 2:34:25 AM7/26/08
to web2py Web Framework
I am for evolution, but I dont think that Massimo should think about
supporting other template languages as a core functionality, if there
is to be support, then it should be as decorators.
Other reasons against supporting other languages are:
1. The danger of "catchup" if the other templating languages get
modified somehow and break in Web2py.
2. More code to maintain.
3. Not many decisive benefits of other languages in comparison to
Web2pys language.
4. Allowing other languages might stifle the evolution of web2py
native templating language.
I think that good software do not have to "throw in the kitchen sink"
to attract developers, sometimes its just plain overkill. Lots of
successful companies follow this principle, Google is a great example.
I am for a strong, simple feature set that is rock sold, these were
the features that attracted me to Web2py and that was even when it was
not advanced as it is now, there were about only 30 members or less on
the list :-)
I like Massimos initial take on this issue, he choose "bits and
pieces" from other languages and decided to add them to web2py, maybe
it would benefit Web2py if developers come forward and help adding or
asking for features to enhance web2pys.
I think this issues should not be rushed, we should all take a look at
the languages that might come in question and weigh them against
web2py first.
3. ,
2. lWeb2pys templating language is simple and can be learned in a few
minutes, I was very thankful for this
supporting other template languages as a core functionality, if there
is to be support, then it should be as decorators.
Other reasons against supporting other languages are:
1. The danger of "catchup" if the other templating languages get
modified somehow and break in Web2py.
2. More code to maintain.
3. Not many decisive benefits of other languages in comparison to
Web2pys language.
4. Allowing other languages might stifle the evolution of web2py
native templating language.
I think that good software do not have to "throw in the kitchen sink"
to attract developers, sometimes its just plain overkill. Lots of
successful companies follow this principle, Google is a great example.
I am for a strong, simple feature set that is rock sold, these were
the features that attracted me to Web2py and that was even when it was
not advanced as it is now, there were about only 30 members or less on
the list :-)
I like Massimos initial take on this issue, he choose "bits and
pieces" from other languages and decided to add them to web2py, maybe
it would benefit Web2py if developers come forward and help adding or
asking for features to enhance web2pys.
I think this issues should not be rushed, we should all take a look at
the languages that might come in question and weigh them against
web2py first.
3. ,
2. lWeb2pys templating language is simple and can be learned in a few
minutes, I was very thankful for this
Massimo Di Pierro
Jul 26, 2008, 3:44:28 AM7/26/08
to web...@googlegroups.com
I am with Voltron and Stuart on this.
Why is Rails so successful when compared with Django or Pylons? It is
not because of its extensibility but because of its simplicity.
Simplicity means it is easy to learn, easy to maintain, people can
build a culture and a community around it.
web2py has it own template language that very closely mimic the rails
one since it has proven to be successful. It copied from Django the
use of {{ }} instead of <% %> because this allows the use of html
editors.
Timbo has done an execllent job with adding support of the Genshi
templates and his code clearly shows he understands web2py. I suggest
that
Timbo rewrites his code in the form os a render_as_genshi or as a
decorator or both that it can go into a a separate module file and
that it will not need modification of the core web2py code. This
module cannot be part of web2py because it has dependencies (the
Genshi template engine) but I will be happy to post it with
documentation as an AlterEgo page.
Massimo
yarko
Jul 26, 2008, 8:06:22 AM7/26/08
to web2py Web Framework
Well, this is what I meant by "support" other render engines - that
is, make it easy to inset an alternate rendering module (not support
internally engines of all sorts! Blech!!!).
In principle (and this is not so important) the only difference from
what Massimo, Voltron, Stuart suggest is that I intended to suggest is
ALL rendering engines (including web2py's) be presented as a rendering
module. This is perhaps too much work to do now, but I hope you get
my point: If it's worth evolving, it's worth modularizing....
Yarko
is, make it easy to inset an alternate rendering module (not support
internally engines of all sorts! Blech!!!).
In principle (and this is not so important) the only difference from
what Massimo, Voltron, Stuart suggest is that I intended to suggest is
ALL rendering engines (including web2py's) be presented as a rendering
module. This is perhaps too much work to do now, but I hope you get
my point: If it's worth evolving, it's worth modularizing....
Yarko
yarko
Jul 26, 2008, 8:12:18 AM7/26/08
to web2py Web Framework
...but then again, the current rendering engine _is_ just python code,
and as Voltron points out - how much easier can you get than
that ... ;-)
and as Voltron points out - how much easier can you get than
that ... ;-)
Kyle Smith
Jul 26, 2008, 4:57:20 PM7/26/08
to web...@googlegroups.com
I should note that I also was not implying that gluon should natively support any other template engines, or should ship with them. I was simply trying to say that it makes a lot of sense to support an easy method for developers to choose a different template engine either via some type of template loader apparatus, decorators etc. I think that method would be far preferable to including any template engine other than the native one.
Kyle
Kyle
Timbo
Jul 26, 2008, 7:45:32 PM7/26/08
to web2py Web Framework
Granted. I'm not sure what you mean by writing it as a
"render_as_genshi". Can you elaborate?
Thanks,
tim
"render_as_genshi". Can you elaborate?
Thanks,
tim
yarko
Jul 26, 2008, 8:43:57 PM7/26/08
to web2py Web Framework
Yeah, Kyle - that's what I understood you to mean (and thanks for the
clarification regardless)
On Jul 26, 3:57 pm, "Kyle Smith" <kyletsm...@gmail.com> wrote:
> I should note that I also was not implying that gluon should natively
> support any other template engines, or should ship with them. I was simply
> trying to say that it makes a lot of sense to support an easy method for
> developers to choose a different template engine either via some type of
> template loader apparatus, decorators etc. I think that method would be far
> preferable to including any template engine other than the native one.
>
> Kyle
>
clarification regardless)
On Jul 26, 3:57 pm, "Kyle Smith" <kyletsm...@gmail.com> wrote:
> I should note that I also was not implying that gluon should natively
> support any other template engines, or should ship with them. I was simply
> trying to say that it makes a lot of sense to support an easy method for
> developers to choose a different template engine either via some type of
> template loader apparatus, decorators etc. I think that method would be far
> preferable to including any template engine other than the native one.
>
> Kyle
>
Timbo
Jul 26, 2008, 10:09:56 PM7/26/08
to web2py Web Framework
Kyle,
Actually, I think this is in the best interests going forward for
web2py. In retrospect, it would be even better than my original patch
by allowing for such flexibility while maintaining the simplicity of
web2py and sending a clear message that this is unofficial territory
(and therefore not invoking an overhead on the developers). It could
be done with a patch similar to the patch above by referencing a
'plugins' module. plugins.py could contain stubs for detecting,
compiling, and rendering based on a template. With that interface, it
would be easy to replace the stubs with workable code that would
invoke code to take care of all the template language specific stuff,
all this while not significantly changing the core code or locking the
devs into making a 'which template language is better' decision. I
would be happy to provide such a patch.
Thoughts?
Actually, I think this is in the best interests going forward for
web2py. In retrospect, it would be even better than my original patch
by allowing for such flexibility while maintaining the simplicity of
web2py and sending a clear message that this is unofficial territory
(and therefore not invoking an overhead on the developers). It could
be done with a patch similar to the patch above by referencing a
'plugins' module. plugins.py could contain stubs for detecting,
compiling, and rendering based on a template. With that interface, it
would be easy to replace the stubs with workable code that would
invoke code to take care of all the template language specific stuff,
all this while not significantly changing the core code or locking the
devs into making a 'which template language is better' decision. I
would be happy to provide such a patch.
Thoughts?
> I should note that I also was not implying that gluon should natively
> support any other template engines, or should ship with them. I was simply
> trying to say that it makes a lot of sense to support an easy method for
> developers to choose a different template engine either via some type of
> template loader apparatus, decorators etc. I think that method would be far
> preferable to including any template engine other than the native one.
>
> Kyle
>
> support any other template engines, or should ship with them. I was simply
> trying to say that it makes a lot of sense to support an easy method for
> developers to choose a different template engine either via some type of
> template loader apparatus, decorators etc. I think that method would be far
> preferable to including any template engine other than the native one.
>
> Kyle
>
Kyle Smith
Jul 26, 2008, 10:37:54 PM7/26/08
to web...@googlegroups.com
These are great ideas, and I think even Stuart and Massimo would probably agree that this is a workable solution long term. I know that Massimo would be even happier if you were willing to provide that as a patch as the more help there is working on the core the less dependent the entire project is on any one person, and the more the project as a whole will progress.
I think if you wanted to supply that as a patch, it would be a great thing, and would advance the topic in a positive direction.
Kyle
I think if you wanted to supply that as a patch, it would be a great thing, and would advance the topic in a positive direction.
Kyle
blackthorne
Jul 26, 2008, 11:49:01 PM7/26/08
to web2py Web Framework
On 26 Jul, 08:44, Massimo Di Pierro <mdipie...@cs.depaul.edu> wrote:
> I am with Voltron and Stuart on this.
>
> Why is Rails so successful when compared with Django or Pylons? It is
> not because of its extensibility but because of its simplicity.
> Simplicity means it is easy to learn, easy to maintain, people can
> build a culture and a community around it.
>
which wasn't that common in web frameworks. Having to learn a new
language and a different programming model to use a framework will
hardly be more simple than using something you already know. Contrarly
to your comment, extensibility was really important for the emergence
of Rails. Just think in the extended AJAX support and the ORM that
they used to do blogs in 15 minutes on their screencasts.
Fact is, when Rails emerged there was no Django (or Pylons) and many
people learned Ruby just because of Ruby on Rails and since django
community is growing much faster than Ruby (not to mention the higher
competition it is exposed to in Python frameworks). In the extreme,
web2py is more simple than Rails and it's not so successful (not even
than pylons). Why?
These same historical reasons.
Francisco
>
> - Mostrar texto citado -
blackthorne
Jul 26, 2008, 11:57:40 PM7/26/08
to web2py Web Framework
Just a note that you probably already know...
I haven't tested your patch for supporting genshi but I know that kid
also has the same syntax. Differences are minimum. So of them are not
supported by kid so you don't have a problem there (even without
touching the code).
Files are named as *.kid instead of *.html but the the rest is
identical. So your work opens a window for kid template system too in
web2py...
Francisco
I haven't tested your patch for supporting genshi but I know that kid
also has the same syntax. Differences are minimum. So of them are not
supported by kid so you don't have a problem there (even without
touching the code).
Files are named as *.kid instead of *.html but the the rest is
identical. So your work opens a window for kid template system too in
web2py...
Francisco
Massimo Di Pierro
Jul 27, 2008, 1:11:38 AM7/27/08
to web...@googlegroups.com
All I meant is that you can do
@render_genshi
def index(): return dict()
or
def index(): return render_genshi(template_filename,dict())
both are acceptable. The second solution is easier and more powerful
(because can be used to build components).
Massimo
Massimo Di Pierro
Jul 27, 2008, 1:16:42 AM7/27/08
to web...@googlegroups.com
The problem with Kid is that there are no maintainers any more. That
is why they developed Genshi.
is why they developed Genshi.
Massimo
mdipierro
Jul 27, 2008, 1:18:01 AM7/27/08
to web2py Web Framework
+1
On Jul 26, 9:37 pm, "Kyle Smith" <kyletsm...@gmail.com> wrote:
> These are great ideas, and I think even Stuart and Massimo would probably
> agree that this is a workable solution long term. I know that Massimo would
> be even happier if you were willing to provide that as a patch as the more
> help there is working on the core the less dependent the entire project is
> on any one person, and the more the project as a whole will progress.
>
> I think if you wanted to supply that as a patch, it would be a great thing,
> and would advance the topic in a positive direction.
>
> Kyle
>
On Jul 26, 9:37 pm, "Kyle Smith" <kyletsm...@gmail.com> wrote:
> These are great ideas, and I think even Stuart and Massimo would probably
> agree that this is a workable solution long term. I know that Massimo would
> be even happier if you were willing to provide that as a patch as the more
> help there is working on the core the less dependent the entire project is
> on any one person, and the more the project as a whole will progress.
>
> I think if you wanted to supply that as a patch, it would be a great thing,
> and would advance the topic in a positive direction.
>
> Kyle
>
Timbo
Jul 28, 2008, 10:18:37 AM7/28/08
to web2py Web Framework
I'll get it out probably tomorrow. I want to get it right.
Timbo
Jul 31, 2008, 3:45:42 PM7/31/08
to web2py Web Framework
To the list, Massimo and I have been discussing this off-list and
we've been through a few iterations.
I think I found a workable solution for the both of us...a "filters"
controller. Here's the code:
+++ C:/svnwork/web2py/trunk/gluon/compileapp.py Thu Jul 31 14:36:15
2008
@@ -171,10 +171,12 @@
web2py_error='invalid function')
code+='\n\nresponse._vars=%s()' % function
restricted(code,environment,layer=filename)
+ filename=os.path.join(folder,'controllers/filters.py')
+ if os.path.exists(filename):
+ code=open(filename,'r').read()
+ code+='\n\nresponse._vars=postprocess(response._vars)'
+ restricted(code,environment,layer=filename)
response=environment['response']
- if response.postprocessing:
- for p in response.postprocessing:
- response._vars=p(response._vars)
if type(response._vars)==types.StringType:
response.body=response._vars
elif type(response._vars)==types.GeneratorType:
Basically, it runs another "filter" (or call it what you want)
controller. This filter takes vars and returns a (possibly) modified
version thereof. An example filter controller looks like this:
def postprocess(vars):
vars.update(dict(message="There is no spoon"))
response.flash = 'Howdy!'
return vars
Naturally this patch lacks support for compiling said filter
controller and running the compiled version, but you can play with
it. I think this is what I'm going to go with for our production
environment. It is the simplest option we've considered (no
decorators, no monkeypatching) and doesn't require deep knowledge of
the inner workings of web2py to use.
What do you think?
- tim
> > > > > > >Genshitemplate engine) but I will be happy to post it with
> > > > > > > >>>> Perhaps there should be a mechanism to allowgenshi(and other
we've been through a few iterations.
I think I found a workable solution for the both of us...a "filters"
controller. Here's the code:
+++ C:/svnwork/web2py/trunk/gluon/compileapp.py Thu Jul 31 14:36:15
2008
@@ -171,10 +171,12 @@
web2py_error='invalid function')
code+='\n\nresponse._vars=%s()' % function
restricted(code,environment,layer=filename)
+ filename=os.path.join(folder,'controllers/filters.py')
+ if os.path.exists(filename):
+ code=open(filename,'r').read()
+ code+='\n\nresponse._vars=postprocess(response._vars)'
+ restricted(code,environment,layer=filename)
response=environment['response']
- if response.postprocessing:
- for p in response.postprocessing:
- response._vars=p(response._vars)
if type(response._vars)==types.StringType:
response.body=response._vars
elif type(response._vars)==types.GeneratorType:
Basically, it runs another "filter" (or call it what you want)
controller. This filter takes vars and returns a (possibly) modified
version thereof. An example filter controller looks like this:
def postprocess(vars):
vars.update(dict(message="There is no spoon"))
response.flash = 'Howdy!'
return vars
Naturally this patch lacks support for compiling said filter
controller and running the compiled version, but you can play with
it. I think this is what I'm going to go with for our production
environment. It is the simplest option we've considered (no
decorators, no monkeypatching) and doesn't require deep knowledge of
the inner workings of web2py to use.
What do you think?
- tim
> > > > > > > >>>> template) support via decorators defined in a
> > > > > > > >>>> gluon.contrib.templates.genshifile.
>
> > > > > > > >>>> Or should we considergenshispecial? Is there a reason to do it
> > > > > > > >>>> gluon.contrib.templates.genshifile.
>
Massimo Di Pierro
Jul 31, 2008, 6:33:44 PM7/31/08
to web...@googlegroups.com
Hi Timbo,
I am in the final week of completing the manual. I will get back to
you on this asap.
Massimo
Massimo Di Pierro
Jul 31, 2008, 6:56:03 PM7/31/08
to web...@googlegroups.com
Timbo this is too complex, adds conditional metaprogramming,
introduces a new convention (controllers/filters.py) and does not
work with web2py bytecode compilation.
introduces a new convention (controllers/filters.py) and does not
work with web2py bytecode compilation.
I suggest we stick with the current solution. You can already define
> def postprocess(vars,response):
> vars.update(dict(message="There is no spoon"))
> response.flash = 'Howdy!'
> return vars
and pass it to postprocessing in any controller:
response.postprocessing.append(lambda vars: postprocess
(vars,request))
It is better to explicit about what to pass because the probably
postprocessing functions belong to modules more than they belong to
controllers.
As a web2py principle I am against introducing a new convention when
something can already be done.
Massimo
On Jul 31, 2008, at 2:45 PM, Timbo wrote:
Timbo
Jul 31, 2008, 11:57:11 PM7/31/08
to web2py Web Framework
Dude, I'm so sorry for wasting your time. I see now that what you put
in place is just what I need. Thanks. I'll post a howto for genshi
tomorrow.
> ...
>
> read more »
in place is just what I need. Thanks. I'll post a howto for genshi
tomorrow.
>
> read more »
blackthorne
Aug 1, 2008, 1:23:48 AM8/1/08
to web2py Web Framework
hi
Now we will (hopefully) have a patch for genshi templates. There are
others and there will be more. How do you see the idea of looking to
this patches as addons (or modules) and create a small addon manager
for them integrated with the admin app? It could even list/update
directly from the web as well as install/uninstall modules easily.
(This also envolves a work on older patches to fit on this system (it
could even be based on a python implementation of "patch")).
You will probably say "No, but you can do that as a web2py app and I
will happily display it on the website..."
And I say: That kills my idea because "nobody" would use it. So I ask
you to reconsider... Think of the amount of doors that a lightweight
feature like this opens...
It could even help you to get orientation about what is relevant and
what's not. Imagine a rating system associated with all these addons.
The highest rated addons could become be included by default in future
versions of web2py. This is a great kick in flexibility and hasn't any
license problem (we could make addons for the SQL Designer, SQL
Alchemy that can be easily installed by anyone).
You might say: "But that's why Appliances exist..."
Applications may add tools to the web2py instance but they don't
change it. They are used as an end, not so much as mean to an end.
I personally think it's a killer feature.
Now we will (hopefully) have a patch for genshi templates. There are
others and there will be more. How do you see the idea of looking to
this patches as addons (or modules) and create a small addon manager
for them integrated with the admin app? It could even list/update
directly from the web as well as install/uninstall modules easily.
(This also envolves a work on older patches to fit on this system (it
could even be based on a python implementation of "patch")).
You will probably say "No, but you can do that as a web2py app and I
will happily display it on the website..."
And I say: That kills my idea because "nobody" would use it. So I ask
you to reconsider... Think of the amount of doors that a lightweight
feature like this opens...
It could even help you to get orientation about what is relevant and
what's not. Imagine a rating system associated with all these addons.
The highest rated addons could become be included by default in future
versions of web2py. This is a great kick in flexibility and hasn't any
license problem (we could make addons for the SQL Designer, SQL
Alchemy that can be easily installed by anyone).
You might say: "But that's why Appliances exist..."
Applications may add tools to the web2py instance but they don't
change it. They are used as an end, not so much as mean to an end.
I personally think it's a killer feature.
Massimo Di Pierro
Aug 1, 2008, 2:49:10 AM8/1/08
to web...@googlegroups.com
Please. Nothing to apologize. Your push for this got it done. Keep it
up.
It is my work to resist to too big changes otherwise it get un-
manageble.
Would you resend to the list the code to process genshi templates?
I am sure other users will find it useful.
If you create a new AlterEgo page, I will approve it.
Thank you for your help.
up.
It is my work to resist to too big changes otherwise it get un-
manageble.
Would you resend to the list the code to process genshi templates?
I am sure other users will find it useful.
If you create a new AlterEgo page, I will approve it.
Thank you for your help.
Massimo Di Pierro
Aug 1, 2008, 3:08:39 AM8/1/08
to web...@googlegroups.com
As you suggested I is answer "no" to the idea of altering admin to
add plugins but this is not a "no" to your general idea.
add plugins but this is not a "no" to your general idea.
There are some plugins I do not want to encourage (those that make
your code work in alternative ways) while there are some I want to
encourage (those that follow strict unwritten specifications,
"enterprise python beans" specifications, or "contrib" as Stuart
called them).
There should be an appliance to manage EPB but first we have to write
specifications. This is an open issue.
I envision a system where a plugin is a tar file (like an app) and
everybody can post them (no centralize repository) and a wizard app
that allows to install a plugin using the url. For example you
published http://www.blacktorne.com/autentication.epb and I want to
give authentication to my app, I just type your url and it will ask
me questions to hook into my app (what's the database? which table
names? etc.)
I am in the middle of finishing the book so we need to postpone this
discussion in a week.
Massimo
Stuart Rackham
Aug 1, 2008, 5:41:11 AM8/1/08
to web...@googlegroups.com
Here's my take:
http://groups.google.com/group/web2py/browse_thread/thread/958efba0564ff89f/e406293a5ad932c7
http://groups.google.com/group/web2py/browse_thread/thread/958efba0564ff89f/e406293a5ad932c7
Don't know that's the sort of thing you are thinking of or not though.
Cheers, Stuart
Massimo Di Pierro
Aug 1, 2008, 12:48:43 PM8/1/08
to web...@googlegroups.com
yarko
Aug 1, 2008, 9:54:08 PM8/1/08
to web2py Web Framework
it would be good to sync up the comment instructinos in the referenced
AlterEgo download, and the AlterEgo posting instructions, i.e.
namespace.
AlterEgo download, and the AlterEgo posting instructions, i.e.
namespace.
mdipierro
Aug 2, 2008, 8:46:26 AM8/2/08
to web2py Web Framework
Sorry I do not understand. Could you explain it again?
mdipierro
Aug 2, 2008, 8:48:52 AM8/2/08
to web2py Web Framework
I am thinking about this issue some more. why reinvent the wheel.
Why not add to admin a web based interface to easy_install?
Admin could have a page to list packages, delete them and install
them.
Every app could contain a file with a list of required packages.
This should work with the binary distributions as well.
Could you provide me an example app?
Massimo
> ...
>
> read more »
Why not add to admin a web based interface to easy_install?
Admin could have a page to list packages, delete them and install
them.
Every app could contain a file with a list of required packages.
This should work with the binary distributions as well.
Could you provide me an example app?
Massimo
>
> read more »
Stuart Rackham
Aug 2, 2008, 5:13:51 PM8/2/08
to web...@googlegroups.com
mdipierro wrote:
> I am thinking about this issue some more. why reinvent the wheel.
> Why not add to admin a web based interface to easy_install?
> Admin could have a page to list packages, delete them and install
> them.
> Every app could contain a file with a list of required packages.
> This should work with the binary distributions as well.
+1
> I am thinking about this issue some more. why reinvent the wheel.
> Why not add to admin a web based interface to easy_install?
> Admin could have a page to list packages, delete them and install
> them.
> Every app could contain a file with a list of required packages.
> This should work with the binary distributions as well.
Nice idea.
Cheers, Stuart
yarko
Aug 2, 2008, 5:18:23 PM8/2/08
to web2py Web Framework
> Sorry I do not understand. Could you explain it again?
I meant only this:
Make instruction in AlterEgo and insode file Gensh4web2py.py the
same.
Right now, in http://mdp.cti.depaul.edu/AlterEgo/default/show/162 :
-----------------------------------------------
3) in your controller add:
import Genshi4web2py
response.postprocessing.append(lambda x: Genshi4web2py.render(x,
request, response))
--------------
in Genshi4web2py.py (the download):
------------------------------------------------
To enable Genshi templating, put the following code in your
controller:
from Genshi4web2py import render
response.postprocessing.append(lambda x: render(x, request,
response))
-----------------
Timbo
Aug 2, 2008, 10:30:07 PM8/2/08
to web2py Web Framework
Massimo, the one you have out there in AlterEgo has a big bug in it.
I sent you the final version (bug-free =) Do you need me to resend
it? The bug is in the use of MarkupTemplate. The corrected version
uses template loader.
On Aug 2, 4:18 pm, yarko <yark...@gmail.com> wrote:
> > Sorry I do not understand. Could you explain it again?
>
> I meant only this:
>
> Make instruction in AlterEgo and insode file Gensh4web2py.py the
> same.
>
> Right now, inhttp://mdp.cti.depaul.edu/AlterEgo/default/show/162:
I sent you the final version (bug-free =) Do you need me to resend
it? The bug is in the use of MarkupTemplate. The corrected version
uses template loader.
On Aug 2, 4:18 pm, yarko <yark...@gmail.com> wrote:
> > Sorry I do not understand. Could you explain it again?
>
> I meant only this:
>
> Make instruction in AlterEgo and insode file Gensh4web2py.py the
> same.
>
Massimo Di Pierro
Aug 3, 2008, 3:58:33 AM8/3/08
to web...@googlegroups.com
Good point.
Massimo Di Pierro
Aug 3, 2008, 4:04:57 AM8/3/08
to web...@googlegroups.com
Please resend it.
Timbo
Aug 4, 2008, 8:41:16 AM8/4/08
to web2py Web Framework
Check your mailbox.
Massimo Di Pierro
Aug 4, 2008, 12:51:58 PM8/4/08
to web...@googlegroups.com
Thanks. Swamped today. Will take care of it tomorrow.
Reply all
Reply to author
Forward
0 new messages