Peter Dimov wrote:
> Christian Boos wrote:
>
>> instead of using an API of the LogRequest class. process() is a generic
>> method from the parent RequestHandler class, which will dispatch to the
>> appropriate method of the subclass according to the action parameter
>> ('do_<action>' or 'render_<action>' ones, the former for GET requests
>> and the latter for POST requests). This is not that useful for the
>> LogRequest, where the only action is 'view' (the default), but would be
>> for other handlers.
>>
>
> The RequestHandler idea is great! The definition of RequestHandler
> should be moved elsewhere though. You'd know better than me which module
> is most suitable.
>
Well, ideally it should go in trac/web/api.py, next to the IRequestHandler.
Hm, probably a more distinctive name would be useful then, like
RequestProcessor.
> Do we really need two different handlers ('do_<action>' or
> 'render_<action>') for the *same* action? I wouldn't actually care
> whether I got the data form the query string with of a GET request or in
> the message body of a POST request... all the handler should care about
> is to get the data and handle the request. Or maybe there's a difference
> in the way trac handles GET and POST requests that I'm unaware of?
>
We usually use posts to trigger some side-effect in the database, so
after having processed the POST we usually send a redirect so that the
client GETs the latest version of the resource. But you're right, there
are situations where we don't differentiate, and we should probably
default to the render_<action> method when the do_<action> one is not
implemented. The opposite is not desired however, as we have some
protective measures for submissions that should be done exclusively with
a POST (grep for form_token in trac/web).
>>> I plan to do similar refactoring to ChangesetModule before proceeding
>>> with the version control api refactoring. Actually I would further
>>> refactor LogRequest and ChangesetRequest to use the "perfect" version
>>> control api. I guess we would have some discussion about how perfect it
>>> is before actually going ahead and changing it ;-)
>>>
>> Please take a look at my updated patch. If we both feel we can achieve
>> something going on this way, maybe we should restart a vc-refactoring
>> branch ;-) As you proposed, we should first start there by some
>> clean-ups and refactoring of the current code base.
>>
>
> Yes, we will definitely achieve something! I hope I'll be able to
> refactor BrowserModule and ChangesetModule and provide a patch for
> review by the end of the week :-).
>
Ok, so I'd like to restart the sandbox/vc-refactoring branch, and I'd
like that Peter could commit there as well.
The idea would be to get that last patch there, then move the
RequestHandler to trac.web.api.RequestProcessor and do a similar
refactoring for the Browser and Changeset modules. This cleanup would be
beneficial to 0.11 and will enable Peter to become familiar with the
existing code; Peter who has already volunteered for providing us with
the perfect versioncontrol API for 0.12 (as I understood it, right? ;-) ).
Any dissenting opinion?
-- 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
-~----------~----~----~----~------~----~------~--~---
