On , Bohuslav Kabrda wrote:
----- Original Message -----
So I would like to propose:
/ > home
/coprs/ > list all the repos (same as home, atm)
/coprs/<user>/ > list someone's copr
/coprs/<user>/<repo>/ > the detail of this copr
/coprs/<user>/<repo>/{permissions,builds,...}/ > same as now the
permissions, builds or other page for this repo (the repo file for yum
could end up here as /coprs/<user>/<repo>/repo/ )
I've been thinking about this for a long time and this is why I
decided to not take your proposed way:
Since Copr doesn't have control over user names (it takes them from
FAS, currently), we cannot prevent user named e.g. "new" or "edit"
to
register. Since "new" and "edit" are also keywords (/coprs/new/,
/coprs/edit/) accessed by GET, this would result in an ugly URL
collision (either user's coprs list would be unaccessible or noone
would be able to display the "new copr" page).
Does that make sense or have I missed something?
Hi Slavek,
Indeed, I was missing these two cases. I thought of two approaches:
change the URLs pattern:
- /coprs_new/
- /user_edit/
I'm not big fan of this approach (but it's one)
Incorporate the username in the URL:
- /coprs/<user>/new
- /coprs/<user>/edit <- (this is the edit page of the user prefs
right?, otherwise it should be /coprs/<user>/<repo>/edit)
Since we have the hand on the repos creation we can blacklist "edit"
and "new" as copr name and since a user have to be logged in to access
the new or edit pages we can generate these URLs.
I like this approach more than the previous but, it's a bit of thinking
out loudly here, I'm not sure this is the best solution
Best regards,
Pierre