Thank you very much, everything's fine now. It wasn't working because I didn't enable the plugin in the base.ini file. I was following the steps described in the here[1], under the 'Installing a plugin - for a single project' section, and there was no mention of having to enable it in config/base.ini. In the 'Installing a plugin - for all projects' section it does say, however, how to enable the plugin, but as I said I was following the instructions from the 'single project' section.
Anyway, thanks for your help and patience, I apologise if some of my questions seemed like I wasn't trying enough to understand everything on my own first, but it was a bit difficult for me to see exactly how the existing code works and how the existing classes and methods interact with each other. Antonia [1] http://trac.edgewall.org/wiki/TracPlugins On Mon, Jul 1, 2013 at 10:27 AM, Matevž Bradač <[email protected]> wrote: > > On 1. Jul, 2013, at 1:03, Antonia Horincar wrote: > > > On Sun, Jun 30, 2013 at 11:55 PM, Matevž Bradač <[email protected]> > wrote: > > > >> > >> On 30. Jun, 2013, at 6:52, Olemis Lang wrote: > >> > >>> On 6/29/13, Antonia Horincar <[email protected]> wrote: > >>>> Hi, > >>>> > >>> > >>> :) > >>> > >>>> Thank you for your help. But unfortunately I'm still struggling with > the > >>>> problem. > >>>> I noticed that when printing the self.env variable in the > match_request > >>>> method from my API I get: > >>>> <multiproduct.env.Environment object at 0x1bd1610> > >>>> but when I print the self.env variable from the match_request from the > >>>> TicketModule class in trac.ticket.web_ui, I get this: > >>>> <ProductEnvironment u'@' at 0x7f0ce07d0d90> > >>>> > >>>> I have spent a lot of time trying to understand why is my API using > >> another > >>>> environment, but I couldn't. Do you have any idea why this is > happening? > >>>> > >>>> Thanks > >>>> > >> > >> Hi, > >> > >> Which URL were you using when accessing your API? If it was the > >> /main/api/ticket/<ID> then you would get the > multiproduct.env.Environment > >> in self.env. If accessed from /main/products/<prefix>/api/ticket/<ID> > >> however, it should be the ProductEnvironment. > >> > > > > I was accessing the API with /main/api/ticket/<id> and I understand now > why > > the request was handled in the global context, but I don't understand why > > is it that when I try to access it through the product it belongs to, I > get > > an error saying that no handler is matching that request. > > That's strange - the code you posted the last time works OK for me. > I have a ticket with ID 1 in the default product (@), and I'm accessing > your plugin through > <hostname:port>/main/products/@/api/ticket/1 > This works fine, the match_request() as well as the process_request() from > your plugin are called and the template is rendered. > > I suggest you set a breakpoint in trac.web.main.dispatch_request() and > step through the code from there. Also, check the conf/base.ini in your > trac environment, the following should be set under [components] section > bhembedding.* = enabled > > > > > > >> As Olemis mentions below, the multiproduct.hooks module is responsible > >> for dealing with product-related handling and redirects, namely: > >> a) if a product is referenced through e.g. /main/products/<prefix>... > >> then the product-specific environment is instantiated and the request > >> passed to it > >> > > > > I looked at the match_request method from the ProductModule class in > > multiproduct.web_ui, and I'm not sure if I understood right but from > what I > > see it is here where the request is being passed to the product-specific > > environment. But then why do I get the 'Not Found - No handler matched > > request' error? > > See above, the request should indeed be passed to the product environment. > > > > > > >> b) if it's not a product-related request in question, then the code > >> checks whether the request should be passed to the default product. > >> This is because certain requests don't make sense in the global scope > >> (e.g. /newticket, /milestone etc.). > >> > >> If none of the above conditions apply then the request is handled in the > >> global context, which I'm assuming happened in your case. > > > > > > > > > >> -- > >> matevz > >> > >>> > >>> Maybe that's caused by *default* hooks redirecting requests to default > >>> product . See multiproduct.hooks module in Bloodhound Multiproduct > >>> plugin for further details . > >>> > >>> -- > >>> Regards, > >>> > >>> Olemis. > >> > >> > >
