[Phpmyadmin-devel] RFE #637 Custom Field Handlers
Chirayu Chiripal
chirayu.chiripal at gmail.com
Fri Jul 4 22:12:39 CEST 2014
On Wed, Jul 2, 2014 at 8:57 PM, Chirayu Chiripal <chirayu.chiripal at gmail.com
> wrote:
> On Wed, Jul 2, 2014 at 6:35 PM, Marc Delisle <marc at infomarc.info> wrote:
>
>> Le 2014-07-02 08:50, Isaac Bennetch a écrit :
>> >
>> >
>> > On 7/2/14, 8:31 AM, Marc Delisle wrote:
>> >> Le 2014-07-01 09:26, Chirayu Chiripal a écrit :
>> >>>
>> >>>
>> >>>
>> >>> On Tue, Jul 1, 2014 at 6:43 PM, Marc Delisle <marc at infomarc.info
>> >>> <mailto: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>
>> >>> > <mailto: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>>
>> >>> > > <mailto: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.
>> >>
>> >> Fine with me, but please confirm with your mentor.
>> >
>> > It's fine with me as well. I wonder if we might easily provide a way to
>> > automatically update (for instance detect the missing columns and prompt
>> > the user to automatically upgrade to the new structure, or detect the
>> > .inc.php in pma__column_info and automatically replace the data in the
>> > column with .class.php), but I'm not immediately sure whether such check
>> > is really necessary. Such checks shouldn't require much overhead to
>> > test, but add complexity.
>> >
>> > Ideally, we could force the user to run once a script (such as
>> > upgrade.php) when first installing/upgrading, but I haven't yet thought
>> > of a good way to run it on first install and never again (mainly since
>> > we can't depend on being able to write to the phpMyAdmin Configuration
>> > Storage or file system in every installation).
>> >
>> > Any thoughts about this from the rest of the team?
>>
>> I had a look at we did for another similar case.
>>
>> In libraries/relation.lib.php, PMA_getRelationsParamDiagnostic(), we do
>> some verifications, then display this if needed: "Please see the
>> documentation on how to update your column_comments table."
>>
>> Have a look in doc/config.rst, searching for "to update your PRE-2.5.0",
>> to see the explanation for updating.
>>
>
> We can provide one SQL script to upgrade and I'll have a look how this
> PMA_getRelationsParamDiagnostic() works.
>
Please, review the work I have done so far:
https://github.com/D-storm/phpmyadmin/tree/FR-637. So that I can come to
know if I am missing something or not. Tasks to be done yet includes:
Mechanism to change input fields & One plugin to demonstrate/test this and
fix failing testcases.
>
>
>> --
>> 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/20140705/fa89c404/attachment.html>
More information about the Developers
mailing list