Maybe the following ideas sounds crazy or stupid.
Sorry if they really are; at least, I would have learnt more about
these controversial APIs ;-)
Quick question related to the context thing: what about the formatter,
especially in macros?
The method signature for a macro is (still):
def expand_macro(self, formatter, name, content)
I'm not sure to understand why we need a "formatter" to retrieve the resource.
With the current -trunk- implementation, a macro needs to retrieve the
resource this way: formatter.context.realm and formatter.context.id if
I'm not mistaken.
It seems fair that the formatter and the context are tied (although I
would have first expected the context to provide the formatter rather
than the opposite but I know really little about these APIs), but I
don't think the formatter should provide the resource, they should not
be directly related IMHO.
The method signature could be something like:
def expand_macro(self, formatter, resource, name, args)
couldn't it?
("content" does not sound as a good symbol for the macro args BTW)
> http://trac.edgewall.org/anydiff?new_path=%2Fsandbox%2Fcontext-refactoring&old_path=%2Fsandbox%2Fcontext-refactoring&new_rev=6117&old_rev=6117
Are you sure about the revision numbers in the above URL? For example,
the Context class in trac/mimeview/api.py does not appear, as it has
been committed in 6116.
[OT]: why a difference between two identical paths and revision gives
something but null ? Maybe it's due to the SVN duality between
revisions and changes, but it's really confusing. I would have
expected: old_rev=6116, new_rev=6117
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
