incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: [RFC] [multiproduct] Review #1
Date Fri, 15 Jun 2012 22:16:02 GMT
On 6/14/12, Gary Martin <gary.martin@wandisco.com> 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` ...

{{{
#!python

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 = match.group('pid')
            products = Product.select(self.env, where={'prefix':pid})
            if len(products) == 1:
                req.args['productid'] = match.group('pid')
                req.args['product'] = products[0].name
                pathinfo = match.group('pathinfo')
                # is it a newticket request:
                if pathinfo == "/newticket":
                    return True
                tmatch = TICKET_RE.match(pathinfo)
                if tmatch:
                    req.args['id'] = tmatch.group('ticket')
                    return True

}}}

... and as a consequence it seems ticket URLs will look like
http://server.com/path/to/bh/MyProduct/ticket/33 ... 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.

+1

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

ok
;)

.. [1] Sample product page
        (http://svn.apache.org/repos/asf/incubator/bloodhound/trunk/doc/html-templates/product.html)

-- 
Regards,

Olemis.

Mime
View raw message