Forum OpenACS Development: Re: OpenACS Roadmap 5.3
- Designing data-intensive Web applications / Stefano Ceri ISBN 1-55860-843-5
- Agile Web Development with Rails - Dave Thomas, David Heinemeier Hansson - ISBN 0-9766940-0-X
I haven't finished them yet but both books give me a lot of insight where a decent web application framework like OpenACS could move on to.
Some examples:
- Object Oriented Scripting
- Extend API and Documentation Browser for Packages
- Integrated Testing for MVC and Performance
- Graphical Modelling and Generative Approach
- DRY-Concept
- Object Relational Mapping
- Tag-Builders
- Message bar
- Convention over Configuration
- Context sensitive help
Some of these things are available in OpenACS but more important than the existence is the question how and to what extend. Here some examples.
For instance extending the API browser to display the model and defined tags for a package would be important (partially this is solved with XoTCL in future). Also for convenience I like the approach in Rails to provide the package API right in the page you develop. There is a toggle to turn it on and off. You can see all classes, methods and files without much navigation.
We have a package builder but it is unusable. A graphical approach would be fantastic. Thus OAK is a good start but is not promoted enough in the community. I'm not sure whether it was created modular enough that it could be extended easily. In WebML you can define your model via ERD and your pages via Hypertext Diagram and generate a great amount of code before you get started with real stuff. I don't think we need a full fledged model driven architecture. Rather there is need for rapid prototyping to provide customers with something they can play around before we dwelve into the real implementation.
We have testing but its not integral in the toolkit. Creating a new object should generate skeletons for testing the lifecycle of the object. A nice feature in Rails is that they seperated the databases handling depending on what you do. Thus with one installation you have a development, a test and a productive database and don't need to work with several installation. You simple clone your development database and can run the tests on some predefined data (called fixtures).
We have database handlers but lack of an extra layer that does the object relational mapping like Hibernate does or ActiveRecord in Rails. This would allow others to extend OpenACS with support for other databases. The ActiveRecords also provide countless nice methods for model validation. Another nice feature is that Rails provide autogeneration of forms depending on the model.
We should use more often tags. Right now most of the stuff is defined in the controller. There are many things that are view really and should be made available in the ADP instead. Like formatting.
We could use the message bar and progress bar much more often. I think its always a good practice to give information on what the system is doing. Thus extending the message bar to give support for different admonitions like those defined in docbook (note, important, tipp, caution, warning) would be great - maybe even with recognisable icons. Maybe we could even integrate the ad_page_contract valiation with that and provide i18n-ized text. Still now we have some stuff in core that is not i18n-ized.
We have already many conventions in OpenACS. It is important to dextend the documentation to explain them to new developers. Maybe there is even a much greater need for conventions like table, columns, classes, objects, method/procs, variables, tests ... naming, SQL, plpgsql and permissions conventions. Most of that stuff could be included in the code generation process in order to unburden new developers. Conventions will make OpenACS much more attractive, readable and reusable.
Please don't get me wrong. There are many other important things and I am not pointing my finger to anyone or saying that the other stuff is less important. All I am saying is that I found some inspiring features OpenACS could benefit from and maybe I am even able to help implement them for future versions of the toolkit.
