Filter the bazaar: write a simple and functional data filter

    image
    Someone will ask how the fuel pre-filters in the picture on the right relate to PHP \ IT as a whole? Very simple! The script, which will be discussed later, is very similar both in purpose and in functionality with these devices. Everyone understands that to implement a more or less universal filter of "ultrafine cleaning" (in our case, fulfilling any wishes of the user) in practice is not always a trivial task. However, to implement something really simple, but at the same time functional and quite applicable is quite real. What is this, in fact, for the "real" and what it is eaten with - we look under the cut.

    PHP is not my main occupation, but even more than once I already had to deal with a situation when you need to implement a simple and functional data filter to display certain data to the user. The simplest example is the admin panel in almost any system. Yes, it’s easier for a developer to go into some PMA and pull out any bun for himself, but, alas, most of them are not capable and should not.

    As a result, I wrote a script that, in most cases (depending on the type of data, which will be discussed below), it’s enough to submit only 2 data arrays of the form:

    $FIELDS = array (
    'active' => 'checkbox',
    'sex' => 'select',
    'type' => 'select',
    'hp' => 'int',
    'ep' => 'int',
    'id' => 'int',
    'bonus' => 'int',
    'description' => 'text'
    );

    $NAMEFIELDS = array (
    'active' => 'Активно',
    'sex' => 'Пол',
    'type' => 'Тип предмета',
    'description' => 'Описание',
    'hp' => 'Здоровье',
    'ep' => 'Энергия',
    'bonus' => 'Бонусы'
    );

    The first array is an enumeration of those fields and types that will be available for filtering, and the second is their symbolic display for the user interface. Currently, I have 4 types of processing implemented: single numeric (just a number), selection from a pre-prepared list (select type), text and Boolean (yes / no). Oddly enough, this turned out to be quite enough to screw the filter to virtually any table and search it. As I described above, for powerful, complex cross-table searches, other mechanisms are used that will be individual for each system.

    For the case if the field is a multiple choice (for example, gender is male \ female \ unisex), a third parameter of the following form is passed to the function:

    $additional = array (
    'sex' => $SEX,
    'type' => $TYPES
    );

    where $ SEX and $ TYPES are just arrays with a possible set of values.

    Someone will start shouting why reinvent the wheel in the presence of such-and-such frameworks, but:
    1. I do not like frameworks :) We will not argue why and why, this will go beyond the scope of this post, everything has its own purpose
    2. It’s always nice to do something less convenient for yourself.

    An example of the script can be found here (The same, but on OOP here ). When sending requests, it will simply return the generated request to you. As you can see, when you set the same criteria (for example, if you select the ID field several times), you can get an even more flexible data selection system.

    However, I do not pretend to discoveries, etc., I just share what I find convenient and useful for myself. It may be useful to someone else. The code, of course, is not sharpened for group development and does not even contain a drop of OOP, but at the same time it is understandable, readable, and if you need to fix something / make your own types \ grind "for yourself" - you do it, I think, with ease. Although, whoever needs to - probably has already done everything for a long time, who has not had time yet - will be able to spy errors in the author’s logic and not repeat them at home.

    To summarize, I note the

    pros
    1. Simply
    2. Universal enough
    3. Quite functional

    minuses
    1. In this example, a GET request is used, i.e. it is worth considering that the length of the URL should not exceed 2048 characters (no one bothers you using POST requests, it all depends on the task)
    2. Not able to do cross-table queries
    3. Written on the knee :)


    PS You can download all the source texts here , on the OOP here (I took out only 3 functions from the class, which can be attributed to public functions as soon as possible, therefore it is better for them to be outside it)
    PPS Only the one who does nothing is not mistaken .

    Also popular now: