3 Jun
2009
3 Jun
'09
4:50 p.m.
Michal Čihař a écrit :
Hi
Dne Wed, 03 Jun 2009 08:43:02 -0400
Marc Delisle <marc(a)infomarc.info> napsal(a):
But... I don't like the idea of having to configure this for each column
(unless you have something else in mind). Well in some situations, per
column could make sense but not generally.
I think that transformations require the PMADB
mechanism?
Yes.
so more users would not have access to them by
default.
Yes, but we can hardly do something about it. But we're anyway going to
this direction (per user configuration).
Also, I would not be in favor
of having more than one such editor integrated.
Do you have other "transformations" in mind for this case? Note that
currently, with the display options (in browse mode), user has a certain
latitude for display.
After quick look into our feature tracker, we could offer at least
following editors:
- input
- textarea
- wysiwig
- textarea with deserialized data [1]
- textarea with hexadecimal data [2]
[1]:https://sourceforge.net/tracker/?func=detail&aid=1615116&group_i…
[2]:https://sourceforge.net/tracker/?func=detail&aid=1611770&group_i…
There would be definitely more options and configuring this per whole
phpMyAdmin installation does not make sense. Also, transformations imply some API we have to
prepare, with the idea
of attracting developers; so I wonder if we can have an API generic
enough in this case. It probably depends on what other transformations
would be supported.
The API can be based on our current transformations - the function
which will display edit form can get same parameters, the function for
fetching updated data would get current row of form. I definitely miss
something here, but I don't see why it should be complex.