On 4/13/2010 4:52 PM, osimons wrote:
On Apr 13, 2:27 pm, Thomas Moschny<[email protected]> wrote:
2010/4/8 Noah Kantrowitz<[email protected]>:
The same goes for streamfilter plugins. What plugins out there are making
good use of this?
We also have at least one internal plugin making use of streamfilters.
In general, it's a nice thing to have, as plugins can tweak the ui
with zero help from the main Trac devs. It's like having hooks
everywhere, even in places no one thought about previously. In a
hook-based model, when there's no hook where you need one, you first
have to convince others that it might be useful, and then wait for the
next Trac release. Admittedly in some cases talking to others can also
have the effect of you being convinced that the hook is indeed not
needed ;)
Agreed. And, it is not just plugins - "site.html match, add& rewrite"
is also quite common for a variety of known and unknown use-cases.
I'm not fuzzed either way about how the technology works (ie. what
templating engine), and even rewriting my things (again) is acceptable
if a switch is deemed neecessary.
Well, the longer Genshi 0.6 takes to materialize, the more obvious it
will be for everyone that we *need* that change, if only from the
software maintenance point of view.
Christopher specifically asked for help for *one* ticket (#370), but
nobody seems to care so far and this tells a lot. If someone really
wants to *voice* an opposition to a migration to an other templating
system, that would be his chance. So while I still like to believe that
0.6 itself will be released at last, I'm a bit worried about the
follow-up 0.6.x releases we might need, and I don't have any illusion
about 0.7 as I witness the Genshi development grind to a halt.
But despite the above, current Genshi trunk / 0.6 sort of works for our
needs, for the few issues we have, there are workarounds. So it's kind
of OK for 0.12 and 0.12.x, and it will also be OK for 0.13, we just have
to be careful to work within the bounds imposed by the current state of
Genshi.
But precisely, those bounds are also bounds on the performance and
that's the second motivation that justifies a migration.
Now, I'm still talking about a migration and not a switch, as I think
it's perfectly possible that we introduce Jinja2 support gradually. We
could use Jinja2 templates to generate some performance critical parts
of the output, then wrap the result in a Markup object and pass that
along to Genshi, which in the first stage would still be responsible for
generating the main layout, theme, etc. as usual. Wiki pages even big
ones are currently rendered quickly precisely because they contain a lot
of content which is opaque to Genshi. The trade-off will be that most of
the complex transformations done on the overall layout, like typically
those involving site.html and documented in
http://trac.edgewall.org/wiki/TracInterfaceCustomization and
http://trac.edgewall.org/wiki/CookBook/SiteHtml will *still* work, but
those trying for example to modify each row of a rendered source file
will no longer work (and I imagine there are not a lot of such templates
anyway, precisely for performance reasons).
In a second step, we could introduce an alternative way to compose the
layout and themes using Jinja2 all the way through, and only then phase
out Genshi.
However, depending on Trac
development for available hooks would be a big step backward,
Not sure; as I've pointed out earlier and others have noticed as well,
not having explicit hooks is also quite fragile. Suddenly, after a
seemingly innocent change in the template, the xpath selectors of some
plugin stop working...
If you read the previous mail from Christopher where he gave some
possible ideas for an improved "Genshi2" (in his reply to Eirik
Schwenke), he was also considering getting away with the xpath matches
("alternatively, drop the match template idea altogether and move to the
more conventional model of template inheritance where the master
predefines slots that can be filled.").
and a
big negative for me as I won't really be able to redo what I currently
have in production.
Well, I don't really know what kind of changes you have in place, but if
they are mostly about the general layout, the hybrid approach I
suggested above should give you enough room for a smooth transition.
-- Christian
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
