Detailed analysis: PHP event-driven issues

Detailed analysis: for PHP event-driven issues, read the detailed analysis: for PHP event-driven issues, the concept of event-driven is generalized. It can be on the client or the server. In WEB applications, client events are based on JS, plug-ins, Java applets, and so on. Basically, if it is a plug-in or Java applet, "> <LINKhref =" http:

The concept of event-driven is generalized. It can be on the client or the server.

In WEB applications, client events are based on JS, plug-ins, JAVAAPPLET, and so on. Basically, if it is a plug-in or JAVAAPPLET, it is not in the HTML category, in fact, there are not many scenarios where JavaScript is really necessary. most of them are basic operations such as FORM submission or link clicking. Therefore, it is meaningless to talk about events.

The true significance of event-driven lies not in visual programming, but in its concept, just like OO. Event-driven is actually an extension of OO. its initial prototype is the message mechanism. However, event-driven messages are encapsulated into callable functions, which are similar to callback functions in Apis. you can define the execution content of these functions by yourself. Visual programming separates these functions and defines parameters (most of which are ready-made objects) so that you can write code and use these parameters (actually using these objects) to do something.

Therefore, it is entirely possible for PHP to be event-driven, mainly in the framework design. To make a visual event driver like VB, you must have an integrated development environment, including a series of functions such as page design, event encoding, and compilation and transcoding. In fact, event drivers like dot NET only encapsulate some commonly used WEB elements or controls, such as buttons and text boxes, let you have a visual interface to design it. after it is compiled, it is still a text like this, just to convert your event code to JS or server-side code. PHP is mainly because the IDE is not rich enough and there is no pre-compilation mechanism, so the final submitted code is the final PHP code, instead of a mixture of resource code and event code of vertex NET (generally an ASP document conforming to XML specifications, including non-standard HTML code ). Therefore, PHP cannot implement the so-called event-driven programming in the narrow sense, but it is completely OK.

If you are interested, go to the official homepage of www.php.net to check out a set of event-driven PHP framework PRADO written by a Chinese buddy (Qiang Xue). This is the best way to win the vote, highly recommended! For more information, see http://www.zend.com/php5/contest. after you export the source code, the PHP event driver returns a response. However, in my opinion, because PHP does not have a pre-compilation mechanism and is overly dependent on OO (although the code is written using PHP5), this framework is somewhat large and complex to use, scalability is not very good. However, the concept is very good, and some ideas solve the problem that puzzles me for many days. Let me briefly introduce this framework.

This framework is written in ZDE and PHP5. It has detailed documents, clear structures, complete comments, and easy-to-understand code. it indicates that the author's code writing level is very high. The author clearly stated that this framework references the concepts of ASP point NET and Borland Delphi.

This framework is very powerful in verification (not to mention the modules such as verification logon), and is very robust. it is almost impossible to launch any direct vulnerabilities, it introduces the concept of standardized files and effectively solves the efficiency bottleneck during a large number of verifications, this verification method has only one problem, that is, the preparation of the specification file itself is laborious (of course, it is another thing to use the tool). However, once it is done well (the specification file itself has a format and specification ), verification is done by the framework, without human calls each time. Its events can also be defined in the standard file (I think this is unnecessary). In fact, its standard file is a bit similar to the FORM definition file in DELPHI or VB, only plain text written in XML is not visualized. The event-driven framework has a set of basic event streams similar to Dot NET. you can customize these events at different stages. to put it bluntly, you just need to redefine these OnXXX functions, you can also add your own events with given parameters. for example, when you define your own components, define the possible event functions and parameters of the component in the standard file, you can directly define these permitted functions when using this component in the future-however, I think this method is too complicated and requires a large amount of reading and analyzing XML files, although very rigorous, it's safe, but it's a little too much, and it's not taking full advantage of the flexibility of PHP itself. my idea is to use a method similar to DELPHI's function handle assignment or the features of C's callback function, you can define events at any time and place when writing code, but you can still identify the event sender and type, and ensure sufficient security, without the need to force each component to have only what events, code modification and extension are very convenient. Of course, strict definition is necessary when it comes to large projects. However, even so, the method of handling events by the framework is still somewhat rough.

I think its template is a good idea. some of its templates are similar to ASP files of point NET before compilation (I am not familiar with ASP point NET, but it works in a way similar to the FORM file of DELPHI. it is a good concept, the only drawback is that the WYSIWYG editor like DW does not feel very comfortable, because several mutex components can be put together in a template at the same time, you can only decide what to display during the running process.

I personally read the code of the framework and found that it has some very weak items. One of the most important problems is the path problem. The scalability is very low. it should be suitable for dedicated hosts. some restricted hosts (Directory restrictions or permission restrictions) are powerless, there are no corresponding reminder measures (or related interfaces ). It uses a cumbersome assetService mechanism for the path of some resources or files to determine the file path. The author himself also said that if this service is used, system consumption will increase significantly. In fact, this is based on the concept of asset library in FLASH. although it can specify any path, it must be re-verified every time, which is not worth the candle. My rule is to fix several major paths, and its sub-directories can be arbitrary, which balances the contradiction between the two. Due to the lack of consideration for the path problem, the framework is powerless to set language and customize templates. for example, if you want to translate a project, the procedures are complicated, the workload is huge, and it is easy to make mistakes. This is the most serious problem in the framework.

In general, the design of the framework is absolutely top-notch in code. Of course, there are always deficiencies, but they do not prevent us from studying and learning it. I did not fully understand its code. I only read a few core programs and some instructions, but I have been able to clearly understand its structure and ideas and I deeply admire the author, however, I am deeply sorry for the shortcomings. In any case, it is definitely a good work to study PHP event-driven code. Therefore, it is strongly recommended!