You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Antonia Horincar <an...@gmail.com> on 2013/07/01 01:03:35 UTC
Re: [GSoC - Embeddable Tickets]: 'Ticket does not exist' error
On Sun, Jun 30, 2013 at 11:55 PM, Matevž Bradač <ma...@digiverse.si> wrote:
>
> On 30. Jun, 2013, at 6:52, Olemis Lang wrote:
>
> > On 6/29/13, Antonia Horincar <an...@gmail.com> 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.
>
>
Re: [GSoC - Embeddable Tickets]: 'Ticket does not exist' error
Posted by Matevž Bradač <ma...@digiverse.si>.
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č <ma...@digiverse.si> wrote:
>
>>
>> On 1. Jul, 2013, at 1:03, Antonia Horincar wrote:
>>
>>> On Sun, Jun 30, 2013 at 11:55 PM, Matevž Bradač <ma...@digiverse.si>
>> wrote:
>>>
>>>>
>>>> On 30. Jun, 2013, at 6:52, Olemis Lang wrote:
>>>>
>>>>> On 6/29/13, Antonia Horincar <an...@gmail.com> 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.
>>>>
>>>>
>>
>>
Re: [GSoC - Embeddable Tickets]: 'Ticket does not exist' error
Posted by Antonia Horincar <an...@gmail.com>.
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č <ma...@digiverse.si> wrote:
>
> On 1. Jul, 2013, at 1:03, Antonia Horincar wrote:
>
> > On Sun, Jun 30, 2013 at 11:55 PM, Matevž Bradač <ma...@digiverse.si>
> wrote:
> >
> >>
> >> On 30. Jun, 2013, at 6:52, Olemis Lang wrote:
> >>
> >>> On 6/29/13, Antonia Horincar <an...@gmail.com> 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.
> >>
> >>
>
>
Re: [GSoC - Embeddable Tickets]: 'Ticket does not exist' error
Posted by Matevž Bradač <ma...@digiverse.si>.
On 1. Jul, 2013, at 1:03, Antonia Horincar wrote:
> On Sun, Jun 30, 2013 at 11:55 PM, Matevž Bradač <ma...@digiverse.si> wrote:
>
>>
>> On 30. Jun, 2013, at 6:52, Olemis Lang wrote:
>>
>>> On 6/29/13, Antonia Horincar <an...@gmail.com> 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.
>>
>>