Emmanuel Blot wrote:
> 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 formatter is tied to a rendering context and not the other way
around because not every mimeview rendering involves formatting wiki
text. Retrieving the resource information from the formatter can be done
either indirectly through the context (formatter.context.resource) or
directly, formatter.resource (it's the same thing). The formatter knows
about the resource to which the text being formatted belongs to, so that
relative links in that wiki content will use that resource as their
reference, so I actually think their directly related.
> The method signature could be something like:
> def expand_macro(self, formatter, resource, name, args)
> couldn't it?
>
That's a possibility, and if this clarifies things I'm OK to add that
(though that will probably break the macro API once again...).
> ("content" does not sound as a good symbol for the macro args BTW)
>
Well, macros could also be called using the block syntax, so in that
case at least it makes sense to talk about content. "content" is also a
more general term than arguments, and not every macro interpret their
content as "arguments" in the sense of comma-separated arguments.
>
>> 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.
>
At the last minute, I didn't want to put a link to the diff itself but
rather to the form leading to the diff (to spare a few costly hits on
t.e.o). I forgot to edit the link, it should have been:
http://trac.edgewall.org/anydiff?new_path=%2Fsandbox%2Fcontext-refactoring&old_path=%2Ftrunk&new_rev=6117&old_rev=6113
(r6113 was the last merge revision from trunk to the context-refactoring
branch)
> [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
When you specify old_rev==new_rev, it's like looking at that changeset.
-- 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
-~----------~----~----~----~------~----~------~--~---
