It is assumed that you are using, or want to use, the following technologies:
The Adapt package provides a small set of Java support classes to help integrate these, reduce the learning curve, and provide facilites for getting started relatively quickly.
Roughly speaking, it consists of developing JSP pages and "bean" support classes (these are Java classes with one or two extra conventions which allow them to be accessed from JSP tags) in a carefully separated way. In the JSP pages, HTML and special JSP tags are used, and no (or not much) Java. In the bean classes, the data is stored and the logic is written in Java. Separate experts are used, e.g. a Web page designer for the JSP pages, and a Java programmer for the beans.
This strategy is suitable in a large corporate setting where there are plenty of resources with separate specialist experts available, where developers have or are prepared to gain a high level of expertise, where a large project is thought of as a single integrated application, where heavy duty analysis and design is done, where the project has a complex state shared amongst the JSP pages, where the maintenance involved once the product is implemented is light and centrally controlled, and where the product is aimed outwards at the general public.
However, in a smaller scale setting (which is much more common), this can be a "sledgehammer" approach. The Adapt package provides support for using the same technologies, but with a more lightweight approach.
Some people argue that using Java directly, instead of tags, makes it harder for non-programmers to work on the graphics aspects of pages. However, tags can be surprisingly verbose and complicated, and are often not all that easy for non-programmers. The Adapt facilities are designed to be as compact and as easy to use, in simple circumstances, as tags. In any case, a 'pure' Web page designer often needs a modicum of 'real' programming to make decisions, alter data, or loop through data, and tags soon turn out to be too restrictive for this.
It is also argued that mixing presentation and logic on a single page is bad design, causing maintenance problems. In the long run, where logic is shared between pages, this is true. However, on a small scale, the logic is often different on each page. This is particularly true when the most common needs for sharing things between pages are already provided by general support classes and the database. Splitting the issues involved with a single page into two places causes its own maintenance problems.
Reducing the need for support classes is important because they are more difficult to develop, requiring separate compilation and 'manual' installation in the right directory, making the turnround time for developing and debugging larger than for JSP pages. Also, if a lot of people share the authoring of a site, remote management of the site becomes very attractive, in which case it is easy to give people limited access to update certain JSP pages, but much more difficult to give them suitable access to write and maintain support classes.
In any case, Adapt does not prevent conventional development with beans and tags and so on, it just allows people to put it off until it is really needed.
To extract a field from an object using JSP tags, you have to write:
<jsp:getProperty name="obj" property="field" />
To do the same thing using Adapt, you can write this (while in Java):
This is both simpler, and more flexible. Suppose, for example, that the
field contains text and you want to change each occurrence of
y before printing it. Then you can write:
If the site has a default database connection set up, then you can make an SQL query by writing:
a.query("select * from people");
Data from the table, e.g. the surname from the i'th record, can be extracted and printed with:
It is true that as sites get bigger and more complicated, the idea of putting separate queries on each page doesn't scale up very well. This will be addressed in later versions of Adapt.