Time
is money!
Table of Contents
Let us start from the main demands to the Service Pages Addon conclusions ratios and real capabilities as developer's(ours) as user's(yours).
One of the main demand to Service Pages Addon was a web-interface functional capabilities increase to the maximum possible level. Open web-api observation ensures us in this demand implimentation ability in spite of the part of that library is not documented.
No less important demand was the interface visual attraction development. Possible boundaries, limiting this demand were defined by available software as client's as server's one. The question was already discussed earlier.
Finally, the application had to be flexible enough to satisfy all the possible customer wishes at the development stage. XML-compatible standards development groth became very suitable for the implementation of this demand. The question is about as a program structure as a data structures - namely, the solid markup language usage allows big increase in flexibility for all application in general. Sorry to say, a XML-compatible JAVA+JSP languages mix for the server side programming was used, which was the reason for that solid format for both data and actions wasn't possible. Nevertheless, using predefined xml-entities and explicit possible java blocks enumeration allows creation of source code solely with xml-tags, while java code blocks not covered by enumeration could be inserted using special insertions with xml <![CDATA[...]]> blocks.
So, let's walk through development process. For the first, let us talk about web-interface design and take a look at main Service Pages Addon user page draft. As in Service Pages main page consists of several frames.
Frameset is described in index.html and consists of references to index.xml and overview.html. Reference button in left frame clicking leads to right frame contents replacement by View.jsp contents printing a table, upper part of which contains view control elements, while lower contains inline-frame referencing ViewBy.jsp. That time, ViewBy.jsp script via HTTP POST receiving the required information. On it's hand ViewBy.jsp generates a XML-compatible listing, then this listing is delivered to the web browser, translated to HTML via table.xsl stylesheet and finally shown. XSL stylesheet usage allows visual design changes according to selected customer's wishes and number of errors elimination, by separate model/view development.
index.xml file is translated to HTML by browser's built-in XSLT processor before output in runtime, which demands client-side XSLT support. To make it happen a stylesheet index.xsl, reference to which exists in index.xml automatically downloaded.
In working application it'll look like this:
As an example, a screenshot of running web-interface in Internet Explorer 6.0 is used [5], in this case it's persons list. Images on control elements are taken from icons folder of Service Desk Client application and translated to the .png type via convert utility from the ImageMagic toolkit.
Here are the difficulties have met when implementing objects listing:
The positive thing, though, is a jvm built-in introspection, which allows classes and methods definitions on their string names in runtime, calling them in context object and type casting of the returned values.
Now let's consider the process of object editing form development. Comparing to the listing page development, this case there are reasonable conditions for another structure design.
Editing form's visual design were chosen as much as possible similar to Service Desk Client's. According to this, control elements layout is used as shown on the underlying draft image.
Object editing pages development process, as used to say, is segregated on several parts. Source code in xml-compatible language contains a description of editing page's parts using several name spaces(xml namespace). Namespace sd: is used by a stylesheet to convert XML data to HTML in runtime. This way one can change a visual layout of the page without source codes changes. Namespace sdjsp: is used for application logic description not covering it's style. Tags not having explicit namespace declaration are considered as common, i.e. could be proceeded as at first compilation stage as in runtime.
On this picture base compilation/execution stages are schematically shown. The names of source code and resulting jsp programs files are constrained by the following naming conventions: source code files must be named as ce_ClassName.xml, where ClassName - is a class name of an object to be edited, for example, ce_Incident.xml, by the way the letter case must match. On the image upon, source code file ce_A.xml contains an editing form description for the object of class A. A stylesheet create_edit_jsp.xsl contains information, required to transform ce_A.xml to ce_A.jsp. During this process tags of the sdjsp: namespace are proceeded, and, as usually, are transformed to form information. Tags of the sd: namespace are left as is. Tags of the undefined namespace are left as is by default, but could be proceeded at compilation stage, that's why source code developer should consult with stylesheets creators. Visual design stylesheet is at create_edit.xsl file and downloaded automatically by browser proceeding resulting xml-code, generated by ce_A.jsp script. Resulting xml-code, naturally, contains only tags without namespaces and sd: namespace tags. As a result, a html-document in browser's cache is created and swhown later.
In working sample it would look like this:
As an example, screenshot from working editing form used, in this case it is an incident editing form.
Naturally to suppose impossible program elements basis creation, satisfying all the needs. For this problem solving, as used to say, there is a capability of making java-code insertions. This capability will be described in the next chapter.
