|
Viewing Bug Advanced Details |
[ Jump to Bugnotes ]
[ Bug History ]
[ Print ]
|
|
ID |
Category |
Severity |
Reproducibility |
Date Submitted |
Last Update |
|
0000223 |
core / field option |
major |
always |
2004-04-12 22:51 |
2004-04-18 19:09 |
|
|
|
Reporter |
nepto |
View Status |
public |
|
|
Assigned To |
|
|
Priority |
normal |
Resolution |
open |
Platform |
|
|
Status |
feedback |
Duplicate ID |
|
OS |
|
|
Projection |
none |
|
Version |
|
|
ETA |
none |
|
Product Version |
current from CVS |
|
|
Product Build |
1.132 |
|
|
Votes |
1 |
|
|
|
Summary |
['options'] / ['select'] / ['input'] issues |
|
Description |
I would like to start discussion and solve following topic.
It is related to ['options'], ['select'] and ['input'] field options.
My thoughts:
1. ['options'] should handle only permissions
2. thus 'HWR' flags are not appropriate for this
3. now 'HRW' can be defined also in new ['input'] option
4. there is also ['select'] setting filtering page inputs
5. ['select'] and ['input'] can by possibly merged together
6. with usage of options variability we can properly handle everything
7. if OK, newly introduced option ['input'] will be discarded and documentation rewritten (no problem, backward compatibility with ['options'] for 'HWR' will be preserved)
I'm looking forward for notes on this from phpMyEdit gurus. ;-)
|
|
Steps To Reproduce |
N/A |
|
Additional Information / Solution |
Described in "Description" field. |
|
Attached Files |
|
|
|
|
Bug Notes |
hbernard
2004-04-13 12:19
|
1, 2, 3, 5 : YES
4. there is also ['select'] setting filtering page inputs
YEP, and
- that's confusing
- this is an 'half implemented' feature (only valid in filter mode, it seems)
6. with usage of options variability we can properly handle everything
YES, but users need some good samples to know about it.
7. if OK, newly introduced option ['input'] will be discarded and documentation rewritten (no problem, backward compatibility with ['options'] for 'HWR' will be preserved)
NO. I suggest the reverse.
'select' should be deprecated.
'input' should have precedence on 'select', so BC is OK but new consistent behavior is possible.
See the bug #218 (foreign table) for why I think we should do it this way. |
|
|
nepto
2004-04-14 19:51
|
So if I understand this correctly:
* I suggest to group ['select'] and ['input'] into ['select'].
* You suggest to group ['select'] and ['input'] into ['input'].
But we accord on the everything else in this issue, right?
I have no problem with ['input'], seems to be more appropriate name as ['select']. |
|
|
hbernard
2004-04-14 21:12
|
You properly summarize our opinions ;-)
'select' is today half-API, and I will be happy to have 'input' (though I will have to correct many pages before upgrading to current CVS :-) |
|
|
hbernard
2004-04-17 12:25
|
Argh ! Please wait before moving to above API !
I went on toughts below when I was poking in internals of PME for resolving bug #169
http://platon.sk/projects/bug_view_advanced_page.php?f_bug_id=169
-------
-A- Options variability make a 'input' only API very usable for 'D' and 'T'.
'T' and 'D' can be strictly related to _input_ method.
I mean, it can make sense to have a 'T' input for a joined field
(like in http://platon.sk/projects/bug_view_advanced_page.php?f_bug_id=218)
Or you may have a 'D' in the filter view for quite any field.
-B- BUT, 'M' is something different :
Say you have a 'M' field (with values2 or table) :
values2 => Array(23 => 'foo1', 12 => 'foo2', 10 => 'foo3'......)
values stored in database are like this : "23,12"
This works OK if 'M' is set for all mode.
Now, say you want to have a 'T' entry field for allowing wildcard search.
(or to avoid a 4 rows widget in the filter view).
You will set :
'input|F' => 'T',
'input|ACPDVL' => 'M',
It will broke you display.
in filter mode, 'M' is not set.
Then strings like "23,12" are not translated into "foo1,foo2".
To summarize :
'D' can be use only for input because if 'values*', join will be performed.
'M' is not only for input, it is required for output.
=> 'M' and 'D' are not orthogonal API.
-C- Way we can go :
1- previous agreement on 'select' into 'input' and stick with broken behavior :
Users have to use M everywhere or no where ()
2- have another new options 'output'
Which will be used in CellDisplay.
With only 'M' for now. Maybe we will have other API in the future.
3- use distinct API for the filter selection and filter display.
This mean, keep both : 'select' AND 'input'
In my sample above, we should write :
'input' => 'M',
'select' => 'T' //(apply only in the filters input widgets) - same as 'select|F' => 'T'
1 is broken but easy and BC
2 make sense but not BC and is a poor API.
3 may be confusing but is BC and make sense for a different reason than 2
My vote is for 3.
Dear PME masters, please tell me
- if I miss something
- if you understand the issue here
- what do you think of this issue.
IMHO, it is necessary to have a decision on this before going to resolve #169 & #218. |
|
|
michal
2004-04-18 12:25
|
if i correctly understand, we are talking about three functions: gather_query_opts() and display_add_record()/display_change...() and F mode in list_table(). one is for database manipulation and one is for button look (but they closely cooperate).
i've never used M option for input, so i cannot comment this.
i would also introduce 'checkbox' type (except for the display equivalent to D)
also i want to introduce custom filters (http://platon.sk/forum/projects/viewtopic.php?t=298).
i mention it here just to avoid some hard-coded code which would disallow this. if you think this features are useful, after solving this bug, it should/will be handled separately.
i agree with above agreement, so i would move 'select' into 'input'. |
|
|
hbernard
2004-04-18 13:23
|
michal, the key of my bugnote 2004-04-17 12:25 is that handling multiple values is not only related with 'input'.
What I'm saying is : with only one API ('select' or 'input'), it is not possible to customize filter widget. |
|
|
nepto
2004-04-18 16:44
|
hbernard: first of all, I believe I completelly understand a problem
Concerning to your "if I miss something": the problems is, that when using text field we want to search according to values, not keys. But what about using ['input|F'] = 'TM'? Flag 'T' will have precedence over 'M', but 'M' will be considered to create neccessary splits/fint_in_set queries. |
|
|
hbernard
2004-04-18 18:56
|
oh, thanks, you found it !
So, 'M' belong to the 'RWH' group (flags, not orthogonal API).
and if 'M' is set, then default "widget" is 'M', which is overriden by 'T' or 'M'.
OK for me (till I found another issue ;-) |
|
|
nepto
2004-04-18 19:09
|
I will suggest to leave this thing in our heads for some time, as you said, till we found another issue. |
|
|
|
|
Login
Registration
Slovak
