On 11/19/12, Gary Martin <[email protected]> wrote: > On 19/11/12 07:04, Olemis Lang wrote: [...] >> >> On 11/19/12, Apache Bloodhound <[email protected]> >> wrote: >>> Page "Proposals/BEP-0003" was changed by olemis >>> Diff URL: >>> <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=14> >>> Revision 14 >>> Comment: [BEP-003] Sample product URL mappings TODO: Detailed request >>> dispatching >>> Changes: >>> -------8<------8<------8<------8<------8<------8<------8<------8<-------- >>> Index: Proposals/BEP-0003 >>> >> [...] >>> '''FIXME''' also be addressable through the product URL namespace, >>> namely >>> /ticket/<product prefix>/<local ticket id>. >>> [...] >>> >> Since proposed solution consists in replicating multi-environment >> setup inside a single environment formerly proposed URL template (i.e. >> /ticket/<product prefix>/<sequence ID>) seems not to be appropriate >> for request dispatching, filtering and other processes taking place in >> the context of product environments. >> >> Therefore I'm proposing to move it to «Rejected ideas» section . I >> look forward to your comments for feedback . >> > > I am not sure that there is enough justification to allow for allowing a > path/to/ticket/<product prefix>/<ticketid> - when only considering this > form for tickets it is certainly possible but we should be making our > lives easy for the determination of all resources that belong to a > product so we are probably looking at (in a fairly generalised form): > > pathto/<namespace path>/<product prefix>/pathtoresource >
+1 > Up until now I have been considering using 'products' as <namespace > path> but we might want to choose something else or even consider > whether this should be configurable. Configurability leads to some > problems when a user chooses a path that is already taken of course. > I have a idea for this ... I'll write something on the subject later today . > Presumably, running under an appropriate apache configuration, we would > be able to effectively access the a product without the user having to > specify the <namespace path> and we could even get the <product prefix> > specified as a subdomain instead. > like in edgewall.org , yes > Anyway, with this scheme, the pathtoresource would represent anything > that could be considered as belonging to the product using the same > subsequent path as it would if it did not belong to a product. +1 Nonetheless I'll wait for a while to move that paragraph to «rejected ideas» section in spite of giving ourselves the chance to consider more opinions . > Effectively, this should probably apply to every resource that you can > have outside of a product (versions, milestones, wiki, etc) but it is > likely that this is where things begin to get a bit messy when > considering plugins that are not product-aware. > yes , eventually we need to come up with something regarding shared resources ... to be discussed in a separate thread , please ;) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
