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