Hi, Thanks for your reply. I am going to take a closer look at the existing components to see how are they being processed in their current implementation. I might need to ask some more questions regarding this aspect, but I'll get back to you after I have a better look at them.
Also, it's the first time I'm using Subversion as a version control system and I'm not sure how are we going to be able to commit things. I have cloned the repo, but I'm not sure of whether we are allowed to simply commit things, without 'asking' for permission (like pull requests in Git) or not. And if not, what steps should we follow in order to be able to commit? I'm a little bit scared at the thought of 'breaking' things, so if you have some useful tips on SVN, that would be really appreciated (I'm not talking about obvious steps, but maybe some of you have encountered some special situations, and have some advise on the good practice of SVN). Thanks, Antonia On Fri, Jun 14, 2013 at 7:56 PM, Gary Martin <[email protected]> wrote: > On 12/06/13 16:14, Antonia Horincar wrote: >> >> Hi, >> >> I decided that I am going to implement the IRequestHandler interface >> for retrieving and processing information about tickets, in favour of >> using RestOnTrac, because I'm trying to avoid using external plugins. >> However, I'm not sure what would be the required methods in the class >> that extends IRequestHandler (besides the match_request method, which >> checks if the given request can be processed by the handler, and the >> process_request method, which returns the information about the object >> queried). Does anyone have an idea on how the information should be >> dealt with after being retrieved? > > > I suspect that a lot of this reply is going to be redundant as BEP-0007 > already includes appropriate links to information that you have found. > However... > > I believe that the IRequestHandler interface only requires those methods > that you have already listed. The link you put in your proposal wiki page > (http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.web.api.IRequestHandler) > may describe it well enough. > > As for the question of how the information should be dealt with after being > retrieved, you might need to be more specific. However, to try to answer a > question.. the basic tasks of components that implement IRequestHandler are > to determine > > 1. determine whether they are interested in a request, > 2. gather the relevant information you need to determine how to fulfil > the request, and > 3. collect data based on that information to fill a template that will > be rendered in response > > Through a lot of that, the req argument is going to be your friend. A > restful url scheme will generally take a lot of notice of req.path_info for > instance, req.method will give you the HTTP method (GET, POST, etc) and > req.args should give you access to the query string if that is useful. You > then essentially collect the data of interest in a dictionary that you can > use the items of which to populate your template. > > Though it may not hurt to experiment with collecting bits of data for > yourself, it might be worth considering effectively reusing the processing > of existing components that already collect all the data you require but > then provide a new template. This may not always be appropriate of course. > > >> Also, what other interfaces should be implemented along >> IRequestHandler? I guess IPermissionRequestor whould be one of them, >> but what other interfaces will I probably need? >> >> Thanks, >> Antonia > > > IPermissionRequestor will be useful if you want to provide custom > permissions for your plugin so that access to the interface can be > restricted as the site admin desires. The underlying data should still be > subject to relevant permissions for that data of course but it is probably > worth it. > > As a provider of templates, you are probably going to want to implement > ITemplateProvider as you have already noted in BEP-0007. > > If you wish to add any navigation items to the main interface, you should > also implement INavigationContributor. Whether this is that useful for your > case is another matter. > > I suspect that is everything you are likely to need to implement for now. > > Cheers, > Gary
