|
phpMyEdit - Viewing Bug Advanced Details |
[ Go Back ]
|
|
|
ID:
|
Category:
|
Severity:
|
Reproducibility:
|
Date Submitted:
|
Last Update:
|
|
217 |
core / field option |
feature |
always |
2004-04-09 20:26 |
2004-04-27 13:55 |
|
|
Reporter:
|
michal |
Platform:
|
|
|
|
Assigned To:
|
|
OS:
|
|
|
|
Priority:
|
normal |
Version:
|
|
|
|
Status:
|
feedback |
Product Version:
|
current from CVS |
|
|
Product Build:
|
|
Resolution:
|
open |
|
|
Projection:
|
none |
Duplicate ID:
|
|
|
|
ETA:
|
none |
|
|
|
Summary:
|
customized header |
|
Description:
|
current header is name of the field, which is clickable. This is sometime undiserable (eg when you have two columnc connected with CONCAT, like 'first_name' 'last_name', you want header to look like 'first' and 'last' name with first and last clickable to sort by first or last name).
similar situation is for filters. |
|
Steps To Reproduce:
|
|
|
Additional Information / Solution:
|
patch against current cvs.
configuration:
$opts['fdd']['col_name']['tmpl_header'] = '$first_name and $last_name name'; (first_name, last_name are col_names of some columns already defined in $opts['fdd']) |
|
Attached Files:
|
0000217-tmpl.header.diff.txt (11 KB) 1970-01-01 01:33 |
|
Bug Notes |
|
|
hbernard
|
|
2004-04-10 13:13
|
|
Well, at first sight, why not use two separate columns ? ;-)
That said, this means we need more globally an abstract layer, in order to list allowed sort fields.
I'm not sure about if your API is right, here. |
|
|
|
|
well i ran into this situation: first_name last_name table and half of entries have reaaaally long first_name and short last_name, and the other half have short first_name and looooong last_name. in two columns it looked ugly (too much white space).
the patch just moves a bunch of code (the one that creates href link for sorting) into a separate function and applies a kind of substituteVars function on tmpl_header string using that function as subst_ar. |
|
|
|
hbernard
|
|
2004-04-12 12:34
|
|
Yes, I undestand why you need this.
But, again, I dislike your API. Not the feature, simply the API.
More thoughts soon. |
|
|
|
hbernard
|
|
2004-04-16 15:07
|
|
Michal,
1. about a string with variables
first I disliked your API because this is yet another var substitution.
So I went with a basic and direct API :
'header' => Array('col1', 'col2')
But this will not allow to put custom separator ('and', '/', etc....). Separator would just be
So I don't know. Nepto and others pme hackers have to comments.
2. about the name of the field options.
Why not use directly existing 'sort' ?
basic use would be 'sort' => true,
extended use would be 'sort' => Array('col1', 'col2') (or '$col1 and $col2', with your style).
I dislike mixed type API, but maybe here it is possible. |
|
|
|
|
1. we could go with array('$col1', 'custom_separator', '$col2') where $something is a name of a field and each another string (not beginning with $) is just echoed. default separator is '' (so none)
2. sometimes it is handy to have separate headers for sorting and filtering. so 'sort' and 'filter' could be used.
is 'filter' option defined ? it should allow column in F mode, but not allow filtering. docs and core class suggest that not. should we define it ? |
|
|
|
hbernard
|
|
2004-04-18 13:24
|
|
2. OT. This has to go in another bug report.
1. I can't make a decision about this. Other hackers have to comment
1a) API style, issues are :
- Array() is possible, trouble is how to handle separator
- string is another possibility, maybe the best.
- another idea we didn't have.
1b) API name :
- have a new field's option : 'sort_header' or something like that.
- reuse 'sort' with mixed arguments, either boolean like today or something in 1a)
- another idea we didn't have.
Nepto and others, please comment. |
|
|
|
|
2. it's already in uploaded patch :)
my votes
1a - string
1b - sort |
|
|
|
|
2. it's already in uploaded patch :)
my votes
1a - string
1b - sort |
|