On 1. Jul, 2013, at 13:31, Antonia Horincar wrote: > 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.
Excellent, great to see it working! I should've mentioned it earlier, but you can also enable/disable the plugins through the admin UI. If you login as an administrator and navigate to the Admin page (e.g. /main/admin) you will find a Plugins link in the General 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. That's completely understandable, don't worry about asking too many or "wrong" questions etc. As in most projects there are areas which are either poorly documented or not documented at all, don't work as described and so on. Asking a question on the community mailing list will open up a debate, which in turn leads to knowledge exchange and sharing. In addition, the discussions are also archived (e.g. http://apache.markmail.org/search/?q=list%3Abloodhound) so they are readily available as a reference. > > 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. >>>> >>>> >> >>
