Long ago I wrote an article about what should a CASE tool should include ( by that time Delphi was already going the way of the Dodo bird ).
The article was thought in the context of providing a complete feature set for large business applications.
Rereading the article, nine years after I wrote it, I realize Cuba platform is very close to my dream tool . Few of the features are missing:
Error messages as separate objects
Integrated help
Modules/Packages ( for large applications)
Prebuilt lookups ( that would be like a minimal view accepting parámeters , so you wouldn’t have to write queries several times)
So, those are my 5 cents regarding improvements for CUBA
http://edn.embarcadero.com/article/33887
Good article, could be a high-level functional specification for a platform. Didn’t you try to implement it?
In the CUBA context, I think such centralized dictionary is overkill for most potential usages. It definitely brings more order to the application and the development process, but it comes with a price of lesser runtime performance and development flexibility. A CUBA application requires just a few configuration files, and that is enough for Studio to parse and show all project artifacts in a centralized UI. We position CUBA somewhere in between low-level tools like Delphi (or Java+frameworks) and ERP platforms, and a dictionary stored in the database would be an unnecessary bias towards ERP.
As for your suggestions for features, I think the most important one is modularity. Currently, we provide some level of modularity: you can select what base projects (i.e. functional modules) you need, and you can create your own base project. But due to the non-trivial magic required for config files modification, Studio can automatically use only one custom base project and several from the platform. We will certainly address this issue in the future.
An ability to create integrated help is obviously a useful feature. We never thought about it, thanks for the idea.
Messages as separated objects - not sure, I tend to think that it may bring an unnecessary rigidity.
And about lookups. We already have two standard ways for looking up related entities - through lookup screens and through optionDatasources connected to picker fields. Both are quite simple in development. Perhaps you are right, some more generic mechanism would be convenient. We will definitely think about it when we implement tons of requirements that have no simple solution in CUBA yet 
Indeed , I did give it a try, but at that time building it was very hard: ECO ( the persistence layer for Delphi ) was quite expensive and I couldn’t afford it Implementing itwith ODBC required a lot of effor and time so I ended throwing away the project.
So , I agree with you , a full dictionary is a lot of work and it’s probably overkill. Nevertheless, it would be nice to have a search field or a filter field in both the class and screen sections. Hopefully it will not be too hard to implement.
Messages: at this point I am too new with CUBA to make any judgement. Translation is the main reason to have them as separate objects. So, as long as there is some way to translate them, there is no real need to have them as separate objects.
Pre built lookups : They ar probably not needed since CUBA can create views which accept parameters.
Hi Armando,
> it would be nice to have a search field or a filter field in both the class and screen sections.
You have it - press Alt+/ or the looking glass button in the tools panel.