[Phpmyadmin-devel] RFD: New feature, Interface implementation (not a feature request! :-)

[Garvin Hicking]

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.