Am 23.01.2007 um 08:45 schrieb Christian Boos: > Alec Thomas wrote: >> ... I know myself how tedious it is upgrading >> plugins to a new API version. It's not "fun" coding, it's just >> boring. >> The less of this we subject plugin authors to, the more likely it is >> that they will keep working on them. > > Well, let me first explain the "let's break the API" point of view, in > this specific case. > A lot of macros are playing tricks to get the informations that are > now > provided by the formatter (and the formatter.context), so I think it > usually makes sense to _really_ upgrade them. > Also, more and more parts of the Trac API are now directly taking a > context argument, and this can be obtained from the formatter, but not > from the req (well, you could always build a global Context(self.env, > req), but you loose the "real" resource context to which the wiki text > belongs).
These are good points; I'd be interested in seeing how many new-style macros that would continue to work if we didn't change the interface, but would actually still be broken because they e.g. depend on the HDF. > That being said, I'm not against adding back support for the > render_macro(req, ...), as there seems to be consensus on that. > > The idea is to anticipate the WikiDOM changes (see #4431) and > provide a > new API for the macros, in addition to the old render_macro(req, ...) > method, kept for compatibility. > > The new API would be: > > def parse_macro(parser, name, content): > """Called after the wiki text containing the call has been > parsed.""" > > def format_macro(formatter, name, content): > """Called by the formatter when rendering the parsed wiki > text.""" In general, I'd prefer to avoid defining APIs that anticipate a redesign (-- okay, the IXxxManipulator interfaces do this, but still, it should really be a rare exception.) In this case, we don't have more than a vague idea how the redesign should look. Sure, there'd be parsing and formatting stages, and inbetween we'd have some kind of tree-based representation of the parsed wiki text. Not really enough to design an API on top of, IMO. The risk that we'll find we'll want a different kind of API when actually doing the redesign is too high. I think we should just use "render_macro2" in this case. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
