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. > 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? > 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. > >
