Design review of project's structure

Hi all,
It was really hard-working week, so I'm writting my post not as usual. But, anyway, I'm going to tell you, my dear reader, about work on design of project's structural and behavioural aspects.
So, after I have made an overview of subject domain (i.e. localization tools) I started phase of project's design. On this pahase I was focused on developing robust and flexible model of project's structure. I tried to figure out the project's structure for few times, and each next time I was so far to right decision. But something was bugging me, each of next decision seemed to me frightfull, and I was starting everything over again. 


Nevertheless, I found the way, so I'm going to slightly open the curtain, wich is covered over this.

Initially, the project structure can be represented as a set of interrelated components. Links between these components may be different. Also, components themselves, might be devided on two groups: inner and outer.

Inner components, which is represents the core of project. They should be developed from scratch. Together, these components will work as some kind of localization tool. The main function of that tool will be obtaining  localized GUI messages, which is stored in resource files and providing an easy way for accessing them directly  from velocity templates. Also, it would be great to have such tool as flexible as possible, in fact, that tool should support an easy way of changing its configuration by other components.

And, in turn, outer components represents an existing servlets filters (into which will be integrated functionality of configuring inner localization tool) and message resource files (which will be accessed through localization tool). I can say, that project components structure was designed to provide the easiest way of integrating localization tool into initial setup and update wizards. Next figure shows as diagram which describes project structure:

Lets make a review of this diagram starting from outer components ('cause, I suggest that most of you have a questions about it). Outer components are:

• UpdateFilter and InitializationFilter;
•  messages.properties* files.

As we can see at picture above, UpdateFilter and InitializationFilter are the components which are representing an appropriate existing servlet filters. Basically, these filters are used for managing the general work flow of both wizards, they control navigation between pages within wizards, they create and render velocoty templates for wirads pages and do job of preparing installation/update process, execute these processes.

Next outer components are named as messages.properties*. These are text files which will contain localized messages for both wizards. Those files are located under /WEB-INF directory of OpenMRS web app (see Analyze of existing L10n tools for velocity templates). Example of their content is shown on related text notes on diagram above.
 So, I think that everything so far is clear. And I can begin description of such "lovely" thing as inner components, they are:

• custom localization tool;
• filter utility.
  

As you might guess from component's layout the key component of structure is custom localization tool. This is a central (in both meaning of this word) component of the project structure. All magic will be around this component. It accesses resources bundles and obtains messages therein.

Such component will be implemented as sub-class of velocity’s ResourceTool class. Creating of sub-class, instead of using standard tool can be explained with need to load resources outside the web-app classpath. For achieve this we will simply override get(Key) method, that is responsible for loading the resources. When we will implement this method ,we should take care about loading messages.properties* from file system by specified path.

Using of this approach will allow as to type $locale.install.method instead of $l10n.get(‘locale.install.method '), for showing localized content.

Also component will contain map with resources bundles for each locale. Moreover,  it should be configurable. This means that this component should provide opportunity to easily change its parameters in run-time.

 And the last important inner component is filter utility. This component should manage locales parameters. It will check whether need to save user’s selected language, will retrieve it locale from http session if need, and will store it into DB as admin’s user property. Also it will try to retrieve that persisted language in case of DB update wizard running.

Since we will use custom velocity resource tool we will need to configure appropriate toolbox.  Admittedly, this component will manage configuring of localization tool by using java API. For this we will use EasyFactoryConfiguration class from velocity framework. Filter utility will be implemented as java class (or set of classes under the same package). Access to localization tool component will be provided through this one.


That is all for now. I think, that we have reviewed all bottlenecks within project structure, 'cause it is very important to begin coding on projec, while investing as much as possible time to design.


With best wishes, Taras Chorny.