My opinion on the issue of PHP event-driven

The problem is that someone is talking about the event-driven problem with PHP and should have replied to a post. But think that the reply is not enough to arouse the attention of everyone, so the special open a post detailing my understanding of this problem, and a good book for interpretation and analysis.

The concept of event-driven is broad. Can be either on the client or on the server side.

In the Web application, the event in the client is based on JS or Plug-ins or Javaapplet, and so on, basically, if the plug-in or Javaapplet, it is not part of the category of HTML, and the real need to use JS the occasion is actually not much, The most important thing is to submit a form or click on a link, so it doesn't make much sense to talk about events.

The real meaning of event-driven is not 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, some similar to the callback function in the API, and you can define what these functions do. Visual programming, however, makes these functions independent, defining parameters (mostly ready-made objects), allowing you to write your own code and use those parameters (actually using these objects) to do something.

So, PHP has event-driven is entirely possible, mainly in the design of the framework. And to make VB, such as the so-called visual event-driven, you must have a supporting integrated development environment, including page design, event coding, compile transcoding and so on a series of functions. In fact, like dot net such an event-driven, it just encapsulates some of the commonly used web elements or controls, such as buttons and text boxes, so that you have a visual interface that you can design, and when it's compiled, it's still <input type= "text" > Just convert your event code to JS or server-side code. and PHP is mainly because the IDE is not rich enough, and there is no precompiled mechanism, so the final submission of the code is the final PHP code, rather than the dot net resource code and event code of the mixture (typically XML compliant ASP documents, including non-standard HTML code). Therefore, PHP can not reach everyone in the narrow sense of the so-called event-driven programming, but in fact, there is no problem at all.

If you are interested, you can go to Www.php.net official homepage to see a Chinese buddy (Qiang Xue) wrote a set of event-driven PHP framework Prado, this is the best to get high votes elected, strongly recommended! Please refer to http://www.zend.com/php5/contest, you read his source code will understand the PHP event-driven what is going on. But I think, on top of that, because PHP has no precompilation mechanism and relies too much on OO (though it's written in PHP5 code), it's a bit bulky, complicated, and scalable. However, the idea is very good, and some ideas have solved the problem that puzzled me for many days. Let me briefly introduce this framework.

The framework, written in Zde and PHP5, has a detailed document, a very clear structure, a very full annotation, and the code is very easy to read, indicating that the author's writing code is very high. The author clearly stated that this framework refers to the concept of ASP dot Net and Borland Delphi.

This framework is very strong in the validation (not to refer to what is inside the verification login module), very robust, almost impossible to have any direct vulnerabilities can be invaded from the outside, it is introduced into the concept of the specification file limit, very effective solution to a large number of validation when the bottleneck of efficiency, The only problem with this method of verification is that the specification file itself is made more laborious (of course, another thing with the tools), but once done (the specification file itself has format and specification), validation is done automatically by the framework, without having to call each person. Its events can also be defined within the specification file (I do not think it is necessary), in fact, its specification file is somewhat similar to the Delphi or VB form definition file, but is written in XML plain text, rather than visualization. And for event-driven, the framework has a set of basic event streams similar to dot net, you can customize these events in different stages, in fact, it is to redefine these onxxx functions, in the given form of parameters, you can also join your own events, such as when you define your own components, Define the event functions and parameters that the component may have in the specification file. Later you can define these allowed functions directly when you use the component--but I think it's too complex to read and parse the XML file in a large way, but it's very rigorous and safe, but it's a bit excessive, Nor does it take full advantage of the flexibility of PHP itself, my idea is to use a function handle like Delphi or a C callback function of the feature, you can write code at any time at any place to define the event, and still be able to identify the issue of the event and the type and adequate security guarantees, And it is convenient to modify and extend the code without having to mechanically force the individual components to have only events. Of course, when it comes to big projects, a strict definition is necessary, but even so, the framework handles the event in a somewhat old-fashioned way.

It's the template I think is a better idea that its template is similar to dot net ASP files in the pre-compiled file (I am not familiar with ASP dot net, but understand some principles), but the way it works is similar to the Delphi form file, is a good concept, The only drawback is that using the WYSIWYG general editor, such as DW, is not very comfortable, because a template can put several mutually exclusive components together, and only decide which to display during the run.

As I see the code for the frame, I find that it has some very weak entries. One of the most important is the path of the problem, scalability is very low, should be more suitable for the dedicated host, for some limited host (directory restrictions or permissions restrictions) can not, there is no corresponding reminder measures (also no relevant interface). It for some resources or file path, with a cumbersome called assetservice mechanism, the purpose is to determine the path of the file, the author himself also said, if the use of this service, the system consumption will increase significantly, in fact, this is borrowed from the Flash Asset Library concept, It is so that although you can specify the path, but each time you have to check, some of the gains outweigh the gains. My approach is to fix several major paths, and its subdirectories are arbitrary, the balance of the contradictions between the two. Due to the lack of consideration of path issues, resulting in the framework of language settings, personalized templates and so powerless, such as to translate a project, procedures of the complexity of the workload is conceivable, and very easy to make mistakes. This is one of the most serious problems in the framework.

Overall, the concept of the framework, design, the code is absolutely first-class. Of course, there is always a shortage, but it does not prevent us from studying and studying it. Its code I do not look at, only mainly read a few core procedures and a number of instructions, but has been able to see the structure and ideas, the author deeply admire, but also deeply regret the deficiencies. In any case, it's definitely a good work to study PHP event-driven code. So strongly recommended!