This week I started to implement a new actifsource feature. A repository for generic actifsource applications. The idea behind this is to provide an easy way to distribute models, frameworks and templates solving common tasks. We decided to provide a special import wizard, which downloads and installs the application. One challenge was to manage the installation of required features and plugins. Our applications may require findbugs or other third party tools.
To solve this issue I decided to manage the information about the features and the updateSiteURIs along which some other information in the repository. This way the wizard can check the current feature list, add missing updateSites und the required dependencies. Since svn does a good job in managing source code, I decided to use the eclipse team project set to manage the download and import of the projects into the workspace.
Since we need a way to define and store additional dependency information, I defined a small actifsource model. One big advantage over using a textfile are the resource formfieldeditor and the actifsource validation, which shows you where the application definition is incomplete.
After this I had to think about from where the generic app import will obtain the data. I decided to implement this as a service. If the service is encapsulated properly the importer doesn't have to care about where the information comes from. Both service data classes, the service interface and the service implementation stub can be generated by actifsource templates. It is also possible to write the wsdl. I first started using the eclipse j2ee wizards, but very soon I found out that it is not very convenient doing the updates by hand. I'm sure this is a good case for a generic application.
Providing templates for building simple java beans (value objects) out of the class defined in actifsource, would be easy. I talked about this in my last post. Using a similar model as shown in the Simple Service Tutorial combined with an enhanced version of the DataClass-Templates will do the job:
The actifsource class
To solve this issue I decided to manage the information about the features and the updateSiteURIs along which some other information in the repository. This way the wizard can check the current feature list, add missing updateSites und the required dependencies. Since svn does a good job in managing source code, I decided to use the eclipse team project set to manage the download and import of the projects into the workspace.
Since we need a way to define and store additional dependency information, I defined a small actifsource model. One big advantage over using a textfile are the resource formfieldeditor and the actifsource validation, which shows you where the application definition is incomplete.
After this I had to think about from where the generic app import will obtain the data. I decided to implement this as a service. If the service is encapsulated properly the importer doesn't have to care about where the information comes from. Both service data classes, the service interface and the service implementation stub can be generated by actifsource templates. It is also possible to write the wsdl. I first started using the eclipse j2ee wizards, but very soon I found out that it is not very convenient doing the updates by hand. I'm sure this is a good case for a generic application.
Providing templates for building simple java beans (value objects) out of the class defined in actifsource, would be easy. I talked about this in my last post. Using a similar model as shown in the Simple Service Tutorial combined with an enhanced version of the DataClass-Templates will do the job:
The actifsource class
The new template
The generated java bean for the use for data transfer
As you can see we often need some kind of data classes in a specific format. It's also possible to generate the service calls and everything else including the setup code of the service client and server. I think this would be really a useful application for the actifsource generic application store, generating the transfer classes for your simple model. I say simple model, because if you have a more complex environment, you probably won't have a 1:1 relationship between your model classes and the data classes. In this case you will most likely write your own templates doing the transformation/mapping between model and code.
No comments:
Post a Comment