SF Project Link
was developed to aid using an MVC approach for building XML user
main target of the framework, but parts of it can be applied to any
XML user interface. The framework is based on the following principles:
- There are two types of UI construction:
Layout UI construction can be done before any
runtime requests are received. It can be constructed during a build
process or as part of deploying the UI files to the server.
All Data UI should be generated on the client. The client in this
case is normally a web browser.
Server processing should be limited to providing data services and back-end business logic
- Layout UI. This type of UI construction is for general layout.
It does not depend on user's data, or data that depends on the specific
runtime request. This type
can be considered part of the View in an MVC pattern.
- Data UI. This type of UI can only be constructed during
the runtime of the UI. This type of UI is generated by an interaction
with the Controller and Model in an MVC pattern.
Effects of the principles:
Approaching UI construction this way allows for the general UI Layout
be served statically from a web server. This in turn allows for caching
of the files by proxy servers and by clients. Some care needs to be
taken with versioning, but there are simple approaches that solve the
issue at the expense of longer term cacheability.
Since all data UI happens on the client, the state machine for the UI
has to be centralized in the logic engine running on the client. This
server application logic on the server to focus on data services and
business logic only.
Normally UI flow and state change more frequently
than the core data services and business logic, so using partitioning
specified by the principles allows for a clearer, more efficient
separation of work between two teams. This allows the
implementation of the server data services to be done in a separate
technology than the UI. It even allows the possibility to be served
from a different place than the server, even locally on a client
machine (although there are browser security models to consider).
For rich web applications, there is better performance with this
The above runtime performance advantages could also be leveraged to actually
scale back the amount of server power needed for the application,
improving cost performance.
UI is served as static files -- no application server/processing
modules are needed to serve the UI.
The UI can be cached by proxy servers, or even in the client browser
Since the UI is static and cacheable, it means there is a very low
latency between user request and a response. This is particularly
important in a broadband world where server response latencies become
the speed bottleneck.
Perceived performance by the user. The sooner the client gets some
UI, the sooner it can start to generate it for the user, and start
retrieving additional assets for the UI (images, scripts, data).
There are techniques to allow data caching during user session in the
browser, avoiding further server load.
For development, prototyping is made easier, since the data services
MVC ChallengesThere are particular
Model, View and Controller challenges in using the MVC framework
described above for web applications, and Tagneto provides tools and support to address the challenges.
Getting the ModelIn
the strictest conformance of the above principles, the dynamic Model
data for the page (user's data, request-dependent data) is not combined
with the layout HTML on the server. It happens on the client. There are
a few ways to retrieve the Model with this approach:
- Dynamically created SCRIPT tags.
has the advantage of working across site domains, but requires the
when the Model has finished loading. Large requests will not work with
this approach either -- only requests that are small enough to fit as
an HTTP GET request (a safe size seems to be about 1KB).
- Hidden FRAME or IFRAME.
A hidden FRAME or IFRAME could be used to send requests to the server
for the Model. This approach limits requests to specific site domains,
similar issue to the dynamic SCRIPT tag approach as far as knowing when
the Model has finished loading. It could also trigger the "wait"
cursor, and in MSIE, the user may here a "click" sound for each
requests (the same sound MSIE uses whenever a new page is requested).
HTTP GET/POST requests are allowed with this method, allowing for very
large request sizes.
- HTTPXMLRequest object.
The HTTPXMLRequest object is supported by most modern browsers.
However, the SCRIPT or FRAME/IFRAME approach may work in a larger set
can only come from specific site domains (normally the domain that the
requesting HTML came from). It has an explicit callback when the Model
has finished loading. HTTP GET/POST requests are also supported, and other HTTP commands may work too (but there may be issues with Safari).
Format of the ModelWhen
the model data is retrieved from the server, it should either be
The decision on whether to
dependent on the server providing the API calls. Using XML could allow
re-using some existing data APIs that the server exposes. It would be
approach prefers that format, and a conversion will have to be done on
XML data. However, that might require custom adapters on the server to
convert data to the correct format. Approaches like JSON may make this easier to do.
application server is not required to serve the View HTML files.
for large projects, there are many pieces of HTML/CSS/script that are
reused as part of many pages. Some sort of tool is needed to build
the final View HTML pages
from HTML fragments. This tool should be able to run offline,
as part of a "compile" step for the application.
the complete View HTML page is built up from HTML fragments, the tool
should have the ability to put the code in the right places
in the final HTML file (<script>, <style>, <link>
tags should go in the <head> area), and the HTML fragments should
be able to specify an "API" for inclusion in the final HTML file.
Tagneto gives the developer a set of tags and tag handlers to do effective View assembly. It is easy for the developer to define new tags that use the built-in tag handlers.
SanitationUsing HTML fragments to build a larger page can lead to a
final HTML file whose source is not easy to read. In addition, when the HTML is
ready to be pushed to a production environment for end users, it may
be desirable to strip out comments and excessive white space to cut
the UI would also avoid unwanted bugs that may only surface when a user
actually uses the application.
file filters are supported in Tagneto that allow processing the
final HTML pages. Right now, only a file filter that supports stripping
whitespace and comments is built. HTML pretty printing and validation
is on the task list.
hard to do. Event handlers can be embedded directly in HTML as an element's attribute, and reference
functions in an external script file. Event handlers can be added
tag allows a developer to group all the event handlers on a page so it
is easy to edit, but allow for the flexibility of binding the event
handlers as element attributes or dynamically binding in script.
messy. Using DOM methods (like appendChild()) is harder to do than
"just writing HTML". Using innerHTML to inject HTML requires the HTML
read and maintain. Tagneto's ctrl tags allow the developer to just write HTML and allow the framework to escape the HTML properly.
Allowing browser caching of pages with dynamic URLsIt
is normal for web pages to need dynamic information, usually in the
form of GET (querystring) parameters, like
"?name1=value1&name2=value2". However, asking for a page like that
may not be cacheable, and the browser will unload the current page to
navigate to the new URL. If these effects are not desired, Tagneto's Ctrl.js can be used to allow passing of dynamic parameters via the fragment identifier of the URL, like #name1-value1.
Why Not Something Else?Tagneto
was developed because of perceived shortcomings with the existing
alternatives. The shortcomings may no longer exist in the alternatives
(Tagneto was started in the summer of 2004), or Tagneto's author may
have missed solutions or misunderstood the alternatives.
The main alternatives seemed to be Java Server Pages, Active Server Pages or PHP.
They all have a similar design (from the perspective of a developer
using them to build UI), so they will be referred to as SP (Server
Pages) for the rest of this document. All of the SP variants
are valuable and useful, and Tagneto can be used with them. Tagneto's
motivational principles and the author's subjective preference gives
rise to some differences between Tagneto and SP:
was considered early in the project, but the requirement that the
source be valid XML was not compatible with the Tagneto design goals.
- Tagneto is
designed to not need an application server to render the HTML pages.
For many types of web applications, a good deal of work can be done
"offline", on a developer's box as part of a compile or transform step.
If Tagneto's motivational principles are strictly followed, all of the
View can be generated offline, and this allows for long cache times. For many
web applications (including this web site), that is the only source
processing that needs to be done.
- It is very easy to mix the
Model, View and Controller in SP. It is still possible to do that in Tagneto,
but the offline compile step really forces the developer to consider
the MVC boundaries.
- SP's syntax. This is a
highly subjective issue, so take it with a grain of salt. The syntax to
demarcate SP parsing does not look at home in HTML, and the script
languages used for server processing are different than the browser's
one language for both.
- XML syntax for demarcating SP
parsing can be used, at least with JSPs, but it requires the entire
document to be valid XML. Tagneto can be used in non-valid HTML/XML.
However, the tags that Tagneto will handle do need to be either XML
conformant, or conformant to a defined alternate syntax. Support for a XML syntax and a XML Entity-like syntax is built in, and new ones can be defined.
SP include mechanism for including HTML fragments is weak on scoping
the script variables and for enforcing required script variables needed
for the include file. Tagneto allows for creating a child script scope for just the included file, and the view:inclueparam tag allows specifying required script variables needed for the included file.
- Tagneto is non-invasive to the source. No special tags need to be defined in the HTML that is to be processed. The tagneticconfig file specifies the parsing and tag rules for the source. This ability coupled with overlays and the TagDefine functionality allow for interesting possibilities.
Why Java?Java was Java used to build the View Assembly tool in Tagneto (The Java runtime is needed only by the web
developer, not on the web server or on the end users computer). Java was used
because that language is the most comfortable one for the author. It is
also nice that it is cross-platform, and has internationalization
and localization features built in. Being object-oriented makes it nice