One php script to bind them all :)

One php script to bind them all :)

jguerrejguerre Posts: 4Questions: 2Answers: 0
edited July 2016 in Free community support

Hi All!

Currently evaluating the usage for datatables / editor for internal backoffice osCommerce interface (bootstrap 3.2).

AFAIR, Editor creates all necessary scripts for each datatable needed, but our current hand-made (and many other) implementations define JUST ONE php crud interface for all needed db connections, just using table/fields/action parameters, and all necessary transformation functions, so it's quite convenient, automatically handling type casting/rendering by fetching table schema.

Is there any EASY way to achieve something similar with Datatables / Editor (i.e., JUST ONE server side script so serve all jsons and act on all CRUD operations, no matter what table/field is involved) for a basic interface? (dialog-based CRUD operations on standard numeric / text fields).

Thank you very much in advance for your time and links ;)

This question has an accepted answers - jump to answer

Answers

  • allanallan Posts: 62,301Questions: 1Answers: 10,216 Site admin
    Answer ✓

    Editor creates all necessary scripts for each datatable needed

    I don't quite understand this point I'm afraid. In the Editor examples there is a single script for each data type and that script will handle the CRUD operations for that table.

    You could have a single script that will handle any table just by having an if statement in it and switching between the different table definitions. You would need to send a GET parameter (or POST if you prefer) to indicate which table is being edited or data retrieved from.

    Allan

  • jguerrejguerre Posts: 4Questions: 2Answers: 0
    edited July 2016

    Yes it would do, but instead of having to create a huge if (case) with a name for each table and fields, and mantain it for every new table to be edited, wouldn't it just be easier to have just one script that queries the database schema of the $table parameter (as easy as "SHOW COLUMS FROM $table"), sets the corresponding Field::inst (if you wish, also depending on the $fields parameters on the GET request), and you're done?

    It seems that 20-25 lines of code would do it, and would hugely simplify first time users (even advanced ones). Just drop one php on the server and you're good to go :smile:

    For instance, in the generated PHP:

    Editor::inst( $db, 'foo', 'id' )
    ->fields(
    Field::inst( 'one' ),
    Field::inst( 'two' ),
    Field::inst( 'three' )
    )
    ->process( $_POST )
    ->json();

    Can something like this be done:

    $table=$_GET['table'];
    $fields=explode(',',$_GET['fields']);
    $query=mysql_dbquery("SHOW COLUMNS FROM $table WHERE Fields in (" . implode("','",$fields) . ")");
    while ($iter=mysql_fetch_assoc($query)) $field_instances[]=Field::inst( $iter['Field'] );

    Editor::inst( $db, $_GET['table'], $_GET['key'] )->fields($field_instances->process( $_POST )->json();

    And in the ajax parameter of the editor just call "universal.php?table=foo&key=id&fields=one,two,three" ?

  • allanallan Posts: 62,301Questions: 1Answers: 10,216 Site admin

    I see what you mean. Yes absolutely you could do that. The Editor examples don't show that, but there is no reason why you couldn't store the table definition in the database and then construct the Editor instance based on that.

    Allan

  • jguerrejguerre Posts: 4Questions: 2Answers: 0

    Hi Allan!

    Great then (thanks for the answer :), but what I meant is not storing the database definition in the database. It IS already in the database (in EVERY database), all you have to do is retrieve it with just one more query, based on the $table parameter, right?

    That piece of code (or similar) should work for any database and any table in the world, and it's just 4 lines longer that the base php generated by the editor that only works for one table at a time :smile:

    Same goes for the Javascript that instantiates the editor: you can just pass a fields array parameter. It can be written much shorter and with much more functionality than the actual examples (took me about 4 hours to reach to this point, and you were really close to loosing a customer based on the "extreme" simplicity of the generator code).

    Only thing that saved you was that there is no other CRUD looking just as good, but ajaxcrud was a really appealing candidate until I realized how your answer could be easily extended to every data source.

    Thanks again for your time, and please consider enhancing "just a bit" your generator code. We're not talking here about end-users, we're talking about stressed developers choosing amongst thousands of google results for "ajax crud" :smile:

  • allanallan Posts: 62,301Questions: 1Answers: 10,216 Site admin

    Oh I see - so automatically build the table and editor based on the schema. Got it now :-).

    Yes, I've actually seen a couple of people do this. It is unlikely that Generator itself will take this approach (although never say never) since it is designed to be a quick start tool only), but I am working in a similar direction (hush hush... :wink:).

    Allan

This discussion has been closed.