Hi all,
Something, I have been discussing with Tomas last week but not with Slavek or the list, is the URLs we have in copr.
For example: front page: / detail of a copr: /coprs/detail/toshio/packagedb/ copr's permissions: /coprs/detail/toshio/packagedb/permissions/ copr's builds: /coprs/detail/toshio/packagedb/builds/ someone's copr: /coprs/owned/toshio/
I basically would like to change a couple of things. At the moment when I'm looking at toshio's packagedb repos there is no way to (from the url) easily go back to the list of toshio's copr.
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/ )
It's something I have in mind but would like to discuss before doing (unless someone beats me to it).
So, what do you think?
Pierre
----- Original Message -----
Hi all,
Something, I have been discussing with Tomas last week but not with Slavek or the list, is the URLs we have in copr.
For example: front page: / detail of a copr: /coprs/detail/toshio/packagedb/ copr's permissions: /coprs/detail/toshio/packagedb/permissions/ copr's builds: /coprs/detail/toshio/packagedb/builds/ someone's copr: /coprs/owned/toshio/
I basically would like to change a couple of things. At the moment when I'm looking at toshio's packagedb repos there is no way to (from the url) easily go back to the list of toshio's copr.
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/ )
It's something I have in mind but would like to discuss before doing (unless someone beats me to it).
So, what do you think?
Pierre
Hi Pierre, 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? Slavek.
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
On 06/17/2013 09:30 AM, Bohuslav Kabrda wrote:
Hi Pierre, 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? Slavek.
True. What about?
/ > home /coprs/details/ > list all the repos (same as home, atm) #-----^^^^^^^^^ this is the change /coprs/details/<user>/ > list someone's copr /coprs/details/<user>/<repo>/ > the detail of this copr /coprs/details/<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/ )
On , Miroslav Suchý wrote:
On 06/17/2013 09:30 AM, Bohuslav Kabrda wrote: Hi Pierre, 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? Slavek.
True. What about?
/ > home /coprs/details/ > list all the repos (same as home, atm) #-----^^^^^^^^^ this is the change /coprs/details/<user>/ > list someone's copr /coprs/details/<user>/<repo>/ > the detail of this copr /coprs/details/<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/ )
That's also an option :) But I would argue for using "view" rather than "details".
Then we would have: /coprs/view/<user>/ /coprs/edit/<user>/ # edit the user info (if/when we have one) /coprs/delete/<user>/ # delete the user entirely
/coprs/new/<user>/ # create a new repo for this user /coprs/view/<user>/<repo>/ # view this repo /coprs/edit/<user>/<repo>/ # edit this repo /coprs/delete/<user>/<repo>/ # delete this repo
Pierre
On 06/17/2013 10:59 AM, Pierre-Yves Chibon wrote:
That's also an option :) But I would argue for using "view" rather than "details".
Then we would have: /coprs/view/<user>/ /coprs/edit/<user>/ # edit the user info (if/when we have one) /coprs/delete/<user>/ # delete the user entirely
/coprs/new/<user>/ # create a new repo for this user /coprs/view/<user>/<repo>/ # view this repo /coprs/edit/<user>/<repo>/ # edit this repo /coprs/delete/<user>/<repo>/ # delete this repo
But then you can not go back in terms of url. I.e. by deleting trailing part of url you could not go back (which was your original problem).
On Mon, 2013-06-17 at 14:44 +0200, Miroslav Suchý wrote:
On 06/17/2013 10:59 AM, Pierre-Yves Chibon wrote:
That's also an option :) But I would argue for using "view" rather than "details".
Then we would have: /coprs/view/<user>/ /coprs/edit/<user>/ # edit the user info (if/when we have one) /coprs/delete/<user>/ # delete the user entirely
/coprs/new/<user>/ # create a new repo for this user /coprs/view/<user>/<repo>/ # view this repo /coprs/edit/<user>/<repo>/ # edit this repo /coprs/delete/<user>/<repo>/ # delete this repo
But then you can not go back in terms of url. I.e. by deleting trailing part of url you could not go back (which was your original problem).
From view you can but indeed from an edit page you cannot go back to the
view.
I guess having the action at the end might be the easiest then: /coprs/<user>/ /coprs/<user>/edit/ # edit the user info (if/when we have one) /coprs/<user>/delete/ # delete the user entirely
/coprs/<user>/new/ # create a new repo for this user /coprs/<user>/<repo>/ # view this repo /coprs/<user>/<repo>/edit/ # edit this repo /coprs/<user>/<repo>/delete/ # delete this repo
Pierre
On Mon, Jun 17, 2013 at 02:53:31PM +0200, Pierre-Yves Chibon wrote:
On Mon, 2013-06-17 at 14:44 +0200, Miroslav Suchý wrote:
On 06/17/2013 10:59 AM, Pierre-Yves Chibon wrote:
That's also an option :) But I would argue for using "view" rather than "details".
Then we would have: /coprs/view/<user>/ /coprs/edit/<user>/ # edit the user info (if/when we have one) /coprs/delete/<user>/ # delete the user entirely
/coprs/new/<user>/ # create a new repo for this user /coprs/view/<user>/<repo>/ # view this repo /coprs/edit/<user>/<repo>/ # edit this repo /coprs/delete/<user>/<repo>/ # delete this repo
But then you can not go back in terms of url. I.e. by deleting trailing part of url you could not go back (which was your original problem).
From view you can but indeed from an edit page you cannot go back to the
view.
I guess having the action at the end might be the easiest then: /coprs/<user>/ /coprs/<user>/edit/ # edit the user info (if/when we have one) /coprs/<user>/delete/ # delete the user entirely
/coprs/<user>/new/ # create a new repo for this user /coprs/<user>/<repo>/ # view this repo /coprs/<user>/<repo>/edit/ # edit this repo /coprs/<user>/<repo>/delete/ # delete this repo
I am still interested in this and still willing to implement it. So what do you think of this proposal?
If we agree, shall I commit or shall I just send pull-request/patches to the list for review first (as this will change a number of files)?
Best regards, Pierre
On 09/12/2013 09:34 PM, Pierre-Yves Chibon wrote:
I am still interested in this and still willing to implement it. So what do you think of this proposal?
Then do it. I think we have important things to do, so I will focus on something else. But if you want to do that, then do it.
If we agree, shall I commit or shall I just send pull-request/patches to the list for review first (as this will change a number of files)?
Rule of thumb: * Test it and commit it. * If you do not test it or you are unsure about something send it to mailing for review first.
Mirek
On Thu, Sep 12, 2013 at 8:34 PM, Pierre-Yves Chibon pingou@pingoured.frwrote:
On Mon, Jun 17, 2013 at 02:53:31PM +0200, Pierre-Yves Chibon wrote:
On Mon, 2013-06-17 at 14:44 +0200, Miroslav Suchý wrote:
On 06/17/2013 10:59 AM, Pierre-Yves Chibon wrote:
That's also an option :) But I would argue for using "view" rather than "details".
Then we would have: /coprs/view/<user>/ /coprs/edit/<user>/ # edit the user info (if/when we have
one)
/coprs/delete/<user>/ # delete the user entirely
/coprs/new/<user>/ # create a new repo for this user /coprs/view/<user>/<repo>/ # view this repo /coprs/edit/<user>/<repo>/ # edit this repo /coprs/delete/<user>/<repo>/ # delete this repo
But then you can not go back in terms of url. I.e. by deleting trailing part of url you could not go back (which was your original problem).
From view you can but indeed from an edit page you cannot go back to the
view.
I guess having the action at the end might be the easiest then: /coprs/<user>/ /coprs/<user>/edit/ # edit the user info (if/when we have one) /coprs/<user>/delete/ # delete the user entirely
/coprs/<user>/new/ # create a new repo for this user /coprs/<user>/<repo>/ # view this repo /coprs/<user>/<repo>/edit/ # edit this repo /coprs/<user>/<repo>/delete/ # delete this repo
I am still interested in this and still willing to implement it. So what do you think of this proposal?
My personal opinion is having an action at the end might be tricky
especially after a commit. I thing we should have sections, for example: /coprs/<user>/setttings: this is for user profile settings /copr/<user>/<repo>/settings : this is for settings to the repo
the actions can be done within settings without necessarily having to give a URL> makes it cleaner. I also think if we are within the repo then actions do not necessarily need to be in URL.
but this is just my opinion.
If we agree, shall I commit or shall I just send pull-request/patches to the list for review first (as this will change a number of files)?
Best regards, Pierre
copr-devel mailing list copr-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copr-devel
copr-devel@lists.fedorahosted.org
-
Bohuslav Kabrda -
Frankie -
Miroslav Suchý -
Pierre-Yves Chibon