The concept of event-driven is broad. It can be on the client side or on the server side.
In WEB applications, client-side events are based on JS or plug-ins or JAVAAPPLET. Basically, if it is a plug-in or JAVAAPPLET, it does not belong to the category of HTML. In fact, the occasions where JS must be used are actually There are not many, at most they are basic operations such as FORM submission or link clicks, so talking about events is meaningless.
The real meaning of event-driven does not lie in visual programming, but in its concept, just like OO. Event-driven is actually an extension of OO, and its original prototype is the message mechanism. But the event driver encapsulates the message into a callable function, which is similar to the callback function in the API. You can define the execution content of these functions yourself. Visual programming separates these functions, defines parameters (mostly ready-made objects), and allows you to write your own code and use these parameters (actually, these objects) to do something.
Therefore, it is entirely possible for PHP to be event-driven, mainly due to the design of the framework. To make a so-called visual event driver such as VB, you must have a supporting integrated development environment, including a series of functions such as page design, event encoding, compilation and transcoding. In fact, event-driven ones like NET just encapsulate some commonly used WEB elements or controls, such as buttons, text boxes, etc., so that you can have a visual interface to design. After it is compiled, It's still text like this, just convert your event code into JS or server-side code. For PHP, the main reason is that the IDE is not rich enough and there is no pre-compilation mechanism, so the final code submitted is still the final PHP code, rather than a mixture of NET resource code and event code (usually an ASP document that conforms to the XML specification. Contains non-standard HTML code). Therefore, PHP is still unable to achieve the so-called event-driven programming in the narrow sense in everyone's mind, but in fact it is completely without problems.
If you are interested, you may wish to go to the official homepage of www.php.net to take a look at PRADO, an event-driven PHP framework written by a Chinese friend (Qiang Xue). This is still the best one that received high votes, and is highly recommended! Please refer to http://www.zend.com/php5/contest . After reading its source code, you will understand what PHP's event driver is. But I think that in this regard, because PHP has no pre-compilation mechanism and relies too much on OO (although the code is written in PHP5), this framework is a bit bulky, complicated to use, and not very scalable. However, the concepts are very good, and some of the ideas have solved problems that have puzzled me for many days. Let me briefly introduce this framework below.
The framework is written in ZDE and PHP5. It has detailed documentation, a very clear structure, and sufficient comments. The code is very easy to read, indicating that the author's coding level is very high. The author clearly stated that this framework refers to the concepts of ASP.NET and Borland Delphi.
This framework is very strong in verification (not that there are any modules such as verification login), very robust, and it is almost impossible to have any direct loopholes that can be penetrated from the outside. It introduces the concept of specification files. Limitation, it effectively solves the efficiency bottleneck in large-scale verification. The only problem with this verification method is that the production of the specification file itself is more laborious (of course, using tools is another matter). However, once it is done (the specification file itself With formats and specifications), the verification is naturally done by the framework without the need for human calls every time. Its events can also be defined in the specification file (I think this is not necessary). In fact, its specification file is somewhat similar to the FORM definition file in DELPHI or VB, but it is plain text written in XML. , rather than visualization. As for event-driven, the framework has a built-in set of basic event flows similar to NET. You can customize these events at different stages. In fact, to put it bluntly, it means redefining these OnXXX functions and using parameters in a given form. You can also You can add your own events. For example, when you define your own component, define the event functions and parameters that the component may have in the specification file. In the future, you can directly define these allowed functions when using the component - but I think this method is too complicated and requires a large number of XML files to be read and analyzed. Although it is very rigorous and safe, it is a bit excessive and does not fully utilize the flexibility of PHP itself. My idea is to use something similar to DELPHI By assigning function handles or using the features of C's callback function, you can define events at any time and anywhere while writing code, and still be able to clearly identify the event sender and type and have sufficient security guarantees without the need for machinery. It effectively forces each component to have only certain events, making code modification and expansion very convenient. Of course, when working on large projects, strict definitions are necessary, but even so, the framework's way of handling events is somewhat old-fashioned.
I think its template is a better idea. Its template is somewhat similar to the ASP file of NET before compilation (I am not familiar with ASP NET, but I understand some principles), but the way it works is A FORM file similar to DELPHI is a very good concept. The only drawback is that it is not very convenient to use a WYSIWYG general editor such as DW, because several mutually exclusive components can be combined in one template at the same time. together and decide which ones to display only during runtime.
When I look at the code of this framework, I still find that it has some very weak items. The most important one is the path problem. The scalability is very low. It should be more suitable for dedicated hosts. There is nothing you can do about some restricted hosts (directory restrictions or permission restrictions), and there are no corresponding reminder measures (and no related interface). It uses a cumbersome mechanism called assetService for the path of certain resources or files. The purpose is to determine the path of the file. The author himself also said that if this service is used, system consumption will increase significantly. In fact, this is borrowed from The concept of asset library in FLASH allows you to specify the path arbitrarily, but it must be re-verified every time, which is not worth the gain. My approach is to fix several main paths, and their subdirectories can be arbitrary, which comprehensively balances the contradiction between the two. Due to the lack of consideration of path issues, the framework is powerless with language settings, personalized templates, etc. If you want to translate a project, it is conceivable that the procedures are complicated, the workload is huge, and it is easy to make mistakes. This is the single most serious problem with the framework.
Generally speaking, the concept, design, and code of this framework are absolutely first-rate. Of course, there are always shortcomings, but this does not prevent us from studying and learning it at all. I have not read all of its code, only a few core programs and some instructions, but I can clearly see its structure and ideas. I deeply admire the author, but I also deeply regret the shortcomings. No matter what, it is definitely a good work for studying PHP event-driven code. Therefore highly recommended!