1. Mandatory
Request Parameters Validation
1.1 Mandatory
Request Parameters Validation
2. Pure MVC
Compliance
2.1 xxx
3. Separation
Application Logic from Presentation Layer
3.1 xxx
4. Built-in ACL
Security System
4.1 xxx
5. Handling with
Session Expiring
5.1 xxx
6. Multiple Web
Designs and Internationalization
6.1 xxx
7. Automatic
Action Documentation
7.1 xxx
8. Runtime
Configuration of Application Workflow
8.1 xxx
10. Dynamic Page
Lifetime Feature
10.1 xxx
11. Static and
Runtime Page Including
11.1 xxx
12. Handling
with action errors
12.1 xxx
13.
Visualization of application structure for modeling
13.1 xxx
14. Automatic
generation of actions errors messages resource file with support for
internationalization
14.1 xxx
15. Setup Sample
Application
15.1 Tomcat
15.2 Orion
15.3 Borland
Application Server
15.4 Resin
15.5 Weblogic
15.6 iPlanet
15.7 IBM
Web Sphere
16.
Roles
16.1 Core-programmer
16.2 Action-programmer
16.3 Security-manager
16.4 Web-master
17. Writing
Application With GlueX
17.1 Action
Servlet
17.2 View
Servlet
17.3 Actions
17.4 Action
Errors
17.5 Validators
17.6 Action
Cases
17.7 XML
Content
17.8 XML
Filters
17.9 XML
Generators
17.10 Built-in
XML Generators
17.11 Permission
Driven System
17.12 gluex-config.xml
17.13 Emmortal
Session Data Feature
17.14 Metrics
17.15 The
paranoiac mode
17.16 Action
pooling
17.17 Action
name mapping
17.18 GluexServlet
class
17.19 GluexAction
class
17.20 GluexSession
class
17.21 GluexContext
17.22 ViewServlet
class
17.23 Variables
17.24 Care
with session expiring
17.25 Built-in
XML generators
17.26 Some
usefull XML generators
18. Design Node
Configuration Files
18.1 The
node-config.xml file - configures design node structure
18.2 The
view-config.xml file - configures View part of GlueX based application
18.3 The
actions-config.xml file - configures Controller part of GlueX based
application
18.4 The
principals-config.xml file - configures security system
18.5 The
resources.properties file - language resources
19. Smart
Session Expiring
19.1 Idata
21. GlueX
Modeling Language
21.1 Design
Diagram
21.2 Permission
Diagram
21.3 Application
Workflow Diagram
22. Interaction GlueX based web applications via web
23. GlueX
Processing Directives
23.1 Pre-processing
Directives
23.2 Post
Processing Directives
Complexity of software systems grows combinatorially as functionality and number of components increases. At some complexity point new functionality can't be simply added by implementing of new components, since interdependency between components make system too fragile and unpredictable.
Simple frameworks which are very well suited for small applications because of number of assumptions, default behaviours in some cases, etc, fail to produce viable solutions for larger projects. Something more rigid is required.
Example of such an approach could be modern programming languages such as Java with strict data types, several compile-time checks etc, as opposed to earlier languages such as Basic. It might be harder to write simple "Hello World" like applications in rigid language, but when a system contains hundreds of thousands lines of code, good technology becomes very beneficial.
GlueX framework is a XML/XSLT-centric library simplifying building of Java web application on standard servlet containers supporting Servlet 2.2 specification. The main principle of GlueX is presentation of state of the web application in XML. Then xml-model is transformed to presentation HTML or other markup language with XSL transformation.
GlueX allows increase speed of web applications development and significantly improve quality of resulting solutions. The framework stems from real-world application development practice and helps to cope with many tipical challenges faced by software architects and programmers.
This document contains detailed GlueX framework specification. It is intended for programmers and web designers who want to fully understand GlueX concepts and employ its power.
During web application development we can discover several challenges that can be compleately solved in web application framework in that way reducing development time and cost. We put efforts in implementing of GlueX framework so that it takes care of most of such issues in general way so that each application can use built-in framework features and benefit from them.
Mandatory Request Parameters Validation
With GlueX framework, in any application action, request parameters are mandatory validated before further processing. If an action uses request parameters such action must define validator for every request parameter. Learn more...
Pure MVC Compliance
GlueX based web applications are build in compliance with MVC (Model-View-Controller) design pattern which is generally applicable standard for most web applications. Learn more...
Separation Application Logic from Presentation Layer
The GlueX web application framework completely separates web designer from java code routine providing him only with high level access to the applications services such as actions, security, etc. From other hands, the web designer has much more freedom with application workflow, comparing with traditional approaches, thanks to control over user activity which is implemented in the web design tier of the web application. The web designer can consider about web application simply as a heap of actions. Internal state of the web application can be retrieved via XML presentation. Programmer provides web designer with a general web application description, detailed action documentation and web design reference implementation. Programmer must ensure that XML content completely reflects current application state and contains all necessary information that may be required by web designer. Then the XML content is processed by a corresponding XSL transformer getting final HTML that is written into response stream. Learn more...
Built-in ACL Security System
GlueX framework provides developers with build-in advanced declarative security system so that they don't have to check permissions inside every action or screen. This system extends standard Servlet Security Model defined by Servlet Specification. Learn more...
Handling with Session Expiring
The main conception of Session Expiring mechanism is that web application resources can be separated on kinds: session expiring sensitive and no sensitive. For example, an main index.html screen should not be session expiring sensitive resource since this is first place where browser enters to application. Learn more...
Multiple Web Designs and Internationalization
With GlueX framework the web designer has dealings with XSL stylesheets and design configuration files. A GlueX based application can have more then one web design that is suitable for multiple designed and internationalized web applications. In multiple design implementation GlueX uses design inheritance principles similar with class inheritance in object oriented programming. When web designer wants to create a new web design he can inherit subdesign from superdesign overriding only necessary design files. Such subdesign can act as superdesign for another design. So web designer can create design tree avoiding doubling existing code. For example, a design diagram can looks like following: Learn more...
Automatic Action Documentation
Action docs are intended as communicantion media between action (Java) developers and Web-layer (XSLT) developers (these are two separate roles in GlueX). GlueX provides Web Developers with automatic action documentation generation system. Learn more...
Runtime Configuration of Application Workflow
One of the ticklish questions in web application development is user activity control. For example, if user submit the HTML form containing wrong data, application should return browser back to the form screen to give a chance to repair the data and try again. This widespread application behavior can be hardcoded directly in javacode of course. However, in practice not everything so smoothly. Often it is necessary select next user screen depending on action results. For example, user should be redirected to the login screen if he try to perform protected action. Of course this functionality can be java hardcoded as well, that is good solution for amateur developers only. More brilliant way is make such functionality configurable and allow to web designer decide where user should go depending on action result. Learn more...
XML Filtering
An xml-model of GlueX based web application can be rather large. However, to make a screen web-master needs only some of nodes of xml-model. GlueX provides web-master with XML Filtering mechanism adjusting in configuration files personally for particular screen. XML Filtering approach economizes memory and CPU resources as well. Learn more...
Dynamic Page Lifetime Feature
Dynamic Page Lifetime Feature Learn more...
Static and Runtime Page Including
Static and Runtime Page Including Learn more...
Handling with action errors
Every action must declare its possible results - different outcomes and errors. (excluding validation errors, self-documented validators take care of these). Learn more...
Visualization of application structure for modeling
High level GlueX based web application workflow is described in four design configuration files. Using information from this files visualization tool can build Design Diagram, Permission Diagram and Application Workflow Diagram using GAML (GlueX Application Modeling Language). Learn more...
Automatic generation of actions errors messages resource file with support for internationalization
GlueX provides developers with tools creating AEMRF automatically. Really, each action has declared validators and action errors. There is way to extract this information from all application actions and use it for generation error message file. Of course, at the application release stage, AEMRF can be customized already. Since in GlueX AEMRF has XSL format, the any sophisticated customization can be done. Learn more...
Setup Sample Application
Roles
Since GlueX provides developers with sufficient separation between web-application parts such as Model, View, Controller and Security Subsystem, development roles can be easily separated as well. Sufficient separation is achieved thanks to minimizing interaction links between the application components. On the other hand such separation minimizes time for writing internal project documentation and communication between persons engaged to the project. This chapter determines basic men roles in development of web applications based on GlueX framework. Subsequently, depending on application specificity, such roles more or less can be divided up to further low level sub-roles. Learn more...
Writing Application With GlueX
Design Node Configuration Files
High level GlueX based web application workflow is described in four design configuration files. Using information from this files visualization tool can build Design Diagram, Permission Diagram and Application Workflow Diagram using GAML (GlueX Application Modeling Language). Web application workflow is described in design config files. Application developer can concentrate on action development instead of user activity. Configuration files describe: what action can be performed, screen shown, links enabled (principals-config.xml) for each security role what next screen must be shown depending on action results (outcomes, errors) (actions-config.xml) what happen if session has expired (actions-config.xml, screen-config.xml) One of the powerful feature of the GlueX framework is web design inheritance where files in parent design node can overriden by files from child node. Actually a design node is located in the filesystem directory. Following example shows typical design node filetree: The root.design is directory containing node files. There is two types of design files: configuration files and presentation files. Configuration files define such aspect as security, application workflow, screens and actions: node-config.xml (in progress) screen-config.xml - configuration file describing all application screens action-config.xml - configuration file describing all application actions principals-config.xml - configuration file describing user permissions to actions and screens Presentation files describe HTML designs and language resources: resources.properties - static language resources file *.xsl - web design *.slice - slices of xsl files that can be included by gluex.include or gluex.indirect-include directives. Note a design node can contain another, application specific, files whith can be obtained as heritable application resources as well. The screen-config.xml configuration file This configuration file describes all application screens. With GlueX framework every screen (html out) is the result of XSLT processing of XML represented internal application state. Learn more...
Smart Session Expiring
XML Generators
GlueX Modeling Language
Interaction GlueX based web applications via web
GlueX Processing Directives
GlueX Processing Directives significantly help to avoid code duplicating in XSL stylesheets making web design more simple to maintain and extend. GlueX uses two types of processing directives - static and runtime. Static directives work when new XSL transformer creating, runtime directives are parsed just after XSL transformation has performed. Since runtime directives are parsed every time after XSL processing they, to some extent, increase request processing time while static directives are parsed only at application startup. Learn more...
| With GlueX framework, in any application action, request parameters are mandatory validated before further processing. If an action uses request parameters such action must define validator for every request parameter. |
1.1 Mandatory Request Parameters Validation
Validator definition is done in action class constructor as shown in following code slice:
...
/**
* Sole constructor. Creates a new UserLoginAction.
*/
public UserLoginAction() {
// Add validators
addValidator(new StringValidator("login", 1, 64));
addValidator(new StringValidator("password", 1, 64));
...
}
In given example, login action using "logn" and "password" request
parameters. Two string validator s insure that "login" and "password" parameters
are present in given request, are no empty and their lengths no more then 64
characters. Otherwise validation error is happen. Usually, if validation error
happen user has chance to correct form field parameters and try again.
Request parameters validation is mandatory. Action parameter can not be retrieved without preliminary validation. This approach ensures, that:
| GlueX based web applications are build in compliance with MVC (Model-View-Controller) design pattern which is generally applicable standard for most web applications. |
2.1 xxx
The Model keeps application state. Usually, in web applications, model is represented by a Application Context and User Sessions. The Application Context is common for all users and Application Context data is shared between all users currently working with application. The User Session is personal object containing user specific information such as personal settings, etc. The lifetime of the Application Context equals lifetime of the application. The lifetime of the User Session usually equals 30 min since last user request.
In the View part Application Context and User Session are monitored by the Context and Session XML generators. This generators generate XML content reflecting current Application Context and User Session state. Then Session and Context XML contents are concatenated together in one general XML content. During XML generation web designer can select only necessary parts of the XML content avoiding extra CPU and memory loading. Then this XML is processed by a corresponding XSL stylesheet in general way.
The Controller part receives http requests from browser. The HTTP request containing action name processing this request. The Controller finds corresponding Action by the action name. If the action found Controller passes request processing into this action. During request processing the Action can update Model. In this case all changes reflects in the XML content. Depending on action result (ok, error, permission-denied, login-required, etc.) Controller selects corresponding screen from View to show it to user.
Internal state of the web application can be retrieved in XML. Developer provides Web Designer with a general web application description, detailed automatically generated action documentation and web design reference implementation, so called "root" design. Developer ensures that XML content completely reflects current application state and contains all necessary information that may be required by Web Designer. Then the XML content is processed by a corresponding XSL transformation to get final HTML or other markup language content.
|
The GlueX web application framework completely separates web designer from java code routine providing him only with high level access to the applications services such as actions, security, etc. From other hands, the web designer has much more freedom with application workflow, comparing with traditional approaches, thanks to control over user activity which is implemented in the web design tier of the web application. The web designer can consider about web application simply as a heap of actions. Internal state of the web application can be retrieved via XML presentation. Programmer provides web designer with a general web application description, detailed action documentation and web design reference implementation. Programmer must ensure that XML content completely reflects current application state and contains all necessary information that may be required by web designer. Then the XML content is processed by a corresponding XSL transformer getting final HTML that is written into response stream. |
3.1 xxx
Internal state of the web application can be retrieved in XML. Developer provides Web Designer with a general web application description, detailed automatically generated action documentation and web design reference implementation, so called "root" design. Developer ensures that XML content completely reflects current application state and contains all necessary information that may be required by Web Designer. Then the XML content is processed by a corresponding XSL transformation to get final HTML or other markup language content.
Note: Usually to make a screen web designer needs only some parts of the XML content. The GlueX provides web designer with XML filter mechanism allowing restrict XML content so only necessary information will be present. XML filters releases application from generation extra XML content freeing CPU and memory resources form extra calculation.
|
GlueX framework provides developers with build-in advanced declarative security system so that they don't have to check permissions inside every action or screen. This system extends standard Servlet Security Model defined by Servlet Specification. |
4.1 xxx
Every screen and action, in GlueX application, can be protected from non authorized access using ACL-based security mechanism. Every user session is belonging to one or more user groups. Every group can have permission set containing granted and denied permissions. Optionally user session can have personal permission settings overriding group permissions. Summary permission are calculated as union of all permission sets.
|
The main conception of Session Expiring mechanism is that web application resources can be separated on kinds: session expiring sensitive and no sensitive. For example, an main index.html screen should not be session expiring sensitive resource since this is first place where browser enters to application. |
5.1 xxx
|
With GlueX framework the web designer has dealings with XSL stylesheets and design configuration files. A GlueX based application can have more then one web design that is suitable for multiple designed and internationalized web applications. In multiple design implementation GlueX uses design inheritance principles similar with class inheritance in object oriented programming. When web designer wants to create a new web design he can inherit subdesign from superdesign overriding only necessary design files. Such subdesign can act as superdesign for another design. So web designer can create design tree avoiding doubling existing code. For example, a design diagram can looks like following: |
6.1 xxx
The root design is the basic design (reference design implementation) containing rough design files. This design is created by the web programmer and contains only necessary functionality. To append some glance web designer should create a new generic design which inherits all files form the root design. Then wen designer overrides design files to make design more sophisticated, suitable for customer presentation. Another custom designs inherits from generic design. They can override some design properties as layout, colors, language settings, etc.
|
Action docs are intended as communicantion media between action (Java) developers and Web-layer (XSLT) developers (these are two separate roles in GlueX). GlueX provides Web Developers with automatic action documentation generation system. |
7.1 xxx
This system explores every application action and builds corresponding HTML documentation which includes:
GlueX also include tool for automatic generation of action error resource files. This resources can be customized or translated depending on design or language.
When web designer make web application html design he(she) need information about application functionality. One from most important section of such documentation is detailed description of all web application actions including action parameters, possible errors, possible action cases. As shown in previous section the action info can be extracted directly from action calsses. So there is the way to build the web application action documentation similar way with building action error resources file.
|
One of the ticklish questions in web application development is user activity control. For example, if user submit the HTML form containing wrong data, application should return browser back to the form screen to give a chance to repair the data and try again. This widespread application behavior can be hardcoded directly in javacode of course. However, in practice not everything so smoothly. Often it is necessary select next user screen depending on action results. For example, user should be redirected to the login screen if he try to perform protected action. Of course this functionality can be java hardcoded as well, that is good solution for amateur developers only. More brilliant way is make such functionality configurable and allow to web designer decide where user should go depending on action result. |
8.1 xxx
GlueX provides developers with such functionality using following rules set:
|
An xml-model of GlueX based web application can be rather large. However, to make a screen web-master needs only some of nodes of xml-model. GlueX provides web-master with XML Filtering mechanism adjusting in configuration files personally for particular screen. XML Filtering approach economizes memory and CPU resources as well. |
9.1 xxx
| Dynamic Page Lifetime Feature |
10.1 xxx
| Static and Runtime Page Including |
11.1 xxx
|
Every action must declare its possible results - different outcomes and errors. (excluding validation errors, self-documented validators take care of these). |
12.1 xxx
This approach ensures, that:
|
High level GlueX based web application workflow is described in four design configuration files. Using information from this files visualization tool can build Design Diagram, Permission Diagram and Application Workflow Diagram using GAML (GlueX Application Modeling Language). |
13.1 xxx
|
GlueX provides developers with tools creating AEMRF automatically. Really, each action has declared validators and action errors. There is way to extract this information from all application actions and use it for generation error message file. Of course, at the application release stage, AEMRF can be customized already. Since in GlueX AEMRF has XSL format, the any sophisticated customization can be done. |
14.1 xxx
In the default constructor of an Action programmer must do following things:
// Create new LoginAction
public LoginAction() {
// Declare action cases
addActionCase(OK);
addActionCase(ACTION_ERROR);
// Set parameter validators
addValidator(new StringValidator("login", 1, 256));
addValidator(new StringValidator("password", 1, 256));
// Declare possible action errors
setErrorPattern("user-does-not-exist", "User does not exist");
setErrorPattern("invalid-password", "Invalid password");
}
An action error is happen in the following cases:
When "unused action parameters found" happen GlueX throws only ServletException because this is simply programming of web deign bug. From other hands, the "action parameter missing or invalid" and "a problem happen at the action processing" error can be caused by incorrect user input or other problems that can happen during user activity. So throwing an Exception is inappropriate solution for that cases.
The standard way of holding with action errors, using in well designed web applications, is creating resource AEMRF (action error messages resource file) file with error messages and select error message(s) from this file by error id(s) returned by the action. Then AEMRF can be customized for different languages.
However, size of AEMRF can be too large. Actually, every validator can return about 5 different error messages. And about 4 different error can happen during action processing. Ordinary action processes about 4 different parameters so number of error returned by an action can be 5 * 4 + 4 = 24. Thus, if web application consists of one hundred actions number of error messages in AEMRF will be about 2400. This is too much to maintain AEMRF by hands. Moreover, such AEMRF all time should be kept up to date with application code.
15.1 Tomcat
15.2 Orion
15.3 Borland Application Server
15.4 Resin
15.5 Weblogic
15.6 iPlanet
15.7 IBM Web Sphere
|
Since GlueX provides developers with sufficient separation between web-application parts such as Model, View, Controller and Security Subsystem, development roles can be easily separated as well. Sufficient separation is achieved thanks to minimizing interaction links between the application components. On the other hand such separation minimizes time for writing internal project documentation and communication between persons engaged to the project. This chapter determines basic men roles in development of web applications based on GlueX framework. Subsequently, depending on application specificity, such roles more or less can be divided up to further low level sub-roles. |
16.1 Core-programmer
Core-programmer is responsible for Model part of web application. As a rule, core-programmer should don't care about presentation and security. Core-programmer provides Action-programmer with high level software interface(s) to an application inside such as EJB tier, etc.
16.2 Action-programmer
Action-programmer is responsible for Controller part of web application. In GlueX Controller consists of action classes implementing web tier functionality.
16.3 Security-manager
Security-manager is responsible for Security Subsystem of web application. With GlueX framework a Security Subsystem is configured in actions-config.xml and principals-config.xml Design Node Configuration Files.
16.4 Web-master
Web-master is responsible for initial XSLT coding.
17.1 Action Servlet
17.2 View Servlet
17.3 Actions
17.4 Action Errors
17.5 Validators
17.6 Action Cases
17.7 XML Content
17.8 XML Filters
17.9 XML Generators
17.10 Built-in XML Generators
17.11 Permission Driven System
17.12 gluex-config.xml
17.13 Emmortal Session Data Feature
17.14 Metrics
17.15 The paranoiac mode
17.16 Action pooling
17.17 Action name mapping
17.18 GluexServlet class
17.19 GluexAction class
17.20 GluexSession class
17.21 GluexContext
17.22 ViewServlet class
17.23 Variables
17.24 Care with session expiring
17.25 Built-in XML generators
17.26 Some usefull XML generators
|
High level GlueX based web application workflow is described in four design configuration files. Using information from this files visualization tool can build Design Diagram, Permission Diagram and Application Workflow Diagram using GAML (GlueX Application Modeling Language). Web application workflow is described in design config files. Application developer can concentrate on action development instead of user activity. Configuration files describe:
One of the powerful feature of the GlueX framework is web design inheritance where files in parent design node can overriden by files from child node. Actually a design node is located in the filesystem directory. Following example shows typical design node filetree: The root.design is directory containing node files. There is two types of design files: configuration files and presentation files. Configuration files define such aspect as security, application workflow, screens and actions:
Note a design node can contain another, application specific, files whith can be obtained as heritable application resources as well. The screen-config.xml configuration fileThis configuration file describes all application screens. With GlueX framework every screen (html out) is the result of XSLT processing of XML represented internal application state. |
18.1 The node-config.xml file - configures design node structure
<?xml version="1.0" encoding="iso-8859-1"?> <!ELEMENT node-config (application-properties?)> <!ELEMENT application-properties (property*)> <!ELEMENT property (#PCDATA)> <!ATTLIST property key NMTOKEN #REQUIRED > |
Description
| the root element | |
| Contains application specific properties | |
| Simple key:value pair. | |
| |
The property key. Must be unique. |
18.2 The view-config.xml file - configures View part of GlueX based application
<?xml version="1.0" encoding="iso-8859-1"?> <!ELEMENT view-config (xml*, set-header*, add-header*, screen*)> <!ELEMENT screen (xml*, stylesheet, include*, set-header*, add-header*)> <!ATTLIST screen id CDATA #REQUIRED lifetime-millis NMTOKEN "0" if-session-expired CDATA #IMPLIED > <!ELEMENT xml EMPTY> <!ATTLIST xml select CDATA #REQUIRED > <!ELEMENT stylesheet (include*)> <!ATTLIST stylesheet name CDATA #REQUIRED > <!ELEMENT include (param*)> <!ATTLIST include id NMTOKEN #REQUIRED name CDATA #REQUIRED > <!ELEMENT param (#PCDATA)> <!ATTLIST param name NMTOKEN #REQUIRED > <!ELEMENT set-header (#PCDATA)> <!ATTLIST set-header name CDATA #REQUIRED > <!ELEMENT add-header (#PCDATA)> <!ATTLIST add-header name CDATA #REQUIRED > |
Description
| root element of the view-config.xsl file. In view configuration files Web Developer can describe which screen well be shown if user tries to perform action or view some application screen from new or expired session. Generally, all restricted screens and actions should be redirected to another place (such as login form) if session has expired and permissions lost. If no such screen specified, application is still protected from unauthorized access: "permission denied" screen will be shown by permission manager. | |
| describes single screen | |
| |
id |
| |
screen lifetime in milliseconds. |
| |
The if-session-expired attribute contains URL where browser is redirected if session has expired. If session has expired and the if-session-expired attribute present in corresponding screen element the GlueX creates a new session then redirects browser to given URL pointed by if-session-expired attribute. If the if-session-expired attribute omitted, and session expired, new http session created. Then GlueX tries to show corresponging screen. If the screen can not be shown because wrong permissions the access denied screen is shown. Following example shows how to redirect browser to login-form screen if update-form screen can not be shown when user session has expired. <screen name="update-form" if-session-expired="view/login-form">
...
</screen>
Usually, every screen/action that can not be shown/performed because loosing user permissions in consequence of session expiring should contain if-session-expired attribute pointing to screen describing problem or to login-form screen. |
| selection for xml filtering. Indicates what parts of xml-model must be included into xml-content | |
| |
single filter criteria. The value of this attribute is XPath-like
expression, indicating what parts of xml-model
must be included into xml-content. Examples: /root/gluex.snoop//* |
| configures xsl stylesheet applying to the screen | |
| |
stylesheet name |
| |
|
| |
|
| |
|
| set header to http response | |
| |
header name |
| add header to http response | |
| |
header name |
18.3 The actions-config.xml file - configures Controller part of GlueX based application
<?xml version="1.0" encoding="iso-8859-1"?> <!ELEMENT actions-config ((action*, batch*)*)> <!ELEMENT batch (action*)> <!ATTLIST batch name CDATA #REQUIRED if-session-expired CDATA #IMPLIED > <!ELEMENT action ((constant*, parameter*, case*)*)> <!ATTLIST action name CDATA #REQUIRED paranoiac (true|false) "true" pass-all-parameters (true|false) "true" if-session-expired CDATA #IMPLIED > <!ELEMENT case (#PCDATA)> <!ATTLIST case id NMTOKEN #REQUIRED screen CDATA #REQUIRED > <!ELEMENT constant (#PCDATA)> <!ATTLIST constant name NMTOKEN #REQUIRED > <!ELEMENT parameter EMPTY> <!ATTLIST parameter source (request) "request" name NMTOKEN #REQUIRED as NMTOKEN #IMPLIED > |
Description
18.4 The principals-config.xml file - configures security system
<?xml version="1.0" encoding="iso-8859-1"?> <!ELEMENT principals ((group*, user*)*)> <!ELEMENT group ((granted?, denied?)?)> <!ATTLIST group name NMTOKEN #REQUIRED > <!ELEMENT user ((granted?, denied?)?)> <!ATTLIST user name NMTOKEN #REQUIRED > <!ELEMENT granted ((action*, screen*)*)> <!ELEMENT denied ((action*, screen*)*)> <!ELEMENT screen EMPTY> <!ATTLIST screen id CDATA #REQUIRED > <!ELEMENT action EMPTY> <!ATTLIST action name CDATA #REQUIRED > |
Description
| principals | |
| group | |
| |
name |
| user | |
| |
name |
| granted | |
| denied | |
| screen | |
| |
id |
| action | |
| |
name |
18.5 The resources.properties file - language resources
19.1 Idata
Often, in web application, it's necessary to save some data between user sessions expiration but during browser lifetime. One from way to do that is using session cookies (cookies with lifetime equals to browser lifetime). However, if user disable cookie in the browser, such approach can lead to crash of application or unpredictable behaviour.
The GlueX provides web developers with so called idata (immortal data) mechanism, allowing to save user data berween session expiration even if browser cookies are disabeld.
To use idata web developer must include in every URL gliex.idata request parameter containing idata string. This string can be obtained from xml content using root/gluex.idata xml generator as following:
21.1 Design Diagram
21.2 Permission Diagram
21.3 Application Workflow Diagram
|
GlueX Processing Directives significantly help to avoid code duplicating in XSL stylesheets making web design more simple to maintain and extend. GlueX uses two types of processing directives - static and runtime. Static directives work when new XSL transformer creating, runtime directives are parsed just after XSL transformation has performed. Since runtime directives are parsed every time after XSL processing they, to some extent, increase request processing time while static directives are parsed only at application startup. |
23.1 Pre-processing Directives
<gluex.include ...
<gluex.indirect-include ...
23.2 Post Processing Directives
gluex.runtime-include[] - runtime include
gluex.ststic[] -
static resource revriting
gluex.url[] - url
rewriting
gluex.action[] - action url
rewriting
gluex.screen[] - screen url rewriting
action - an object handling http request. When ActionServlet receives http request it translates url string to action name, appropriate action class is retrieved from action pool by action name then ActionServlet invokes service method on the action class.
validator - an object responsible for validation certain request parameter. In GlueX framework every request parameter is mandatory validated before further processing. GlueX API already contains several standard validators for primitive datatypes, string, etc. Also, web developer can create other validator types for application specific datatypes.
screen - result of XSLT processing. Every screen must be described in view-config.xml
idata - mechanism providing web developer with storage small application data surviving between session expiration even if stored and per-session cookies are disabled.
xml-content - filtered xml-model
xml-model - full xml tree representing current application state.
| JavaRealm (c) 2002. All Rights Reserved. |