How will this Work?

During the development phase, the programmer will program the invocation for an unknown ezAJAX Server Command such as “FetchDataFromDb”, for instance. As soon as the client-side code has been executed but before the ezAJAX Server Command has been coded the normal behavior for the ezAJAX Framework would be to throw an error on the server that is sent back to the client to notify the end-user (the programmer at this point in time) that an error happened on the server.

Future version of the ezAJAX Framework will notice that a given named Server Command does not exist and automatically prompt the programmer, during the development phase, to identify to the ezAJAX Framework as to what kind of Server Command the programmer wanted to use.

Let’s say the programmer intended to code an ezAJAX Server Command that performs a SQL Query which typically returns a Query Object from the ezAJAX Server. In this case, the ezAJAX Server would prompt the programmer for the Server Command Type. The programmer would select SQL Query as the Server Command Type and the ezAJAX Server would automatically produce code to support the SQL Query Server Command except for the actual SQL Code which the programmer would supply at a later time. The programmer could then construct the SQL Query syntax and plug it into the stubbed code that was automatically generated by the ezAJAX Framework along with any ancillary processing the programmer may desire and the work is done. The programmer can then move along to the next Server Command and repeat the process until the application logic has been produced.

The other side of the coin could be just as easily generated by the ezAJAX Framework to support client-side processing.

Let’s say for this example, the programmer failed to code the client-side Call-Back for the ezAJAX Server Command invocation. In this case, the ezAJAX Client would catch the error the ezAJAX Framework threw and automatically issue an ezAJAX Server Command to automatically generate the appropriate client-side code to support the common code that all ezAJAX Call-Backs share in common except for the specific application logic.

Some programmers may wish to leverage the concept of sharing abstract Call-Backs among various ezAJAX Server Commands and “yes” the ezAJAX Framework fully supports this powerful feature. In this case, the ezAJAX Framework would not automatically generate client-side code for an already existing Call-Back since the client would, in this case, throw any client-side error.

The primary goal for the ezAJAX Framework is to make the programming effort as small as possible. Reduce development time to as little programming time as possible. Allow code to be reused as much as possible. And to fully support the Agile Methodology as much as possible.