|
Page 3 of 4 IndicThreads
>> In a recent interview with IndicThreads,
Jonas Jacobi said that "Pure
Ajax creates the next generation legacy
applications"
and "There is no migration path from a pure Ajax
solution". Is my application future proof if I use Ajax with Backbase's
framework?
Mark
Schiefelbein >>
Jonas suggests that you can avoid legacy by focusing on JavaServer
Faces (JSF), and that is exactly what the Backbase Java Edition does.
An application developer who uses Backbase does not have to be aware of
the specifics of the client-side Ajax engine and can just use the JSF
UI Components, which work according to the JSF standard.
"Avoid legacy by focusing
on JavaServer
Faces (JSF)..."
However, we have customers who cannot move to JSF today,
usually
because they need to continue supporting a legacy application. For
those customers we are offering a client-only Ajax solution that works
with any server-side technology. In addition, this autumn we will
launch a Struts edition, which provides an easy way to add Ajax
features to the large number of active Struts projects.
IndicThreads
>>
As you would know, the Java world is obsessed with
standards. is
Backbase working on standardization of any of the technologies
involved?
Mark
Schiefelbein >>
Yes, we are working on a number of initiatives. First of all, we are a
member of the OpenAjax initiative, which aims to provide standardized
tooling for Ajax development, primarily based on Eclipse. Our
development tools are already based on Eclipse and WTP and we expect
that the OpenAjax initiative will drive further standardization.
"OpenAjax initiative aims
to provide
standardized
tooling for Ajax development..."
Secondly, we are using existing standards where possible. Most
prominently this is JavaServer Faces, which is at the core of our Java
Edition. On the client-side we make extensive use of XML, XPath and
XSLT, and of course JavaScript.
For developers it would be great to have a single standardized
UI
definition language. That's why we are closely following all
initiatives to create such a language and are directly involved in some
of them, including the OpenAjax Initiative markup subcommittee.
IndicThreads
>>
There are so many Ajax frameworks out there that it's quite difficult
to understand how one differs from another. Are Dojo, Backbase, Google
Web Toolkit, DWR, etc. directly competing with each other or does each
have its own space / category?
Mark
Schiefelbein >>
Ray Valdes of Gartner has created a frequently used classification of
Ajax frameworks in an article on application development trends.
He lists four levels of
Ajax support:
-
Snippet level
-
Widget level
-
Framework level
-
Enhanced Framework level
DWR focuses solely on remoting of function calls and hence
falls into
the snippet level category. Several UI Component vendors focus on
providing individual widgets to ajaxify existing web interfaces. Those
are examples of the widget level category. To reach framework level a
toolkit needs to provide an integrated Ajax Engine, with - for example
- a common browser compatibility layer. Dojo is an example of this.
Backbase and GWT are examples of the enhanced framework level as they
also provide server-side integration and tool support.
DWR - Snippet
Level
UI Components - Widget Level
Dojo - Framework Level
Backbase and GWT - Enhanced Framework level
While today there are many, many Ajax offerings, very few
provide the
functionality and maturity required to build and maintain Ajax
interfaces for business-critical applications, like Backbase does.
|