Hi Marc!
I think that this new feature would be welcome in phpMyAdmin and I would like to contribute also to it.
Great to hear that. :)
First a general opinion: suggestion 2 pleases me, it goes in the general direction of the pma db containing special settings.
I also thought this solution would best integrate with pma's general 'look&feel' as well as the general coding style. Even though I think it personally not the most flexible solution.
I wonder if we need more than one transformation type for each field?
I think so. As for me, I would best like to define my own PHP functions as possible transformation types. Generally they can be easy functions accepting a single input variable and all of them have to return a single value field, just like htmlentities().
I can think of the following functions:
- Plain HTML: Everything will be printed like it is in the DB. No escaping, besides stripslashes() or so
- Transform filename to IMG-Tag. If I have a field called 'thumbnail_img' I may want to convert the data '/htdocs/file.jpg' to the complete string '<img src="/htdocs/file.jpg" border="0">' and have that shown in the table view.
- Convert standard formatting Tabs: <b>, <i> and so on will be used to format a string. Tags like '<table>' will still be transformed to '<table>>'.
These are rather odd examples, and I can't think of any more. But I think it is easy to code and would otherwise if left out restrict the user in his creativity.
For example, I have a field with binary data, I want to specify that it is jpeg, but I might want to see the thumbnail or the full pic.
This would be quite a great feature, but I can't think of it's implementation. This can't be used as easy as a 'return string - function($buffer)' replacement, because you would have to call a wrapper script, which then has to create a temporary image file, insert this into a <img ...>-Tag and afterwards somhow garbage-collect and delete the temporary file. Or is there a possibility yet to compatibly render inline binary pictures in HTML?
Or have I somehow misunderstood your intention?
Other things: look at our big T, to show Full texts or reduced texts. It operates on the whole page and transforms the output. But often I would like to see the full text of only one cell. I agree with you to avoid a lot of pull-downs for each column header (or each cell).
This is a good example - the 'big T' could be replaced using my proposed functionality. We could provide a 'full text' function and a 'reduced text' function. The latter one would only output the first 50 chars (or words, if you prefer).
Also, should we display the new modes in table view (many records), or only when we go in Edit mode (where we clearly have only one record to deal with, and we can display more freely pull-downs for all rendering options)?
I think it best to only show the transformations in table view, for comparison reasons. I can't really think of why a user should want to have a transformation applied on a page, where he wants to edit data?
Sorry for the lots of questions :)
No way! Thanks for your valuable input. That's what my posting was for.
Regarding implementation, I think of the following approach (everything as a 'stream of consciousness', don't expect miracles ;-)
1. We need a new table, call it transformations using the structure:
TABLE 'transformations' - table - field - transformation_rule
'table' references to the table name where you want a transformation applied.
'field' references the fieldname for the transformation. (Examples following)
'transformation_rule' will contain an id-reference to the table 'transformation_rules':
TABLE 'transformation_rules' - transformation_rule [foreign key for 'transformations.transformation_rule - function_description - function_name - function_php
'transformation_rules' will be a auto_increment id.
'function_description' is what will be shown in a dropdown for selecting which transformation you will like to be applied to a field
'function_name' contains the non-conflicting php function name.
'function_php' contains the function, which can be eval'd(). (which raises security issues discussed later on)
Now we can display a simple HTML-form. Say we have a table 'dummy' containing the fields 'id', 'image', 'description', 'owner'. You will then have the form:
id (BIGINT unsigned) [transformation_pulldown] image (VARCHAR 255) [transformation_pulldown] description (TEXT) [transformation_pulldown] owner (BIGINT unsigned) [transformation_pulldown]
You will then have the transformation functions 'Shorten Text', 'HTML View', 'Plain', 'HTML Formatting Tags Only'. These are represented in the 'transformation_rules'-table. If I now insert the Rule 'Shorten Text' for the field 'description' I get an entry:
TABLE transformation_rules transformation_rule: 1 function_description: 'Shorten Text' function_name: 'pma_transform_shorten' function_php: '<?PHP function pma_transform_shorten($buffer) { return substr($buffer, 0, 255); }';
TABLE transformations table: dummy field: description transformation_rule: 1
You will then only have to clean up the transformations-database everytime a database is dropped or you change a transformation for a certain field. How is this solved in the 'relation'-Database?
Now you can go to the table view, where you can click on a Button similar to the 'big T' which then turns on transformations for every field found in the 'transformations'-table by querying the table for the current field name. Performancewise, this only has to be called once, I think.
Concerning security, I don't know how much of a risk it is to allow eval'uation of PHP-Code coming from a SQL-DB. On the one hand only the control- or superuser should be able to create transformations, so if he decides not to use our provided transformations and insteads implements his own, it's up to him whether he uses 'dangerous' php-code or not.
Another solution could be not to store the php-code in a database, but instead hard-code it into the script. This will lose additional complexity and abilities to customize code, but could be much safer.
I guess, I'm too much into babbling now, so I'll settle for the day and see if you can take any reason out of my writing. I'm open to any suggestion to make, I'm not yet fixed to a certain solution and reading of today's cross-site scripting attacks, a feature like this should be well thought-out. I guess. ;-)
Wishes, Garvin.