z3c.pt in Grok

[Peter Bengtsson]

First of all, rendering speed is a lower priority for me than learning
Grok but when I saw this I got really excited:
"Casual benchmarks pegs it 11x more performant than zope.pagetemplate."

It doesn't support METAL but Viewlets will surely solve that anyway.
I also saw Lennarts how-to how to replace the templating language in
Grok so perhaps with that I could get going with z3c.pt myself.
However, have other people tried this? What were your results and
impressions? Does it work well with viewlets?

Peter

--
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Hey,

Peter Bengtsson wrote:
> First of all, rendering speed is a lower priority for me than
> learning Grok but when I saw this I got really excited: "Casual
> benchmarks pegs it 11x more performant than zope.pagetemplate."

Don't get *too* excited by casual benchmarks, and treat all benchmarks
as casual ones. :)

But yes, template rendering can be done more quickly than
zope.pagetemplate definitely. It depends on your application whether
this should actually speed up performance of the whole thing a lot, but
it sounds like a good idea to try.

> It doesn't support METAL but Viewlets will surely solve that anyway.
> I also saw Lennarts how-to how to replace the templating language in
> Grok so perhaps with that I could get going with z3c.pt myself.
> However, have other people tried this? What were your results and
> impressions? Does it work well with viewlets?

I haven't tried this myself. I'd love to hear feedback from people who
have. Lennart's how-to on how to introduce a new template language is
definitely the way to go. Just introduce a new file extension for z3c.pt
and experiment away.

I'd love people to try out our template pluggability a bit more. I'm
sure it's imperfect, as nobody is using it for real purposes yet as far
as I'm aware, and the only way to get it ready is to try to make it
support z3c.pt, and Jinja, and do a real world project with Genshi, etc.

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Michael Haubenwallner-2]

Martijn Faassen schrieb:
> I'd love people to try out our template pluggability a bit more. I'm
> sure it's imperfect, as nobody is using it for real purposes yet as far
> as I'm aware, and the only way to get it ready is to try to make it
> support z3c.pt, and Jinja, and do a real world project with Genshi, etc.

Template pluggability works fine for me - i'm using
http://pypi.python.org/pypi/d2m.rendersource which renders restructured
text formatted templates to standalone HTML pages.

Michael

--
http://blog.d2m.at
http://planetzope.org
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Michael Haubenwallner wrote:

> Martijn Faassen schrieb:
>> I'd love people to try out our template pluggability a bit more. I'm
>> sure it's imperfect, as nobody is using it for real purposes yet as
>> far as I'm aware, and the only way to get it ready is to try to make
>> it support z3c.pt, and Jinja, and do a real world project with Genshi,
>> etc.
>
> Template pluggability works fine for me - i'm using
> http://pypi.python.org/pypi/d2m.rendersource which renders restructured
> text formatted templates to standalone HTML pages.

That's a good data point, thanks!

I'm especially curious about cases where a template uses another using
some kind of inclusion scenario. ZPT expects inclusion (for instance of
macros) to happen by view lookup. I think many other template languages
include bits from another template on the filesystem. This might bump
into Grok complaining when it finds a template without an associate view.

I'm not sure your .rst templates can refer to external templates. If so,
it'd be interesting to find out whether that works.

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Michael Haubenwallner-2]

Martijn Faassen schrieb:
> I'm especially curious about cases where a template uses another using
> some kind of inclusion scenario. ZPT expects inclusion (for instance of
> macros) to happen by view lookup. I think many other template languages
> include bits from another template on the filesystem. This might bump
> into Grok complaining when it finds a template without an associate view.
>
> I'm not sure your .rst templates can refer to external templates. If so,
> it'd be interesting to find out whether that works.
>

Not sure i understand correct, but the 'include' and 'raw' directives
both work - includepaths must be absolute or relative to the folder the
grok application ist started from.
I also found that you need to declare the 'encoding' options for
external files (except you've got unicode formatted files).

Hth,
Michael

--
http://blog.d2m.at
http://planetzope.org
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Michael Haubenwallner wrote:

> Martijn Faassen schrieb:
>> I'm especially curious about cases where a template uses another using
>> some kind of inclusion scenario. ZPT expects inclusion (for instance
>> of macros) to happen by view lookup. I think many other template
>> languages include bits from another template on the filesystem. This
>> might bump into Grok complaining when it finds a template without an
>> associate view.
>>
>> I'm not sure your .rst templates can refer to external templates. If
>> so, it'd be interesting to find out whether that works.
>>
>
> Not sure i understand correct, but the 'include' and 'raw' directives
> both work - includepaths must be absolute or relative to the folder the
> grok application ist started from.

This behavior I don't think is what you'd expect using restructured
text, though, right? You'd expect it to try to include from the same
directory the restructured text file is in. This is probably not a big
problem for typical restructured text usage, but, I think, a big problem
problem for something that really wants to include a file for reuse very
commonly.

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Michael Haubenwallner-2]

Martijn Faassen schrieb:

> Michael Haubenwallner wrote:
>> Not sure i understand correct, but the 'include' and 'raw' directives
>> both work - includepaths must be absolute or relative to the folder
>> the grok application ist started from.
>
> This behavior I don't think is what you'd expect using restructured
> text, though, right? You'd expect it to try to include from the same
> directory the restructured text file is in. This is probably not a big
> problem for typical restructured text usage, but, I think, a big problem
> problem for something that really wants to include a file for reuse very
> commonly.
>

Thanks for the feedback.

The issue is fixed in 0.4 now, 'include/raw/csv-table' directives now
work with paths relative to the base-template. Also added functional
tests - http://pypi.python.org/pypi/d2m.rendersource

Regards
Michael

--
http://blog.d2m.at
http://planetzope.org
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev