Christopher Lenz wrote:
> On 12.12.2007, at 09:57, Christian Boos wrote:
>
>> Noah Kantrowitz wrote:
>>
>>> This has been previously discussed on the list, though I stopped
>>> reading
>>> for a week or two due to final exams. Basically we need to add
>>> infrastructure to the navigation system to manage the ctxtnav bar
>>> in a
>>> thematically similar fashion to the other nav bars. The reason this
>>> needs to be done before a beta is this will break every template
>>> currently in existence. The proposed API is something of the form
>>> add_ctxtnav(req, tag.a('Foo', href=req.href.myplugin('foo'))),
>>> working
>>> internally in a similar fashion to add_stylesheet and add_script.
>>> This
>>> will also mean moving the ctxtnav div out of the individual templates
>>> and into layout.html (hence the mass breakage).
>>>
>>>
>> I agree that there are improvements to be made here, but I don't think
>> it's something we can realistically do for 0.11 at this point, as this
>> would involve a lot of work (seeing the relative complexity of all the
>> existing ctxnav <div>s), not the mention the "mass breakage" thing. If
>> 0.11 plugins really need to extend the ctxnav, they can probably do so
>> using an ITemplateStreamFilter anyway.
>>
>
> Extending the ctxtnav has been a long standing issue that I think is
> quite important, too. If Noah or someone else can come up with a patch
> quickly enough, I'd be in favor of including it in 0.11, even after
> b1. Otherwise, it shouldn't block.
>
Agreed.
>
>> I rather think this refactoring fits well with the 0.12 goals already
>> mentioned elsewhere [1]. In particular, one goal would be to actually
>> /remove/ all the layout related stuff from the Request, as that part
>> of
>> the code is quite fragile (see e.g.
>> http://trac.edgewall.org/changeset/6135), and not to add more to it.
>>
>
> Remove it and move it where to?
>
> (Here's hoping you're not going to suggest mimeview)
No, I rather think the template data dictionary is the right place for
that. All these informations (css, scripts, navigation links, warnings)
are meant to be used by the layout.html template and /only/ by it, so it
would be quite natural to use a 'layout' (or even the existing 'chrome')
entry in the dictionary for storing all these things.
I don't see the real need to use the Request object (not to mention the
transient "FakeRequest") as an intermediate storage. AFAICT, the various
hoops in the code are due to the way the 'chosen_handler' needs to be
known when calling Chrome.prepare_request, all this for setting the
active flag on the appropriate nav entry. I'm sure there's a simpler way
to achieve the same effect, like setting that flag a posteriori, after
chosen_handler.process_request(), perhaps as part of the populate_data()
step.
-- 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
-~----------~----~----~----~------~----~------~--~---
