ATag is a light-weight framework for creating 'true' MVC GUIs for HTML clients.
ATag supports modularization and generalization of components and creation of component groups in the form of panels.
Using ATag you can create asynchronous html components which can be loaded independently of the page they appear on.
ATag propagates HTML events ('click', 'change', etc.) from any given component to the server asynchronously, and redraws the list of components returned in the response.
In many ways, ATag is like a JSP include system. If you are at all familiar with Struts Tiles, then you can think of ATag as an asynchronous version of Tiles, wherein any Tile can be refreshed based on its dependency on a component firing an event.
This implies that the smallest unit that can be refreshed independently is a JSP file. Therefore every form field or display area that may need to be refreshed because of a dependency on another component will require its own JSP file.
However, as just about every value required for rendering a component is injected into the component from the reference level, components and panels (groups of components) can be made generic so that only one JSP file is required for any one type of component (i.e. inputText.jsp, select.jsp, checkboxGroup.jsp, myObjectPanel.jsp, etc.).
On the client side, ATag is a set of javascript functions that prepare and dispatch ATag events to the server, and on receipt of a valid response, render the content on the appropriate areas of the page.
A key feature of ATag is that an ATag page can be rendered form any given point within the ATag component hierarchy.
In order to render a page from any point other than its root, ATag requires a component context to use as a starting point.
ATag client side sends an event which is accompanied by 1 or more component
contexts.
The first context in the list belongs to the event source component and the
rest (if any), to its dependents.
On receipt of client events, the ATag controller which is implemented as a Servlet Filter, first forwards control to the underlying webapp, giving it a chance to act on the event, and/or change the view data model. It then iterates the contexts dispatching, in turn, to each corresponding view and writing the output to an XML formatted response stream (wrapped in CDATA).
ATag stores contextual information about a component on the client page in a container tag (<div>) that wraps each ATag component. This information is only loaded once - when the page is initially requested.
When the ATag client side dispatches an event, it posts (along with any form data) only the context information of the component that fired the event and those of its dependents (if any), not of the entire component hierarchy (as is the case with some JSF client state manager implementations).
This makes ATag efficient, only rendering the required subsections of a page. And as all the dependent components are rendered during the scope of a single request, ATag could easily be deployed in a random load-balanced environment without session replication.
Up to the point of being loaded, an ATag page is juat like any other html page. If after loading, the Javascript is unable to obtain an instance of XMLHttpRequest object, the page will simply funtion as a normal html page, without the asynchronous functionality.
See here for Installation details.
See API docs ATag specs.