[drupal-devel] hard coded page sizes
I have a use to expose some of the admin type pages (logs, users etc) in a view with limited space available. I noticed that the page size is hard coded in all modules that use drupals paging mechanism. A quick glance reveals the following hard-coded pages sizes: watchdog = 50 lines user = 50 lines statistics = 30 lines comment = 50 lines poll = 50 lines I think it would be really usefull to provide a mechanism to override these hard-coded values. I would suggest something simple like apending a value to the url in the query string for page size. This value could be interogated by each module that calls theme_pager_link() to see if it should use it's hard-coded default or use an override. I'm more than happy to provide some patches for this but I wanted to make sure I wasn't missing a far easier way to solve this issue. Does anyone else see value in this? Is there a better way to do this other than patching the core modules?
David Reed wrote:
I have a use to expose some of the admin type pages (logs, users etc) in a view with limited space available. I noticed that the page size is hard coded in all modules that use drupals paging mechanism. A quick glance reveals the following hard-coded pages sizes:
watchdog = 50 lines user = 50 lines statistics = 30 lines comment = 50 lines poll = 50 lines
I think it would be really usefull to provide a mechanism to override these hard-coded values. I would suggest something simple like apending a value to the url in the query string for page size. This value could be interogated by each module that calls theme_pager_link() to see if it should use it's hard-coded default or use an override.
Or a setting in the admin/settings/<module> page --Vernon
On Tuesday 11 October 2005 16:53, Vernon Mauery wrote:
I think it would be really usefull to provide a mechanism to override these hard-coded values. I would suggest something simple like apending a value to the url in the query string for page size. This value could be interogated by each module that calls theme_pager_link() to see if it should use it's hard-coded default or use an override.
Or a setting in the admin/settings/<module> page
How about having a global setting in q=admin/settings but letting registered users override it with a user profile setting? Per-module is probably not needed, because the page size won't change depending on which module you're in. On the other hand, nothing I've proposed would preclude a module adding its own per-module setting if it wanted to, and that module could rely on the system- or user-chosen value as defaults. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
I have a use to expose some of the admin type pages (logs, users etc) in a view with limited space available. I noticed that the page size is hard coded in all modules that use drupals paging mechanism. A quick glance reveals the following hard-coded pages sizes:
watchdog = 50 lines user = 50 lines statistics = 30 lines comment = 50 lines poll = 50 lines
I think it would be really usefull to provide a mechanism to override these hard-coded values. I would suggest something simple like apending a value to the url in the query string for page size. This value could be interogated by each module that calls theme_pager_link() to see if it should use it's hard-coded default or use an override.
I'm more than happy to provide some patches for this but I wanted to make sure I wasn't missing a far easier way to solve this issue.
Does anyone else see value in this? Is there a better way to do this other than patching the core modules?
No URL parameters please! None! Let this be a setting for the admin and/or the user, if you want this customized. Goba
Hi, These are issues that indeed need attention too, often. I would suggest to make it all 50, and then use a variable_get('foo', 50) in those hardcoded places. A configuration setting in drupal could then allow setting this. I would say /admin/settings/adminpages is a nice place to bundle all our administration settings. Just my €0.02 Bèr On Tuesday 11 October 2005 22:16, David Reed wrote:
I have a use to expose some of the admin type pages (logs, users etc) in a view with limited space available. I noticed that the page size is hard coded in all modules that use drupals paging mechanism. A quick glance reveals the following hard-coded pages sizes:
watchdog = 50 lines user = 50 lines statistics = 30 lines comment = 50 lines poll = 50 lines
I think it would be really usefull to provide a mechanism to override these hard-coded values. I would suggest something simple like apending a value to the url in the query string for page size. This value could be interogated by each module that calls theme_pager_link() to see if it should use it's hard-coded default or use an override.
I'm more than happy to provide some patches for this but I wanted to make sure I wasn't missing a far easier way to solve this issue.
Does anyone else see value in this? Is there a better way to do this other than patching the core modules?
I don't like hardcoded values at all, and I'd like *everything* to be configurable. The problem is if we make everything configurable, the admin interface would be unmanageable. Proposed solution: Make all of these values configurable in the settings file, but not through the web pages. Ideally, we'd access all of these values throught the variable_get/variable_set interface, but then we'd need some array in the settings file to hold all of these values, and then the variable management functions to discriminate between the ones that have to be set into the database and the ones that are in the code. David Reed wrote:
I have a use to expose some of the admin type pages (logs, users etc) in a view with limited space available. I noticed that the page size is hard coded in all modules that use drupals paging mechanism. A quick glance reveals the following hard-coded pages sizes:
watchdog = 50 lines user = 50 lines statistics = 30 lines comment = 50 lines poll = 50 lines
I think it would be really usefull to provide a mechanism to override these hard-coded values. I would suggest something simple like apending a value to the url in the query string for page size. This value could be interogated by each module that calls theme_pager_link() to see if it should use it's hard-coded default or use an override.
I'm more than happy to provide some patches for this but I wanted to make sure I wasn't missing a far easier way to solve this issue.
Does anyone else see value in this? Is there a better way to do this other than patching the core modules?
For a screenshot of what I'm trying to do see. http://mycivicsite.com/admin_screenshot1.png Also see posting http://drupal.org/node/33862 If we make it a variable setting then I'm stuck with one page size for the site. As you can see from the screenshot I could view the log entries from within the tabs on the front page as well as viewing them on the normal logs page. On 10/12/05, Konstantin Käfer <kkaefer@gmail.com> wrote:
Karoly Negyesi schrieb:
Proposed solution: Make all of these values configurable in the settings file, but not through the web pages.
This one I like.
Seconded :D
Another route to take here is the theme route. Themes are not just for visual shazam. "themes are there to control the look and feel". Feel, means control over all the output. AFAIK you can set all these values in the theme. And if not, i think a patch that makes the amount easy themable will be the best route to take. After all: it is the fact that a specific theme does not like a certain amount of lines in a pager, that brings up this issue. Not the fact user X wants 20 and user Y wants 30. Bèr On Wednesday 12 October 2005 18:38, David Reed wrote:
For a screenshot of what I'm trying to do see.
http://mycivicsite.com/admin_screenshot1.png
Also see posting http://drupal.org/node/33862
If we make it a variable setting then I'm stuck with one page size for the site. As you can see from the screenshot I could view the log entries from within the tabs on the front page as well as viewing them on the normal logs page.
On 10/12/05, Konstantin Käfer <kkaefer@gmail.com> wrote:
Karoly Negyesi schrieb:
Proposed solution: Make all of these values configurable in the settings file, but not through the web pages.
This one I like.
Seconded :D
I think conceptually setting this in the theme would work but as I understand this it can't be done the way things are now as most of the time a particalr module is calling the pager_query function to return the correct number of db rows to match the page size and that is all done outside the theme functions. On 10/12/05, Bèr Kessels <ber@webschuur.com> wrote:
Another route to take here is the theme route.
Themes are not just for visual shazam. "themes are there to control the look and feel".
Feel, means control over all the output. AFAIK you can set all these values in the theme. And if not, i think a patch that makes the amount easy themable will be the best route to take.
After all: it is the fact that a specific theme does not like a certain amount of lines in a pager, that brings up this issue. Not the fact user X wants 20 and user Y wants 30.
Bèr
On Wednesday 12 October 2005 18:38, David Reed wrote:
For a screenshot of what I'm trying to do see.
http://mycivicsite.com/admin_screenshot1.png
Also see posting http://drupal.org/node/33862
If we make it a variable setting then I'm stuck with one page size for the site. As you can see from the screenshot I could view the log entries from within the tabs on the front page as well as viewing them on the normal logs page.
On 10/12/05, Konstantin Käfer <kkaefer@gmail.com> wrote:
Karoly Negyesi schrieb:
Proposed solution: Make all of these values configurable in the settings file, but not through the web pages.
This one I like.
Seconded :D
I think conceptually setting this in the theme would work but as I understand this it can't be done the way things are now as most of the time a particalr module is calling the pager_query function to return the correct number of db rows to match the page size and that is all done outside the theme functions.
It can be made into a theme setting though, to be changeable on the theme settings pane. Goba
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12 Oct 2005, at 9:09 PM, Gabor Hojtsy wrote:
It can be made into a theme setting though, to be changeable on the theme settings pane.
Or someone can write a small module with an interface for configuring these variables. The theme settings pane is confusing enough as it is. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDTXLmgegMqdGlkasRAu7GAKC+hHORqdm/3fM7Rs4ihM4xNP0q+ACfWhaB likVj/cMk4hl5bDntx8eXH8= =3ks8 -----END PGP SIGNATURE-----
Whether they are hard coded or if they are set with a variable I'm stuck with one page size for the site. For example I could only view the logs with one page size, I couldn't view them 10 to a page in one view and 50 to a page in another view. This may seem like a small point but I could envision an administration use case where I may want to create some kind of a "dashboard" that shows a limited set of data, like last 20 log records, the top 10 pages visited, 10 comment record at a time. Viewing any of these items outside of this "dashboard" one would want to see the normal views with more data. On 10/12/05, Adrian Rossouw <adrian@bryght.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12 Oct 2005, at 9:09 PM, Gabor Hojtsy wrote:
It can be made into a theme setting though, to be changeable on the theme settings pane.
Or someone can write a small module with an interface for configuring these variables.
The theme settings pane is confusing enough as it is.
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin)
iD8DBQFDTXLmgegMqdGlkasRAu7GAKC+hHORqdm/3fM7Rs4ihM4xNP0q+ACfWhaB likVj/cMk4hl5bDntx8eXH8= =3ks8 -----END PGP SIGNATURE-----
You can set the variable however you need on a page by page basis: if ($_REQUEST['pager_style'] == 'large') { $conf['admin_pager_items'] = 500; } David Reed wrote:
Whether they are hard coded or if they are set with a variable I'm stuck with one page size for the site. For example I could only view the logs with one page size, I couldn't view them 10 to a page in one view and 50 to a page in another view.
This may seem like a small point but I could envision an administration use case where I may want to create some kind of a "dashboard" that shows a limited set of data, like last 20 log records, the top 10 pages visited, 10 comment record at a time. Viewing any of these items outside of this "dashboard" one would want to see the normal views with more data.
On 10/12/05, Adrian Rossouw <adrian@bryght.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12 Oct 2005, at 9:09 PM, Gabor Hojtsy wrote:
It can be made into a theme setting though, to be changeable on the theme settings pane.
Or someone can write a small module with an interface for configuring these variables.
The theme settings pane is confusing enough as it is.
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin)
iD8DBQFDTXLmgegMqdGlkasRAu7GAKC+hHORqdm/3fM7Rs4ihM4xNP0q+ACfWhaB likVj/cMk4hl5bDntx8eXH8= =3ks8 -----END PGP SIGNATURE-----
Thanks Moshe, yep, that would do it for me. So the consensus is a new "admin_page_size" variable with no UI interface? Correct? I guess the next question I have is that when I looked at the existing code of the 16 instances of admin type pages that I found they are not all using the same hard-coded page size. 6 were using 50 6 were using 30 1 was using 25 3 were using 20 So do we create multiple variables? By size range? By module? By ??? On 10/12/05, Moshe Weitzman <weitzman@tejasa.com> wrote:
You can set the variable however you need on a page by page basis:
if ($_REQUEST['pager_style'] == 'large') { $conf['admin_pager_items'] = 500; }
David Reed wrote:
Whether they are hard coded or if they are set with a variable I'm stuck with one page size for the site. For example I could only view the logs with one page size, I couldn't view them 10 to a page in one view and 50 to a page in another view.
This may seem like a small point but I could envision an administration use case where I may want to create some kind of a "dashboard" that shows a limited set of data, like last 20 log records, the top 10 pages visited, 10 comment record at a time. Viewing any of these items outside of this "dashboard" one would want to see the normal views with more data.
On 10/12/05, Adrian Rossouw <adrian@bryght.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12 Oct 2005, at 9:09 PM, Gabor Hojtsy wrote:
It can be made into a theme setting though, to be changeable on the theme settings pane.
Or someone can write a small module with an interface for configuring these variables.
The theme settings pane is confusing enough as it is.
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin)
iD8DBQFDTXLmgegMqdGlkasRAu7GAKC+hHORqdm/3fM7Rs4ihM4xNP0q+ACfWhaB likVj/cMk4hl5bDntx8eXH8= =3ks8 -----END PGP SIGNATURE-----
Thanks Moshe, yep, that would do it for me.
So the consensus is a new "admin_page_size" variable with no UI interface? Correct?
I guess the next question I have is that when I looked at the existing code of the 16 instances of admin type pages that I found they are not all using the same hard-coded page size.
6 were using 50 6 were using 30 1 was using 25 3 were using 20
So do we create multiple variables? By size range? By module? By ???
I would create admin_pager_long (50) and admin_pager_normal (30), and let the 25 and 20 long pages use the normal pager size. Goba
Patch provided for review at http://drupal.org/node/33809 On 10/12/05, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Thanks Moshe, yep, that would do it for me.
So the consensus is a new "admin_page_size" variable with no UI interface? Correct?
I guess the next question I have is that when I looked at the existing code of the 16 instances of admin type pages that I found they are not all using the same hard-coded page size.
6 were using 50 6 were using 30 1 was using 25 3 were using 20
So do we create multiple variables? By size range? By module? By ???
I would create admin_pager_long (50) and admin_pager_normal (30), and let the 25 and 20 long pages use the normal pager size.
Goba
On Wed, 12 Oct 2005, David Reed wrote:
Thanks Moshe, yep, that would do it for me.
So the consensus is a new "admin_page_size" variable with no UI interface? Correct?
The only problem with this approach is that we usually don't use it. I know of only one variable in core that has no admin interface. I personally like this approach, though. Cheers, Gerhard
Jose A. Reyero wrote:
I don't like hardcoded values at all, and I'd like *everything* to be configurable. The problem is if we make everything configurable, the admin interface would be unmanageable.
Proposed solution: Make all of these values configurable in the settings file, but not through the web pages. Ideally, we'd access all of these values throught the variable_get/variable_set interface, but then we'd need some array in the settings file to hold all of these values, and then the variable management functions to discriminate between the ones that have to be set into the database and the ones that are in the code.
The fun thing is that all this works right now (and worked before :) with Drupal. Look into the bottom of your settings.php (variable overrides). Goba
Gabor Hojtsy wrote:
Jose A. Reyero wrote:
I don't like hardcoded values at all, and I'd like *everything* to be configurable. The problem is if we make everything configurable, the admin interface would be unmanageable.
Proposed solution: Make all of these values configurable in the settings file, but not through the web pages. Ideally, we'd access all of these values throught the variable_get/variable_set interface, but then we'd need some array in the settings file to hold all of these values, and then the variable management functions to discriminate between the ones that have to be set into the database and the ones that are in the code.
The fun thing is that all this works right now (and worked before :) with Drupal. Look into the bottom of your settings.php (variable overrides).
Goba
Yes, you're right. So we just have to define the variables in settings.php and use them in the code through all Drupal :-) In addition to this, someone can make a module to configure this rarely changed values...
I compiled some stats for all core modules calling theme_pager. - there are 24 calls to theme_pager - 16 of them are admin type pages - none of the 16 admin page calls use any kind of override (all hard-coded) - of the 8 non-admin pages ---4 use the 'default_node_main' variable to override the page size ---1 uses the 'forum_per_page' variable ---1 uses a URL param (comment module) ---1 is hard-coded (tracker) A variable for admin pages would help but in my case I would like to show pages like logs in two differnt admin views (with different page size requirements) so I would need still need a way to override the variable setting. On 10/11/05, David Reed <dreed10@gmail.com> wrote:
I have a use to expose some of the admin type pages (logs, users etc) in a view with limited space available. I noticed that the page size is hard coded in all modules that use drupals paging mechanism. A quick glance reveals the following hard-coded pages sizes:
watchdog = 50 lines user = 50 lines statistics = 30 lines comment = 50 lines poll = 50 lines
I think it would be really usefull to provide a mechanism to override these hard-coded values. I would suggest something simple like apending a value to the url in the query string for page size. This value could be interogated by each module that calls theme_pager_link() to see if it should use it's hard-coded default or use an override.
I'm more than happy to provide some patches for this but I wanted to make sure I wasn't missing a far easier way to solve this issue.
Does anyone else see value in this? Is there a better way to do this other than patching the core modules?
participants (11)
-
Adrian Rossouw -
Bèr Kessels -
David Reed -
Gabor Hojtsy -
Gerhard Killesreiter -
Jose A. Reyero -
Karoly Negyesi -
Konstantin Käfer -
Moshe Weitzman -
Syscrusher -
Vernon Mauery