Hi Rabus!
- A substring() transform (only return X bytes/chars of a field)
I am against this idea. A database administration application should always display the true content of the tables. Transformations should always be used to display the content in a clearer way - not for truncating it. I just don't like the idea of hiding the content partly from the user.
I don't really understand your point. It's not that the application hides something from the user which he doesn't know. He always has to enable the transform and is thus willing to only see part of a string. It's not that we don't have this feature yet with the fulltext-transform-button - in the transformation approach, the user would even have the ability to display X bytes/chars of the input, or even get the beginning X words and the ending X words. I'd like to have that, like for browsing DB-stored comments where I only quickly browse over comments to find what I look for.
- A datetime/timestamp to local dateformat transform
What do you mean by "local"? How do you want to detect a user's timezone? Setting the timezone by a function parameter does not make much sense in a multiuser environment.
The timezone is already drawn from the language file and transformed by PMA_localisedDate(). I'd like to use that function - my 'local' word was used for a "local dateformat" not the "local time"... Apart from that I like the idea to put an parameter to the transform to choose a +/- offset to a time.
Where do you see problems with a multiuser environment? You can define transforms for your own tables, mostly your adminstrate your own tables and why don't you want to put a transformation on a table used on a foreign server to transform the time into your format?
- A plugin to babelfish or something like that to translate
contents? Transform options would be "from"- and "to"-language
I'd rather leave out the "to" option and automatically use the selected interface language for this purpose :-)
Good idea. :)
Anyway, I don't like babelfish's word-by-word translations at all... :-p
Me neither, but there are certainly many users who don't understand english at all. Even those mostly wrong translations lets the user get the basic idea. I guess. ;)
- An E-Mail Link-o-fier. (transforms me@supergarv.de to <a
href="mailto:me@supergarv.de?subject=<option>">
Again, you might get in trouble if "me@supergarv.de" is the value of a foreign key field. Why do you want to limit this to email addresses? I'd rather extend this to all kinds of URIs.
I think it'd be easier for users, if they don't have that global functions and have to adapt them with custom options, but to provide ready-to-user transform functions.
Concerning foreign fields: I haven't check out whether transforms or foreign field descriptions are privileged in display. I guess when a relation is set, that overrides any transform. At least I think, that would be the way to go. In any case, a relation-link PLUS a transform on that key is a problem.
- A plugin to search for a word in a field in google/google
groups/google images
Again, I won't restrict this feature to Google only...
It will be hard to create a function ready to use for any searchpage because of the different GET/POST options. The user would be troubled to figure that out by himself, if we don't provide defaults.
What a bout a set of pretty-printers for HTML, XML, CSS, (My)SQL, PHP, C (++ / #), Java, Perl, Python, Pascal, etc.?
Nice thing to have, sure. :)
Regards, Garvin.