[Phpmyadmin-devel] RFD: New feature, Interface implementation (not a feature request! :-)
Salutations!
I am planning to add a feature for my own sake to phpMyAdmin. The reason is, I have created an application for one of my customers and gave him phpMyAdmin-access on his database. For me this is a good solution because I down have to fiddle with a reduced backend, and he scores because I won't charge him for that. ;)
Well, but then one major problem occured to us: He is administrating data containing html-code (here: an image). He wants to see those images inside of phpMyAdmin or at least having a link in a row where he can click on.
Currently libarires/display_tbl.lib.php3 encodes all data with htmlspecialchars(). I want to let certain html-entities pass as such and be rendered by the browser. First I just wanted to hack the code away, bypassing the htmlspecialchars()-Function if a certain config-variable is set.
But I think this can be done with more grace, and may come to be integrated in upcoming phpMyAdmin-releases; if there is a need for, I would be gratefully willing to code the required snippets.
Until now I am not fully advanced regarding how I could put the feature inside the user interface. First on, I want the solution to be as flexible as possible. Best way would be, that a user could choose among a set of functions treating a table. So it would not only be possible to render HTML-Code, but maybe to transform certain characters to other ones. Maybe a function turning all ":-)" into smilie-GIFs.
I thought of extending the SQL-parser to support SQL-Comments which then turn on my celldata-reparsing. I then dropped this idea, because I think it is too hard to use for the novice user.
Currently I am thinking about the following implementations. I would really appreciate your feedback on this, and what you think of it:
1. Add another row below the header-row of the data. It should contain a checkbox and a pulldown for each header. So I can check each checkbox, if I want that field to be HTML-enabled, and choose a value in the pulldown- field, which function I want the field to be used with. I think of a set of predefined PHP-Functions, and the ability to insert 'plugins' in the config.inc.php3 file. Like, I add a "smilie_to_html" function, a "html_img" function, a "html_table" function and so on. This new row could either be shown all the time, or only made accessible by clicking on a link like "Enhance Display" or "Convert fields" or such.
Advantages: Full, flexible control over the desired fields. Customizable, which field I want to have converted. Maybe I only want one single row HTML-enabled, not all of them.
Dis-advantages: Many, many Variables to be propagated throughout the page. Maybe too much to fit in GET-Vars. Many checkboxes/pulldowns to render for the browser (slowdown)
2. Add a persistent table-property field. There I can define, much like the 'edit table properties' which fields I later want to be treated with certain functions.
Advantages: Clean integration without much variable-propagation hassle.
Dis-Advantages: We have to store this data somewhere, which is harder to user for the novice user because he has to create tables like the bookmark-table. Parsing would be a lot harder to do, because one has to take ALIAS-Rows into consideration. You can't do 'on-the-fly'-alteration of a single cell to be HTML-enabled.
3. Add a full-page alternative Display much like the current 'print view'. Call it 'html view' and parse every single data as HTML.
Advantages: Most easy to code
Dis-Advanteges: Ugly implementation, no customization.
4. Expand the SQL-language with phpMyAdmin-parseable comments. Like: SELECT field_img, field_href, field_plain FROM table /* pma_parse:field_img:html_img, pma_parse:field_href:html_href, pma_parse:field_plain:htmlspecialchars */
And then add a nice Interface to that like the "insert field-name" dropdown above the SQL Query-Textarea.
Advantages: Perfect way for a 'pro'-user. Easy to code, very flexible, no variable-propagation hassle.
Dis-Advantages: Hard to get for novice users to be usable, unless a good point-an-click editing system is etablished.
Maybe the last suggestions, if done properly, could be enhanced for all kind of native phpMyAdmin-functions. Even though I can't think of any other right now.
So...oppinions please? :-)
-- Bye, ...[ icq #21392242 | Garvin ...[ www.supergarv.de |
... *Wenn Du im Zweifel bist, hoere auf den Mann mit der blutigeren Waffe.*
Hi Garvin,
I think that this new feature would be welcome in phpMyAdmin and I would like to contribute also to it.
First a general opinion: suggestion 2 pleases me, it goes in the general direction of the pma db containing special settings. As for the novice user, well I think those new features are not targeted at novice users. But it's only a matter of cut&paste a table definition (or maybe someday we will have an automatic installer for those tables) and define a controluser, then populate the table with some interface.
I wonder if we need more than one transformation type for each field?
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.
And some will prefer to see the pic in a popup, others to see it in the same row to be able to read the other fields too.
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).
For HTML, do we really need more than one transformation type? Now we see the raw HTML, new mode would be to render HTML, need another mode?
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)?
Sorry for the lots of questions :)
Marc
Garvin Hicking wrote:
Salutations!
I am planning to add a feature for my own sake to phpMyAdmin. The reason is, I have created an application for one of my customers and gave him phpMyAdmin-access on his database. For me this is a good solution because I down have to fiddle with a reduced backend, and he scores because I won't charge him for that. ;)
Well, but then one major problem occured to us: He is administrating data containing html-code (here: an image). He wants to see those images inside of phpMyAdmin or at least having a link in a row where he can click on.
Currently libarires/display_tbl.lib.php3 encodes all data with htmlspecialchars(). I want to let certain html-entities pass as such and be rendered by the browser. First I just wanted to hack the code away, bypassing the htmlspecialchars()-Function if a certain config-variable is set.
But I think this can be done with more grace, and may come to be integrated in upcoming phpMyAdmin-releases; if there is a need for, I would be gratefully willing to code the required snippets.
Until now I am not fully advanced regarding how I could put the feature inside the user interface. First on, I want the solution to be as flexible as possible. Best way would be, that a user could choose among a set of functions treating a table. So it would not only be possible to render HTML-Code, but maybe to transform certain characters to other ones. Maybe a function turning all ":-)" into smilie-GIFs.
I thought of extending the SQL-parser to support SQL-Comments which then turn on my celldata-reparsing. I then dropped this idea, because I think it is too hard to use for the novice user.
Currently I am thinking about the following implementations. I would really appreciate your feedback on this, and what you think of it:
- Add another row below the header-row of the data. It should contain a
checkbox and a pulldown for each header. So I can check each checkbox, if I want that field to be HTML-enabled, and choose a value in the pulldown- field, which function I want the field to be used with. I think of a set of predefined PHP-Functions, and the ability to insert 'plugins' in the config.inc.php3 file. Like, I add a "smilie_to_html" function, a "html_img" function, a "html_table" function and so on. This new row could either be shown all the time, or only made accessible by clicking on a link like "Enhance Display" or "Convert fields" or such.
Advantages: Full, flexible control over the desired fields. Customizable, which field I want to have converted. Maybe I only want one single row HTML-enabled, not all of them.
Dis-advantages: Many, many Variables to be propagated throughout the page. Maybe too much to fit in GET-Vars. Many checkboxes/pulldowns to render for the browser (slowdown)
- Add a persistent table-property field. There I can define, much like
the 'edit table properties' which fields I later want to be treated with certain functions.
Advantages: Clean integration without much variable-propagation hassle.
Dis-Advantages: We have to store this data somewhere, which is harder to user for the novice user because he has to create tables like the bookmark-table. Parsing would be a lot harder to do, because one has to take ALIAS-Rows into consideration. You can't do 'on-the-fly'-alteration of a single cell to be HTML-enabled.
- Add a full-page alternative Display much like the current 'print view'.
Call it 'html view' and parse every single data as HTML.
Advantages: Most easy to code
Dis-Advanteges: Ugly implementation, no customization.
- Expand the SQL-language with phpMyAdmin-parseable comments. Like: SELECT field_img, field_href, field_plain FROM table /* pma_parse:field_img:html_img, pma_parse:field_href:html_href, pma_parse:field_plain:htmlspecialchars */
And then add a nice Interface to that like the "insert field-name" dropdown above the SQL Query-Textarea.
Advantages: Perfect way for a 'pro'-user. Easy to code, very flexible, no variable-propagation hassle.
Dis-Advantages: Hard to get for novice users to be usable, unless a good point-an-click editing system is etablished.
Maybe the last suggestions, if done properly, could be enhanced for all kind of native phpMyAdmin-functions. Even though I can't think of any other right now.
So...oppinions please? :-)
-- Bye, ...[ icq #21392242 | Garvin ...[ www.supergarv.de |
... *Wenn Du im Zweifel bist, hoere auf den Mann mit der blutigeren Waffe.*
This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
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.
Hi
Great to hear someone needs simmilar thing as me ;-). I thought about simmilar feature, but I haven't time to code it....
On Tuesday 28 January 2003 21:45, Garvin Hicking wrote: [...]
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?
You would just put <img src="get_image.php?blahblahblah"> and the other (or same called with some parameters) php script will just return image (with correct content type).
[...]
'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
I thing that this should be in php code, not in database, as when you would upgrade phpMyAdmin, you would have to change this database....
(Note: please read thru all of this before replying to parts of it...)
On Tue, Jan 28, 2003 at 09:45:46PM +0100, Garvin Hicking wrote:
First a general opinion: suggestion 2 pleases me, it goes in the general direction of the pma db containing special settings.
I concur with that, the PMAdb is where custom data should go.
I wonder if we need more than one transformation type for each field?
Definetly we need it.
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'm against having custom defined functions, but instead I propose a better layout.
In the existing system for column comments, we add a field for the mimetype of the data, as well as fields for transform choice and additional transform parameters. The last two are optional, in that as long as you have a mimetype for data, there is a sensible default transform applied (configued via the config file again).
Now say we have data types like text/plain, text/html, text/xml, image/jpeg, image/png etc.
Now add a directory: libraries/transforms/ Files take the name format of: (basetype)[_(subtype)][.(transform_name)].inc.php3 Note the important fact that we can have a general classes of: (basetype).inc.php3 (basetype).(subtype).inc.php3 For the data types I listed above, we have the following file that define helper functions for all of the transform if needed. text.inc.php3 text_plain.inc.php3 text_html.inc.php3 text_xml.inc.php3 image.inc.php3 image_jpeg.inc.php3 image_png.inc.php3
if the data type is image/png, then include all the source of image.inc.php3, image.*.inc.php3, image_png.inc.php3, image_png.*.inc.php3 in that order, to have a complete list of transforms possible for that piece of data.
For all image types, we have a general transform of: image.display.inc.php3
which can just display the image. For the most part this is as simple as sending the data with an extra HTTP header of the mime type (part of my choice of mime type for controlling transforms).
image.display_thumbnail.inc.php3 - displays just a 100x100 thumbnail of the image. possibly the size is customizable via the additional parameters, but we have sensible defaults for it already (provided via the config file).
If you wanted additional pre-processing, say to convert an image format that is not directly displayable (using XBM format as example), you would have 'image_x-xbitmap.display.inc.php3' that would convert it to something that could be displayed in the browser and send that. There could possibly be more image transforms through GD or anything that you wanted, via the additional tranform paramaters field.
The text ones could be like: text.none.inc.php3 - does no formatting at all text.string.inc.php3 - takes a parameter like '<img src="%" />' showing how to mangle the data for displaying it... text_html.simpleformat.inc.php3 - does the minimal HTML conversion as you suggested before.
[transform examples converted into ideas above] 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.
Adding a new transform should be as easy as putting a new file into that directory with the correct name, and possibly adding the transform identifier to an array somewhere.
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?
<img src="transform.php3?(select query for data)&transform=(transform id)" /> removes the need for temporary files by shoving the data from the DB to the user directly.
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).
text.fulltext.inc.php3 text.reduced.inc.php3 :-)
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?
Agreed. ONLY the view page should have the transforms applied, partially for the reason you supplied, but additionally because MANY of the tranforms are not reversible so display the data in the transformed format in the edit page is not sensible.
Sorry for the lots of questions :)
No way! Thanks for your valuable input. That's what my posting was for.
Ideas and code always welcome :-).
Regarding implementation, I think of the following approach (everything as a 'stream of consciousness', don't expect miracles ;-)
- 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':
I've added this in by adding those three fields to column comments, because this is an extension of what the data in that column is about.
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)
This has serious security ramifications, and is actually more of a pain to manage when PMA is upgraded. Instead we will have just many files of transforms along with an array somewhere with a list of transform identifiers.
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:
This is added in via the column pages, in that after they add a mime-type, they can choose from an applicable list of transforms and specify additional options as needed.
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.
My approach saves from this.
How is this solved in the 'relation'-Database?
The relation database has a further problem in that if you rename database/tables/columns things don't make link up anymore. It isn't solved in the relation database at the moment, but I've been toying with ideas on how it chould be solved.
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.
Since we already make calls for relation data about columns, there is minimal overhead involved here, only once per page/table call.
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.
Serious issues in this, the other reason I would go against this, is that if you combine it with issues of data-injection security holes, it would become possible to inject code like: `shutdown -p` into the PHP field (say overwriting one of the generic transforms for text), and then if your PHP is running as root under apache like many users not knowing better, when that transform is run your server shuts down or worse...
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 see no loss of customizing code, and it would actually become easier to manege. I don't get where you see the loss of complexity?
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. ;-)
Read up on XST attacks and data-injection attacks as well.
Hi Robin!
Thanks, your suggestions were very valuable to me. I think this is the way to be done. I will sit down the next weekend (where I'm on vacation, so a lot of free time) and walk through the code. If everything runs smoothly (which I suspect) we can talk about my implementation at the end of next week.
Are there any major changes I should wait to be done in the next days? I currently use 2.4.0-dev (latest CVS)...
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 see no loss of customizing code, and it would actually become easier to manege. I don't get where you see the loss of complexity?
The loss of complexity would be, that phpMyAdmin Users (in auth-mode other than 'superuser') don't usually have access to the phpMyAdmin-Codebase. So they can't create their own transformations. But I think the phpcode-in-database issue has been dropped of good reasons completely, so I don't waste my creativity on that any more. ;)
Regards, Garvin.
On Wed, Jan 29, 2003 at 09:28:05AM +0100, Garvin Hicking wrote:
Thanks, your suggestions were very valuable to me. I think this is the way to be done. I will sit down the next weekend (where I'm on vacation, so a lot of free time) and walk through the code. If everything runs smoothly (which I suspect) we can talk about my implementation at the end of next week.
Great to hear that!
Are there any major changes I should wait to be done in the next days? I currently use 2.4.0-dev (latest CVS)...
2.4.0 release was supposed to be coming up soon, in early Feburary, but I haven't heard anything more about it for a while. Rabus - how is your user privilege stuff going ?
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 see no loss of customizing code, and it would actually become easier to manege. I don't get where you see the loss of complexity?
The loss of complexity would be, that phpMyAdmin Users (in auth-mode other than 'superuser') don't usually have access to the phpMyAdmin-Codebase. So they can't create their own transformations.
I see that differently, the average user that is just using PMA is not capable of writing much PHP anyway. If they are using it in just a small installation, they they would have full access to it anyway, and otherwise, they just ask their admin to put a new script in.
But I think the phpcode-in-database issue has been dropped of good reasons completely, so I don't waste my creativity on that any more. ;)
I've got exams this next week, then I'm away from computer for the weekend, and the week after that I'll be coding again.
Hi Robin!
(BTW, using OutlookExpress I only see your messages as plaintext Attachments and can't easily quote to it. But well OE sucks anyways.)
I'll be waiting till this weekend for any other feedback to our proposed structure and/or release issues and then start to code.
I've got exams this next week, then I'm away from computer for the weekend, and the week after that I'll be coding again.
Good luck for your exams! :-)
Regards, Garvin
--------------------------------------------- Garvin Hicking / Mediengestalter Faktor E AG email: hicking@faktor-e.de | me@supergarv.de www.faktor-e.de | www.supergarv.de
Hi Marc!
Well, 2.4.0-rc1 is still planned for Feb 2nd, so no major changes will occur this week. Then maybe 2 weeks of feedback until 2.4.0-final.
Allright then. Are there any major features apart from mine planned for a next release? The privilege system will be put in 2.4.0, right?
I'm just looking for excuses why users should update from 2.4.0 to 2.4.1 three week later or so. :-)
Regards, Garvin
Garvin Hicking wrote:
Hi Marc!
Well, 2.4.0-rc1 is still planned for Feb 2nd, so no major changes will occur this week. Then maybe 2 weeks of feedback until 2.4.0-final.
Allright then. Are there any major features apart from mine planned for a next release? The privilege system will be put in 2.4.0, right?
Well, depends what can be called "major". The sub-pages that occurred in version 2.3.0 was something major, I think :)
There are no signs of major features coming soon, we are quite busy with bug fix, user support and minor features.
About the privilege system, it is unlikely that something in cvs now would not be in the release.
I'm just looking for excuses why users should update from 2.4.0 to 2.4.1 three week later or so. :-)
Our release cycle is at least 7 weeks, not 3 :)
However I suggest that the new features be introduced in small to medium chunks, to avoid looking like a major rewrite. This way we can still work as a team on the same scripts, fixing bugs during 2.4.1 development.
Regards, Garvin
Hi
I'm just looking for excuses why users should update from 2.4.0 to 2.4.1 three week later or so. :-)
Because they will have the latest version...isn't this most usual reason to update?
Anyway, if you will make your proposed changes, please try to also make implementing something like RFE #653201 (BLOB download/upload) as easy as possible. I just wanted to let you know about this as it is just another thing that should IMHO work within those changes you are going make. And don't thing that I request you to write it, but it would be nice ;-).
Michal Cihar wrote:
Hi
I'm just looking for excuses why users should update from 2.4.0 to 2.4.1 three week later or so. :-)
Because they will have the latest version...isn't this most usual reason to update?
Anyway, if you will make your proposed changes, please try to also make implementing something like RFE #653201 (BLOB download/upload) as easy as possible. I just wanted to let you know about this as it is just another thing that should IMHO work within those changes you are going make. And don't thing that I request you to write it, but it would be nice ;-).
Michal,
BLOB upload should go on the Edit page, no?
Marc
On Wednesday 29 January 2003 21:27, Marc Delisle wrote:
Michal Cihar wrote:
Anyway, if you will make your proposed changes, please try to also make implementing something like RFE #653201 (BLOB download/upload) as easy as possible. I just wanted to let you know about this as it is just another thing that should IMHO work within those changes you are going make. And don't thing that I request you to write it, but it would be nice ;-).
Michal,
BLOB upload should go on the Edit page, no?
Sure. Sorry, I forgot to mention, that I meant here only the download part ;-).
Hi Michal!
Because they will have the latest version...isn't this most usual reason to update?
Hm, as a bleeding-edge user of course. But I know of a lot phpMyAdmin- Installations using 2.2.xxx
Anyway, if you will make your proposed changes, please try to also make implementing something like RFE #653201 (BLOB download/upload) as easy as possible. I just wanted to let you know about this as it is just another thing that should IMHO work within those changes you are going make. And don't thing that I request you to write it, but it would be nice ;-).
Thanks for the reminder. Yes, I will work on a general BLOB-Wrapping script (but for DOWNLOAD only, as pointed out in a parallel posting), which should not only display inline-graphics display but should be able via the transformations to output any other file with usefull headers.
Hope everything goes as smoothly as I worked it on my imagination. :-)
I think for the first step column transformations will not work for aliases columns. Like when I define a 'image/jpeg'-Transformation on the field 'image' I will see the transformation with a query like 'SELECT image FROM table' but will not see it if I use 'SELECT image AS bild FROM table'. That means, the column name has to match a comment entry. Using 'SELECT image_new AS image' instead will transform the image using the 'image/jpeg'-Transformation.
I think this is the way I would expect the transformation to work.
Regards, Garvin. -- Bye, ...[ icq #21392242 | Garvin ...[ www.supergarv.de |
... *"Five days is not too long to wait for a gun." - B.Simpson*
On Wed, Jan 29, 2003 at 11:53:00PM +0100, Garvin Hicking wrote:
Because they will have the latest version...isn't this most usual reason to update?
Hm, as a bleeding-edge user of course. But I know of a lot phpMyAdmin- Installations using 2.2.xxx
Same here, I've had to use a few of the older ones myself on client projects anyway. It really won't hurt to only have your feature in 2.4.1 the way I see it, many sysadmins will avoid 2.4.0 because of the stigmata associated with point releases, and wait for 2.4.1 at the least.
Hope everything goes as smoothly as I worked it on my imagination. :-)
Heh, there are always some bumps along the way, the SQL parser I wrote last summer is twice the size I predicted it would be, mostly because of all the odd little corner cases that had to get covered.
I think for the first step column transformations will not work for aliases columns. Like when I define a 'image/jpeg'-Transformation on the field 'image' I will see the transformation with a query like 'SELECT image FROM table' but will not see it if I use 'SELECT image AS bild FROM table'. That means, the column name has to match a comment entry. Using 'SELECT image_new AS image' instead will transform the image using the 'image/jpeg'-Transformation.
Our SQL query analyzer system can tell you what columns are aliased and much much more, so this shouldn't be a problem.
I think the column name should not be used to define what type of transform is used, as that restricts the user a lot. Instead just base the transform off the specified mimetype.
Oh, and once you write up the code for putting the mime-type in, I'll contribute a little bit of code that can auto-detect what mime-type a data field should be if there is data in the field but no mime-type specified. It's just a little bit of code I have kicking around my personal archives that I wouldn't mind putting to better use.
Hi Robin!
Our SQL query analyzer system can tell you what columns are aliased and much much more, so this shouldn't be a problem.
I think the column name should not be used to define what type of transform is used, as that restricts the user a lot. Instead just base the transform off the specified mimetype.
Then I don't get the clue of how you want to add the mime-types. In your first mail I thought you want to use the column comments table for storing it. The column comments references the comments by the column name, currently like this:
db_name.table_name.column_name:comment
There I would just add new fields: mimetype, parameters.
On the browsepage I would use a function which gets all fields mimetype and parameters from the comments-database. In every field I would the check the mimetype of the column using an association by the column name.
Which means exactly, I have an array like this:
$transformation_map = array('id' => 'text/plain', 'image' => 'image/jpg_inline', 'image2' => 'image/jpg');
And after that, inside the loop for displaying the rows' values I query my array via $transformation_map[$pointer] -- if there is an entry, to the transformation stuff, otherwise use the standard htmlspecialchars()-Function.
What was your approach, could you please specify?
Oh, and once you write up the code for putting the mime-type in, I'll contribute a little bit of code that can auto-detect what mime-type a data field should be if there is data in the field but no mime-type specified. It's just a little bit of code I have kicking around my personal archives that I wouldn't mind putting to better use.
That'll be great. :-)
Regards, Garvin.
On Thu, Jan 30, 2003 at 12:15:00PM +0100, Garvin Hicking wrote:
I think the column name should not be used to define what type of transform is used, as that restricts the user a lot. Instead just base the transform off the specified mimetype.
Then I don't get the clue of how you want to add the mime-types. In your first mail I thought you want to use the column comments table for storing it. The column comments references the comments by the column name, currently like this:
db_name.table_name.column_name:comment
There I would just add new fields: mimetype, parameters.
You missed transformname, or whatever you want to call it, for when multiple transforms exist for the same data. (If you base this off the filename for the transform, it should be easy to manage...). The mime-type field should contain ONLY the offical mime-type values for portability reasons, no custom modifiying them.
On the browsepage I would use a function which gets all fields mimetype and parameters from the comments-database. In every field I would the check the mimetype of the column using an association by the column name.
Just SELECT the three data fields that you need from the columncomments table yes.
Which means exactly, I have an array like this: $transformation_map = array('id' => 'text/plain', 'image' => 'image/jpg_inline', 'image2' => 'image/jpg');
I had envisenged it more like this, but you are close enough anyway... $transformation_map = array( 'id' => array('mimetype'=>'text/plain','transform'=>'',parameters=>''), 'image' => array('mimetype'=>'image/jpg','transform'=>'inline',parameters=>'width=100,height=100'), 'image2' => array('mimetype'=>'image/jpg','transform'=>'',parameters=>''));
And after that, inside the loop for displaying the rows' values I query my array via $transformation_map[$pointer] -- if there is an entry, to the transformation stuff, otherwise use the standard htmlspecialchars()-Function.
(puesdo code) foreach($field of $data)... echo doTransform($row[$field],$transformation_map[$field]); I have it this way so that people can specify default transforms for all data in their database if they so desire...
What was your approach, could you please specify?
I think it was just a slight misunderstand, what you wrote in your previous email looked like you were basing it directly off the field names instead of using those as indexes into the tranformation mapping.
Oh, and once you write up the code for putting the mime-type in, I'll contribute a little bit of code that can auto-detect what mime-type a data field should be if there is data in the field but no mime-type specified. It's just a little bit of code I have kicking around my personal archives that I wouldn't mind putting to better use.
That'll be great. :-)
This is part of my reasoning behind wanting to stay with offical mime-types only in the one field.
Hi Robin!
Allright, now we speak the same language again. Thanks for your clarifications.
I will work on the right arrays-types to use and will keep your mime-types RFC-conform.
I'll be back. ;)
Regards, Garvin.
-----Original Message----- From: Garvin Hicking
I'm just looking for excuses why users should update from 2.4.0 to 2.4.1 three week later or so. :-)
Humm...,
We could build in some major bugs in 2.4.0 and fix them in 2.4.1 :o)
Alexander M. Turek alex@bugfixes.info
+-----------------------------+ | The phpMyAdmin Project | | http://www.phpmyadmin.net | | rabus@users.sourceforge.net | +-----------------------------+ | [bugfixes.info] | | http://www.bugfixes.info | | rabus@bugfixes.info | +-----------------------------+
On Thu, Jan 30, 2003 at 10:15:56AM +0100, Rabus wrote:
We could build in some major bugs in 2.4.0 and fix them in 2.4.1 :o)
Lets not follow Microsoft's brilliant example now...
On Thu, Jan 30, 2003 at 10:15:56AM +0100, Rabus wrote:
I'm just looking for excuses why users should update from 2.4.0 to 2.4.1 three week later or so. :-)
Humm..., We could build in some major bugs in 2.4.0 and fix them in 2.4.1 :o)
what about adding Palladium/TCPA support ? :-)
Regards, Olivier, back to the list :)
Salutations!
I today worked myself into the relation/comments database. On the way to getting the system to know I improved the following things:
* Print column comments in 'Browse' View (optionally, via $cfg-Variable) in the heading row (both vertical&horizontal mode - BTW, good I worked on my own code there, I think it's somehow getting more complex to work on)
* Enable the javascript 'setPointer'-Function to correctly mark rows in vertical display
I think the comment-feature needs some other work to be done. I'm volunteering to do the following, if that is okay with you:
* Display column comments in the main page 'tbl_properties_structure', either as MouseOver/Title or as an extra cell inside the whole table
* Display column comments in 'tbl_alter' and make it editable there
* When updating column comments, check for no-more existing columns and delete entries in this DB
* Make a link for cleaning up column comments - to delete every entry to which no corresponding db->table->column exists
I think this won't take too long. I'm just asking if anybody objects to my changes or if anybody else is working on that. My changes would affect quite a lot places, so I they won't get checked in for the current 2-4-0.
BTW, is there anything special I have to watch out for when providing diffs for the project? I have never worked (not just patched) on a CVS project I haven't had write-access to...
-- Bye, ...[ icq #21392242 | Garvin ...[ www.supergarv.de |
... *Compile, run, curse. Recompile, rerun, recurse.*
-
Garvin Hicking -
Garvin Hicking -
Marc Delisle -
Marc Delisle
-
me＠supergarv.de
-
Michal Cihar -
Olivier M. -
Rabus -
Robin Johnson