Ian Bicking wrote:
I would say that
the argument or arguments passed to find_template() need to be pretty
open ended, since you cant predict what kinds of things might be
meaningful to a template finder, such as in myghty's case, the resolver
wants to know if you are asking for this
Phillip J. Eby wrote:
What I'd suggest is that this is actually an opportunity for Myghty to put
its lookup and caching on one side of the interface, and an actual
template
rendering facility on the other side. That is, treat Myghty as an
embedd*er* rather than the embedd*ee*, so that the
is it possibly of value to just put some of these ideas into practice
first without shooting any of them down ? I find it very hard to
come up with broad-ranging specs, and then declare it as thats the
way it will be, without having a decent community of folks trying
out the ideas and
On Feb 1, 2006, at 12:59 PM, Phillip J. Eby wrote:
At 1
So asking for foo can resolve to foo.gif or foo.jpeg in the
file system? If you have to say in the code which it is, that's
not what I mean.
you can write a resolver that searches the filesystem for foo.* and
does some type
Clark C. Evans wrote:
I'd stick with the notion of a template_name that is neither the
template file nor the template body. Then you'd want a template factory
method that takes the name and produces the template body (complied if
necessary). This needs to be once indirect since a template
hey all -
I have released Myghty 0.99a, which includes a variety of bugfixes, as
well as a new demo application which illustrates some new controller ideas
plus integration with an improved MyghtyJax toolkit and the upcoming
SQLAlchemy database library.
Myghty is a full Python port of
On Aug 17, 2005, at 6:49 PM, Phillip J. Eby wrote:That really hasn't been my experience. Partly, this is because I tend to use RESTful approaches that put 99% of all statefulness in the browser. For example, if I have a multi-page form, I embed all the previous pages' data as hidden fields on
my own project, Myghty, is modeled after Perl's HTML::Mason, which in
turn is a lot like PHP with regards to just plug it in and start
writing pages. it does foster a more compentized design than PHP and
also integrates nicely into whatever MVC framework the developer
chooses. Myghty
if you run multiple virtual hosts out of Apache, mod_python by default
creates new subinterpreters, via Py_NewInterpreter, for each virtual
host. this can also be set up per apache directive, an arbitrary name,
or within individual directories.
although how well Py_NewInterpreter separates
