On 19/11/12 07:04, Olemis Lang wrote:
I've been working on BEP-0003 recently , adding some routes we should
support and why . Some details still missing on the subject ,
especially how all this will work in the context of product
environments .
... read below ...
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>.
[...]
+In a multi-product configuration product resources should not be accessed
using current global URL scheme (i.e.
/path/to/bloodhound/<environment>/<realm>/<id>). Since [#permissions
products will have their own permissions schema] then requests handled by
components in the context of the top-level environment will perform neither
the right permissions checks nor even use appropriate settings , and so on
... The same will happen for resources moved between products . In general
such requests should be redirected to a URL under the namespace of
resource's product.
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
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.
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.
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.
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.
Cheers,
Gary
