Hi all,
I've been playing with WebKit over the past few days with thoughts of making
it the core engine of a specialized application server I am building. While
doing so I found a To-Do item somewhere about the need to fix it so that
multiple instances could be run on the same box using the same
On Saturday 09 June 2001 12:21, Ian Bicking wrote:
> Tavis Rudd <[EMAIL PROTECTED]> wrote:
> > I think we should aim for a 1.0 release with full docs
> > and a stable syntax for the end of July. Until then
> > how about we just keep on incrementing the 0.9.#
> > numbers until we think we're ready
Ian Bicking wrote:
> One alternative would be to make TS more future-compatible, but
> versioning the input. I remember browsing some discussion on the
> Python lists. One person noted a system that had a version at the top
> the file, and would sometimes edit the code in-place or put in
> back
Tavis Rudd <[EMAIL PROTECTED]> wrote:
> I think we should aim for a 1.0 release with full docs and
> a stable syntax for the end of July. Until then how about
> we just keep on incrementing the 0.9.# numbers until we
> think we're ready, then have a 2 week freeze period?
The implementation ca
Tavis:
This is a pretty crude way to rename things, but it catches most of the
vestiges that will linger for a long time if you try to do it manually:
$ cd Cheetah-0.9.4
$ find -type f |xargs perl -i.bak -pe
's/TemplateServer/Cheetah/g;s/TScompile/cheetah-compile/g;'
$ vim Cheetah/__init__.py
ed
updated docs,
new #slurp directive
other minor stuff in the changelog
I think we should aim for a 1.0 release with full docs and
a stable syntax for the end of July. Until then how about
we just keep on incrementing the 0.9.# numbers until we
think we're ready, then have a 2 week freeze perio
At 10:24 AM 6/9/2001 -0700, Tavis Rudd wrote:
>I'm just about to upload the HTML docs as the homepage for
>now.
>
>BTW, shouldn't this be on the devel list?
>What was your opinion about how to manage the crossover
>between Cheetah and the webware 'templates' meta-thread?
Well the biggest thing is
Similar to $vars, I think #include should take effect during rendering, not
during construction. Otherwise, we're back to the same situation. For
example, a Template must be discarded every time if there is any chance the
#include files could change.
Or does Cheetah check the timestamp of #inc
On Saturday 09 June 2001 08:59, Chuck Esterbrook wrote:
> At 09:03 AM 6/9/2001 -0700, Tavis Rudd wrote:
> >Chuck,
> >I see where you're coming from on this. I was just
> > getting sick of putting * in for all the vars that I
> > wanted to cache, which was almost every single one.
> >Here's a prop
At 09:03 AM 6/9/2001 -0700, Tavis Rudd wrote:
>Chuck,
>I see where you're coming from on this. I was just getting
>sick of putting * in for all the vars that I wanted to
>cache, which was almost every single one.
>Here's a proposal that should remove my frustration, while
>using dynamic vars as t
Chuck,
I see where you're coming from on this. I was just getting
sick of putting * in for all the vars that I wanted to
cache, which was almost every single one.
Here's a proposal that should remove my frustration, while
using dynamic vars as the $placeholder default:
===
"The value of each reference will be calculated once at start-up and a
cached version will be used thereafter." -- that's just sooo no-intuitive.
And why would I even keep the template object around then? The string would
do just fine.
Consider:
>>> from Cheetah.Template import Template as T
At 08:37 AM 6/9/2001 -0400, Jay Love wrote:
>No, it should be "path" for psp:include. I just haven't updated the
>documentation. @include includes the source of a file, psp:include
>actually does a application.includeURL call.
Perhaps it should be "url"?
-Chuck
___
At 09:22 AM 6/9/2001 -0400, Jay Love wrote:
>On 08 Jun 2001 10:21:38 -0700, Tavis Rudd wrote:
> >
> > I should have written something about this. ServletFactory
> > and PlateKit were essentially duplicating what TScompile
> > does for .tmpl files, but TScompile does it better. If you are
> > bui
On 08 Jun 2001 10:21:38 -0700, Tavis Rudd wrote:
>
> I should have written something about this. ServletFactory
> and PlateKit were essentially duplicating what TScompile
> does for .tmpl files, but TScompile does it better. If you are
> build a site using .tmpl files you should compile all
On 08 Jun 2001 20:16:32 +0200, Tom Schwaller wrote:
>
> B.T.W. take a look at www.python.de, there is some
> surprise about Webware, but it's not finished yet.
> I need a stable AsyncThreadedHTTPServer,
> because I have no Apache on the uCSimm.
> Unfortunately it does not seem to run stable.
> I
Well, that seeming inconsistency came straight from JSP. It actually
does have a purpose, though.
@ commands are done at compile time.
psp: commands do something at runtime.
Jay
Chuck Esterbrook wrote:
> At 01:52 PM 6/8/2001 -0400, Geoff Talvola wrote:
>
>> I just noticed that the documen
No, it should be "path" for psp:include. I just haven't updated the
documentation. @include includes the source of a file, psp:include
actually does a application.includeURL call.
Jay
Geoff Talvola wrote:
> I just noticed that the documentation for PSP specifies the following
> syntax:
>
18 matches
Mail list logo
