[Phpmyadmin-devel] RFE #637 Custom Field Handlers

[Chirayu Chiripal]

On Tue, Jul 1, 2014 at 6:43 PM, Marc Delisle <marc at infomarc.info> wrote:

> Le 2014-07-01 08:43, Chirayu Chiripal a écrit :
> >
> >
> >
> > On Thu, Jun 26, 2014 at 8:30 PM, Isaac Bennetch <bennetch at gmail.com
> > <mailto:bennetch at gmail.com>> wrote:
> >
> >     Hi,
> >
> >     Marc has already provided excellent answers to most of this, but see
> >     below:
> >
> >     On 6/26/14 6:25 AM, Chirayu Chiripal wrote:
> >     > On Thu, Jun 26, 2014 at 3:31 PM, Marc Delisle <marc at infomarc.info
> >     <mailto:marc at infomarc.info>
> >     > <mailto:marc at infomarc.info <mailto:marc at infomarc.info>>> wrote:
> >     >
> >     >     Le 2014-06-25 06:23, Chirayu Chiripal a écrit :
> >     >     > Hi,
> >     >     > Feature Request Link:
> >     >     > http://sourceforge.net/p/phpmyadmin/feature-requests/637/
> >     >     >
> >     >     > I am bit confused that what does this RFE is all about. Here
> >     is my
> >     >     doubt:
> >     >     >
> >     >     > 1] Does this feature requests says that if a field has a
> >     "prepend"
> >     >     input
> >     >     > transformation plugin with prepend text as "phpMyAdmin "
> then on
> >     >     insert
> >     >     > page if someone enters into this field "Bringing MySQL to
> >     the web" and
> >     >     > when a row is inserted then it should insert "phpMyAdmin
> >     Bringing
> >     >     MySQL
> >     >     > to the web" into the database.
> >     >     >
> >     >     > OR it requires something else?
> >     >
> >     >     Hi Chirayu,
> >     >     the example you mention is correct, but this feature request
> >     is much
> >     >     more than that. Look at the comment from Garvin in the RFE.
> >     >
> >     >     In reality, we don't have to code a credit card validation,
> >     for example;
> >     >     we just have to provide the mechanism by which someone can
> >     code their
> >     >     own credit card validation and apply it to the input field.
> >     >
> >     >
> >     > In my proposal, I also gave an example of regex validation plugin
> i.e.
> >     > if some invalid data is inserted then that plugin can replace that
> >     > invalid data with some other value (which would be given in plugin
> >     > options) and if data is valid then it should go as it is. I am not
> >     sure
> >     > about canceling the insert with error message right now but it can
> be
> >     > done like by setting value for invalid data in plugin option as
> >     NULL for
> >     > not null column which would automatically fail the insert or in the
> >     > plugin itself if validation fails then it could throw a error and
> stop
> >     > the execution of the script itself or we can have a boolean & error
> >     > variable in transformation plugin which would be checked before
> >     > insert/update and take actions likewise.
> >
> >     I think rather than waiting until submission and trying to make the
> >     INSERT fail, we should do any validation client side (through
> JavaScript
> >     so when the field loses focus, we validate and display a
> non-intrusive
> >     message explaining that it's invalid). Does this help?
> >
> >
> > I recently noticed that in "transformation" column of "pma__column_info"
> > table the name of transformation is stored something like this:
> > "image_jpeg__inline.inc.php" rather than "image_jpeg__inline.class.php"
> > i.e. extension ".class.php" is replaced with ".inc.php" while storing
> > and it is reversed while fetching. Is there any particular reason for
> > doing this?
>
> Yes, the reason is backward compatibility, but maybe it's time to do a
> radical move about this.
>
> In pma__column _info, the transformation column contains a string ending
> with .inc.php which, in older versions, matched the file name.
>
> It would be cleaner to invent some code that describes each
> transformation, but then all users would have to redefine their
> transformations, unless we provide them with some .sql file to run, that
> would do the conversion.
>
> If we do a conversion, it would mean that a pmadb would not be backward
> compatible with older phpMyAdmin versions.
>

Well, to separate the input & output transformations I would be moving
current transformation plugins into a new output sub-directory (as
mentioned in my blog), which would also break the backward compatibility.
Also as 2 new columns are being added to pma__column_info which would also
require users to upgrade their tables for transformations to work. So, I
think its time to remove that backward compatibilty hack.


>
> --
> Marc Delisle | phpMyAdmin
>
>
-- 
Regards,
Chirayu Chiripal
phpMyAdmin Intern - Google Summer of Code 2014
https://chirayuchiripal.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20140701/cf3206ec/attachment.html>