bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [RFC] [multiproduct] Review #1
Date Fri, 15 Jun 2012 22:16:02 GMT
On 6/14/12, Gary Martin <> wrote:
> Hi Olemis,

Hi !

> A bit too much in that message to comment sensibly in a single email but
> I will try to cover some points. The first part is a particularly
> confusing as I do not see the common module in
> bloodhound_multiproduct/multiproduct, I wonder if you are looking at the
> right code.

Maybe it's an hgsvn side-effect once again ...

> Meanwhile I didn't follow the p prefix idea but instead decided on
> req.path_info.startswith('/products') so that it is more obvious what it
> is for. I don't mind variations on that but I think that /p is not
> enough to retain clarity. Even if google use it.

yes , that's ok . any prefix is ok . Nonetheless I see this code for
`ProductTicketModule.match_request` ...


PRODUCT_RE = re.compile(r'^/(?P<pid>[^/]*)(?P<pathinfo>.*)')
TICKET_RE = re.compile(r'/ticket/(?P<ticket>[0-9]+)$')
class ProductTicketModule(TicketModule):
    """Product Overrides for the TicketModule"""

    # IRequestHandler methods
    def match_request(self, req):
        """Override of TicketModule match_request"""
        match = PRODUCT_RE.match(req.path_info)
        if match:
            pid ='pid')
            products =, where={'prefix':pid})
            if len(products) == 1:
                req.args['productid'] ='pid')
                req.args['product'] = products[0].name
                pathinfo ='pathinfo')
                # is it a newticket request:
                if pathinfo == "/newticket":
                    return True
                tmatch = TICKET_RE.match(pathinfo)
                if tmatch:
                    req.args['id'] ='ticket')
                    return True


... and as a consequence it seems ticket URLs will look like ... i.e. no prefix at
all .

>>   3- I wonder whether it'd be a good idea to
> Possibly but it could be overkill if there are not going to be that many
> additional models to support.

ok, no big deal ... ;)

>>   5- It's cool to have models ! :)
> I agree it would probably be better to use a pre-existing ORM - I would
> quite like to see the whole of bloodhound including trac to use such an
> approach so that more of the system can be taken a consistent step away
> from raw SQL.


> I don't know if I am on my own in liking good ORMs of
> course which is why I have not made too much of it. I do have a secret
> desire to be using django's model and query system though!

ok , cool !

> I think we are placing a higher priority on getting the basic interface
> right than getting multi-product fully working (product namespaces,
> permissions etc).

By the way I reviewed the code because I wanted to start converting
product pages to look like latest design , but it doesn't seem to work
. I mean , I get 404 error pages if I enable
`multiproduct.ticket_web_ui.ProductTicketModule` and disable
`trac.ticket.web_ui.TicketModule` . So basically I cannot see ticket
pages , or they do not contain product field anywhere , so I don't
know how to set args for widgets displaying tickets [1]_ etc , etc,
etc ... as basically I see no way to bind tickets to products I
already created one product for testing purposes , btw ;)

> I can see that work slipping to the next milestone if
> we are not able to get more people interested in working with us and up
> to speed in the short term.


.. [1] Sample product page



View raw message