Resource and Substitution Realignment in OpenInstaller Introduction The primary goal of this project is to design/architect a common mechanism for loading different types of OI and install developer resources. In addition, the following set of issues are also tackled as part of this project
- Replace different substitution methods in the openInstaller with one standard technique.
- Eliminate the need for full duplication of *.prefs
- Remove the need to carry full PSP.xml for tweaking the display
Hard requirement
- Must not break backward compatibility.
We have already shipped a product which defines the limitations we must work with. These assumptions are:
- Old syntax must retain the original meaning
- Old ui.prefs must exist and must be parsed as
- Tweaks to the ui
- Resource bundle messages to be recognized as such
Initial analysys Type of Resources
- Model resources
- View resources
- OI resources (such as ResourceMsgs)
- Install developer resources
Substitution mechanisms
- :(
- $var in UI pages
- Freemarker based substitution
Resources in openInstaller
| Resource Type |
Resource |
Template used |
Substitution/Loading mechanism used |
| openInstaller view resources |
*.ftl |
freemarker template |
DataModel |
| openInstaller and install developer view resources |
*.prefs |
java properties files |
Java properties/resource loading + Freemarker template substitution |
| openInstaller and install developer resources |
*.properties |
java properties files |
Java properties/resource loading |
| openInstaller engine resources |
*.jpgs, *.gifs |
image files |
Java resource loading |
| openInstaller model resources |
*.xcs |
OOR schema based xmls |
:( |
Jspwiki style: sortable
Use Cases Possible solutions (Old)
- New substitution engine token type, e.g. :[dm:mq:VAR] which reads from mq.prefs (where does this go? what if there need to be more than one?)
- Breaks backward compatibility unless resource translators and versioning are introduced tranparently.
- Maybe move to all-XML format for all resources i.e. *.prefs becomes XML too so we can start versioning it.
- New DataModel syntax for specifying overwrite e.g. "overwrite:listname:newelement1" - Rejected because of backward compatibilty requirement
- Specify bundlename in EE - Longer term
- Change ${} usages in view files to use existing substutition syntax type, e.g. :[some.var.name] (this is already implemented in the "simple" substitution)
- Think about how to split out into multiple data models and what that means - Partly implemented
- Current data model for View side assumed only one singleton instance. Summary report generation fed in it's own data into this Global namespace. Some product definitions were stuck into this view side model when they should have been in the data side space. This is partly fixed by making TemplateProcessor non-singleton and multiple instances using their own instance of the 'DataModel' class.
|
