Added NonPackagedKidTemplates
robin...@gmail.com
I've just added an example to the documentation playground:
http://trac.turbogears.org/turbogears/wiki/NonPackagedKidTemplates
Is there a simpler / better way of achieving this than the example I've
presented ? Any other thoughts on the merrit of the example ?
Cheers,
Robin
Kevin Dangoor
Though it's unlikely the implementation would look like this, this is
most definitely something that needs to appear in some form in First
Class. Being able to pick up templates off of a path is pretty
critical when it comes to customizing apps that you install.
Kevin
Jorge Godoy
> Though it's unlikely the implementation would look like this, this is
> most definitely something that needs to appear in some form in First
> Class. Being able to pick up templates off of a path is pretty
> critical when it comes to customizing apps that you install.
It is also interesting for code reuse. I have a piece of code that I'm using
in 6 applications now. This depends on model -- it is a common part of the
model --, view (there are templates and custom templates for widgets there)
and, of course, the controller to do the operation.
Being able to pass each application's model *and* master.kid to this "common
code" would allow me factoring it out and even reducing this to something more
useful for other applications as well.
This is a feature that would be very appreciated. (It can be done today with
some hacks, but hacks aren't a good thing to have in code...)
--
Jorge Godoy <jgo...@gmail.com>
Robin Bryce
implementation to look ? I've got time to work on this atm.
What is 'First Class' ? [googles] oic.
When I started on this my main concernes were:
1. to avoid patching TG
2. play nicely with existing template machinery
I think the example I posted fails on 2., as it breaks auto reloading.
Once the import hook has fired once it takes a restart to clear out
sys.modules. And I bet there are cleaner ways to handle the startup
script. But it looks like First Class is going to shift the ground
somewhat :)
Cheers,
Robin
Kevin Dangoor
>
> Thanks for the feedback. Got any thoughts on how you would like an
> implementation to look ? I've got time to work on this atm.
I was just emailed with Elvelind about this a couple of days ago,
because he was thinking of something else along these lines. I'd love
to see some work done on this (on the trunk).
One part is template paths (and this is the part that may change how
expose finds templates). Under ideal circumstances, if the user wants
to completely replace a template they should be able to do so, and
template paths would allow this. First Class is the codename for the
first major release after 1.0. It will allow applications to be
configured in PasteDeploy style. (There's an experiment checked in in
the firstclass branch that adds a tg-admin serve command that allows
easy composition of apps through PasteDeploy).
The second part of this is being able to flexibly swap out the master
*or* to add additional match rules. The new Markup template language
provides a Kid-like syntax but provides this kind of flexibility in
match rule inheritance. I do hope that Markup and Kid can become one,
since they are syntactically quite close, but that's really for
others to decide. It would likely be possible to make a Kid->Markup
converter, given that Kid templates are standard XHTML. There are
some constructs that would be harder to convert automatically though.
To start with, though, Markup does make it easy to substitute in a
new "master" or to add match rules. So, that increases layout
flexibility tremendously for apps that you are reusing. This
capability just needs to be exposed via Python and config file. (Note
that the current trunk does not include the PasteDeploy goodness...
this will need to be ported from firstclass, which is a bit old right
now.)
Kevin
Robin Bryce
> I do hope that Markup and Kid can become one, since they are syntactically > quite close
I took a quick look at Markup and liked it too. I particularly like
its "make it fit in the xml tool chain" meme (I'm not a particular fan
of xml but, hehho when in rome).
ISTR something in the kid docs along the lines that support for
comment processing prevented Kid from making full use of cElementTree
accelerations. (In fact my copy of kid has a patch applied to get
comments working at all but thats another story).
I did very much like that Markup uses AST generation rather than
generating .pyc's.
I didn't realy understand why not having a dependency on ElementTree
was a good thing. I mean, how hard can it be to patch cElementTree to
give line numbers and handle comment processing in c ?
I'll have a dig arround the firstclass stuff & trunk this weekend,
with a view to seeing how deep the water is ;-)
Cheers,
Robin
On 09/08/06, Kevin Dangoor <dan...@gmail.com> wrote:
>
Christopher Lenz
> I didn't realy understand why not having a dependency on ElementTree
> was a good thing.
It's not advertised as a good thing, just as a difference.
> I mean, how hard can it be to patch cElementTree to
> give line numbers and handle comment processing in c ?
There's simply not much benefit of using ElementTree in Markup. ET is,
after all, a DOM-style API, whereas Markup uses SAX-style streaming
internally.
Furthermore, in my (not very extensive) tests using cElementTree with
Kid doesn't make a huge difference compared to using the Python
ElementTree implementation. Kid spends most of the time in its own code
;-)
Cheers,
Chris
--
http://www.cmlenz.net/
Kevin Dangoor
> I didn't realy understand why not having a dependency on ElementTree
> was a good thing. I mean, how hard can it be to patch cElementTree to
> give line numbers and handle comment processing in c ?
Apparently, it's hard enough, since no one has done it.
> I'll have a dig arround the firstclass stuff & trunk this weekend,
> with a view to seeing how deep the water is ;-)
Cool. I'd recommend moving any such discussions over to the
turbogears-trunk mailing list.
Kevin
Robin Bryce
>
> On Aug 10, 2006, at 8:10 AM, Robin Bryce wrote:
>
> > I didn't realy understand why not having a dependency on ElementTree
> > was a good thing. I mean, how hard can it be to patch cElementTree to
> > give line numbers and handle comment processing in c ?
>
> Apparently, it's hard enough, since no one has done it.
Well line numbers wasn't to hard: sf #1538691. Wonder what subtelty
I'm missing ;-)
On 10/08/06, Christopher Lenz <cml...@gmail.com> wrote:
> There's simply not much benefit of using ElementTree in Markup. ET is,
> after all, a DOM-style API, whereas Markup uses SAX-style streaming
> internally.
>
> Furthermore, in my (not very extensive) tests using cElementTree with
> Kid doesn't make a huge difference compared to using the Python
> ElementTree implementation. Kid spends most of the time in its own code
> ;-)
Fair enough :-). And I definitely respect what your doing with Markup
Cheers,
Robin