|
Bug Notes |
|
|
hbernard
|
|
2004-01-21 07:07
|
|
NB: this is a post 5.4 issue.
I made implementation in the #121 bugnotes (sqlw implementation).
Please note that 'sql|LFV' with current CVS is exactly as virtual field should work, but it has to be extended for other modes.
(virtuals fields can't be in UPDATE/INSERT/DELETE sql statements).
I plan to upload updated patch against current CVS this week.
API would be :
'virtual' => true,
OR maybe a new flag properties (like HRW) ? (But see #127 bugnotes for this)
Having a virtual key field will not be allowed (for now).
Hey, * pme hackers, what do you think about the above ? |
|
|
|
hbernard
|
|
2004-01-21 12:24
|
|
Reading the current code, I think there is something wrong :
Nepto, what are rationnales for this line :
function virtual($k) { return stristr($this->fdd[$k]['options'],'V') && $this->col_has_sql($k); }
didn't you mean ...['options'],'U'.....
then API would be to include 'U' in 'options' to make the field virtual ?
This V seems very strange to me.... |
|
|
|
|
i was thinking of something similar, like 'themes' (inspired by css)
for example theme 'date' would define proper datemask, phpw/sqlw, default value, options, ... (user defined in an external file (?) like in css) and pme would apply these settings to a column defined with theme 'date'.
the problem is whether to override or append so ['theme']['override'] and ['theme']['append'] (like ['cgi'])
'virtual' is like ['theme']['override'] removing AC from options.
but this is probably OT. separate feature request ?
back to your question: i would stick it into 'options'. user will have to define 'options' and removing AC from it is a lot easier than creating default and then removing AC. is this all that 'virtual' would make ? or some sorting/filtering on top of that ?
ad deleted: afaik, D mode is almost the same as V. just with an extra sql statment for deleting a row. |
|
|
|
hbernard
|
|
2004-01-21 14:20
|
|
please make OT comments in specifics bug report.
Especially at the very beginning of the thread, in order to not loose every body (me...) with it.
Back to the topic :
I think you didn't understand (my explanations were certainly not sufficient):
'virtual' is not for displaying/processing or not.
How will you make API difference between
1- a REAL field that you want to display in C mode but not in A mode
2- a computed field that you want to be displayed in C mode but not in A mode ?
With your solution, (2) will fail during savechange operation because the field don't exist in the database.
virtual flag is there to be sure you won't perform any insert/update operation regarding this field when displaying its value.
Do you understand what I mean ? Or is my english too bad ?
edited on: 2004-01-21 18:31 |
|
|
|
|
yes, you are certainly right, stupid me ...
so virtual means:
"don't ever try to insert or update this field (even if i tell you to do so)"
and
"don't ever try to fetch this field from db, except for when 'sql' set (?)"
will it be able to appear in add/change forms ?
api: will be hard in 'options' (already used are: V I R U(?) A L , so only T is left to use :-)
so i see 'virtual' => true as only left possibility |
|
|
|
hbernard
|
|
2004-01-21 18:20
|
|
well, there is an API confusing semantic about ACPFLDV flags.
They are mode's flag, and a mode is essentially a way to make difference between 'pages' (List, View, Delete, and so on)
virtual means
'don't ever try to insert or update this field because this field doesn't exist'
AND
'never try to directly fetch this field because it doesnt exists' (use 'sql' if exist, else use 'default' if exist, else return "")
[^^^ pme_row]
BUT
process/display as usual (if requested) this field, using optionnaly 'php' feature to compute its value,
[^^^ php_row]
Yes, it aims at being available too in add/change forms (especially change), (mainly ReadOnly)
API:
'U' can be a possibility, depending on other bug report issue.
My first draft was to have 'virtual' => true, because this is not a common feature.
Rethinking about this, maybe with 'php' feature, it could be useful to not make it ReadOnly, in order to allow you to insert/update a field using 2 or more 'virtual' field (dummy sample : a date, input would be 3 virtuals fields for year, month, day and the concatenation would be inserted with (hidden, but processed) 'php' feature.
edited on: 2004-01-21 18:33 |
|
|
|
|
I meant 'V' flag. This will be part of ['input'] field option. Password, hidden, read-only and other flags will be moved into ['input'] -- see my last commit.
Backward compatibility will be preserved at least in 5.4 release. |
|
|
|
hbernard
|
|
2004-01-22 06:52
|
|
[definitely Post 5.4 issue, please look at #121, which is maybe the last one to resolved before 5.4]
Hmmm,
Ah, with the commit, I understand it very much better ;-)
I agree with introduction of new 'input' option's field.
But I'm not sure this is the right place for 'virtual' thing (if we are calling virtual the same thing).
Your implementation (readonly and sql required) make sense, and it was in the same way in my very first patch (#121).
However, virtual is not a matter of input or not, it's just a matter of doing direct sql stuff with it or not.
I wrote a dummy sample 2 bugnotes above, another case of non readonly virtual field can be to let easily user to add a input box that he may use elsewhere after calling phpMyEdit. (hashing string that you don't want to store, for example, I can think about many samples like this)
Then, from an API point of view, Virtual should not be in 'input' stuff.
virtual -> 'true' is still a workable API.
Another thing is maybe to have a new 'store' (or something like) options.
storing, relative to a field can be made in 2 ways :
- by [I]nserting (Add/Copy)
- by [U]pdating (Change)
'store' => 'IU'; would be the default
'store' => ''; is equivalent to virtual |
|
|
|
|
I tried to switch an application from released 5.3 to CVS version.
It uses 'Calculated Expression' feature like:
$fdd['other']['name']='Col Header';
$fdd['other']['expression']='onHand-ordered';
where 'other' can be anything, but needs to be unique within the list of $fdd keys.
With CVS version I get the following error:
Unknown column 'PMEtable0.other' in 'field list'
Does it mean that it's no more possible to add extra virtual fields? Even with 'sql' and 'php' features? |
|
|
|
hbernard
|
|
2004-02-22 21:28
|
|
No, while this bug report will stay open, there will not be possible to add extra virtual fields.
(Except in list/view mode, you may use this trick :
$fdd['other']['name']='Col Header';
$fdd['other']['options|ACPDF'] = '';
$fdd['other']['options|LV'] = 'LV';
$fdd['other']['sql'] = <put your sql expression here>;
)
Please, Open a forum thread if you want more about this |
|
|
|
hbernard
|
|
2004-11-01 20:53
|
|
input => 'V' virtual feature has been in CVS since 6 months, at least ;-)
So this is an already resolved issue |
|
|
|
hbernard
|
|
2004-11-01 20:54
|
|
|
argh ! no, there is no documentation. |
|
|
|
hbernard
|
|
2010-08-30 08:45
|
|
|