DVelum - PHP + ExtJS4 Development Platform Version 0.9 Release

    The main goal of the project is to create a convenient RAD platform for developing web applications, database management interfaces, CRM systems, workstations. The platform functionality automates the routine development processes to the maximum, freeing up space for creative self-realization.

    Last year we introduced you to the DVelum platform in the publication “DVelum - a PHP + ExtJS4 development platform” .

    At that time, the platform was quite crude (beta release), after the publication received a lot of useful tips and reviews. A lot of the proposed has been implemented and fixed, I would like to introduce you to what has been done during this time. The project got stronger, acquired a more harmonious look, included a sufficient set of tools for everyday development.

    A detailed list of changes and new features can be found on the project website http://dvelum.ru/timeline.html

    Interesting and significant innovations

    Significantly increased platform performance. Introduced "lazy" loading of dictionaries, configurations, localizations. Optimized and revised system architecture. Many third-party components are replaced by their own lighter implementations. Improved information content of error messages, additional logs.

    Autoloader

    The Autoloader class is now compatible with the PSR-0 standard.

    Interface Designer Updated

    The fundamental part of the platform, the interface designer, has undergone significant changes and improvements. Support for events has been added, the ability to assign handlers has been implemented, the list and types of received parameters are highlighted. Implemented the ability to connect nested projects. Thus, in the interface designer, you can create your own components that will be included in other projects. The list of ready-made components and auxiliary interfaces for filling properties is expanded, for example:








    • icon selector
    • Related Items Grid (component for editing links to a list of objects)
    • component for field object reference
    • component for the field link to the list of objects


    Tree.Panel, storage filters and more.

    AJAX request url patterns

    To improve the portability of ready-made solutions, AJAX request url templates have been introduced; now the interface is not tied to a specific file structure, administrative panel address, attachment depth, or localization.

    Improved code generator

    The code auto-generator has been improved, now the editors of all properties of objects, including links to objects, lists of objects and library items are automatically generated. Everything that is necessary for editing a record will be created automatically (interface project, controller, javascript). This greatly simplifies the work and reduces the threshold of entry.

    CSRF attack protection

    An automated system for protecting the administrative panel from CSRF attacks is integrated, which is very important for projects with interfaces on ExtJS. Now there is no need to think about this kind of vulnerability and add hidden token fields to forms, the system independently creates tokens and necessary Ajax request headers.

    Improved ORM and models.

    Now it is possible to use foreign keys, connecting individual ORM objects to various remote databases. The system works stably in strict mode, and if possible, uses transactions.

    Added ORM data editor with integrated editing components (development mode). Now the database can be filled with test data before starting to create an interface. At any time, it’s easy to look at and adjust the value of the properties of ORM objects.


    Many additional details simplifying the life of the developer

    Plugins

    One of the problems of development based on frameworks is the distribution of ready-made modules. If library classes are easy to transfer by copying, then files of finite functionalities are often “blurred” across the file system (controllers, templates, models, etc. are scattered in different folders).

    The platform now includes a plug-in mechanism that allows you to store third-party solutions in a separate folder, but work with files as they are in the main directory of the application (still experimental).

    A separate interface allows you to connect / disconnect modules (possibly, loading, installing / uninstalling, the application directory will be implemented later). Access rights to third-party modules are transparently distributed. Class files, settings, interface designer projects become “native” for the system (they are added to autoload, displayed in various system lists, and are available for routing).

    New HTML5 Multi-Loader

    We abandoned Uploadify’s flash multi-loader in favor of our own solution based on html5 + js, now previews of images are available before sending files to the server, the bootloader API is more flexible.




    Asked - we answer
    • Why aren't you using PSR-1,2 Coding Style?
      Initially, we tried to adhere to the Zend Framework 1.x style, which appeared long before the PSR-1,2 recommendations. Since the code base is quite extensive, there is no way to rewrite it at a time for a new style, just to say that we use the popular code format (most likely this will be done in future versions when there is free time).
    • Is DI used?
      Many hardcode parts are rewritten using dependency injection (via setters). The container for Dependency Injection is not used due to the complexity of processing a large amount of code, and the use of the container will inevitably lead to loss of performance and complicate the logic of the code generator and interface designer, so at this stage it was decided not to implement it. (For example, the lack of a DI container does not make YII a bad decision)
    • Why no namespaces?
      Namespaces are not used in the core of the platform, but can be applied in final solutions. Embedding namespaces in the kernel will inevitably affect the compatibility of ready-made applications. Most likely, they will be introduced later, presumably in a sparing / alternative mode to maintain compatibility with ready-made applications.
    • Configuration in arrays?
      Someone may say that PHP arrays are a bad tone for storing configurations, and even provide links to interesting articles that analyze this topic. Yes, most likely it is. Our system uses configuration files based on php arrays, but the vast majority of them are edited using visual interfaces, so this fact should not be very confusing. It is worth treating this not as the best, but as the most optimal solution to a specific problem. According to the test results, it turned out that caching platform configuration files using the opcode cache is much more efficient than memcached storage. In addition, you can use additional configurations in the format in which you are used to working.
    • API documentation API
      documentation does not fully cover the platform code; on the other hand, we tried to describe most of the possibilities using examples of various functionalities and solutions to frequently arising tasks. We replenish and translate sections of the documentation as far as possible.
    • Why the requirement of DocumentRoot?
      This requirement is related to the implementation features of the interface designer.
      For some users this is a problem. Now, with the advent of url patterns for AJAX requests, we have implemented the necessary base for introducing the ability to install into subdirectories (it will probably be implemented soon).
    • Why platform files in DocumentRoot
      Part of the file structure of the platform is easy to move outside the host, for this you need to correct the paths in the configuration file. Such a “default” file arrangement simplifies the life of beginners, reduces the necessary number of gestures for the first acquaintance with the platform.
    • Is Composer supported?
      It would be great to implement support, but so far unlikely.
    • Is there a GIT project repository?
      Are planning.
    • Is there native support for other DBMSs?
      The kernel of the platform requires MySQL, but this does not interfere with using connections to other DBMSs from your application, it is also possible to manually switch individual models to other adapters (perhaps in the distant future there will be support for other DBMSs at the kernel level).


    The platform is far from ideal, but we spend most of our free time to make it better, trying to program on business, not for the sake of programming as such.

    Comparative Performance Tests

    Following the tradition, we present you the system performance tests.
    Senseless popular synthetic performance test “Hello World”: More serious tests that provide at least some idea of ​​the system’s performance: “Blog”, “Portal Home”, “List of nested comments” (300 elements of the tree structure): Special thanks to all who participated in the development and testing of the platform, as well as the participants in the discussions on the forum - for their support and interest. We are open to constructive criticism, glad to hear suggestions and suggestions. We hope that the platform will be an interesting and useful solution for you. The project team











    Also popular now: