>> * 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
>> * 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@... to <a
> Again, you might get in trouble if "me@..." 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. :)