Skip to main content.

Sunday, September 25, 2011

Falcon has an elected web application platform called "Nest" (Falcon Nest...) which we're intensely developing and that's becoming ready for production services by the hour.

Initially, the only modular element in the picture was a so called "Service", a type of standardized module that could have been interacting with other services in a page, and that would have had to be "configured" (actually, programmed) on-site. For instance, a "Form" could have been a service, as a whole "Wiki". The idea is quite interesting for self-contained entities as the "Login" service, where the rendering of the login form, the check of the authorization level and other related activities can be tracked to a single conceptual entity; or, in simple database-table editing, where the form must just read and then store data in the required record; you just need, and most of the time just want, a very simple way to perform some consistency checks before storing data in the database, and then you're done.

But modern web application design requires far more. Initially, I thought that it was simply possible to delegate everything client-side to third-party client libraries, as jquery or mootools; in fact, Nest is pretty forgiving on the overall site structure and can be pretty shy, to the point that you won't even notice it's there... and so, not even use it. Especially when it comes to AJAX, while those client-side libraries have interesting pure AJAX frameworks where you just have to provide your server-side programming, the concepts behind Nest were too heavy-weight to delegate everything to a completely separate and stand-alone server-side AJAX interface. For instance, when activating the persistent login and database session management facility, having to javascriptize all the data that the server-side function of an AJAX framework need might be hard and clumsy.

So I thought a way to circumvent that, without necessarily overseed or outrule client-side javascript libraries, and I came out with the idea of "widgets". They are visual elements of the final page that are rooted inside the Nest application, and thus, they can use all the facilities used by Nest, as, for instance, the current status of the variables are they are set by existing services, or session data as it is handled by the session manager.

Widgets expose an AJAX interface that is published by Nest, and some simple javascript calls to excite the exposed AJAX interface and enforce actions that the AJAX interface wants them to perform. A simple javascript glue code (approx 150 lines) is used to bridge the Nest server-side widget representation and the client-side rendering.

Widgets can be configured right on-page (where they are rendered before sending them to the browser) so to link with any foreign javascript code or library. Also, while they have a pretty useful AJAX interface, they can use third party AJAX support. They themselves or the rest of the web application can interact with AJAX functions exposed by Nest independently by their widget AJAX interface, or could attach to the Falcon WebAPI simple AJAX framework (which doesn't require Nest to provide web AJAX features).

ATM this new feature is not very well integrated with the rest of Nest; i.e. the database oriented Form service is not using them. It will take a few days figure out how to work this feature in the existing framework.


No comments yet

Add Comment

This item is closed, it's not possible to add new comments to it or to vote on it