I think the question of whether you choose to tackle such a problem from the top down vs. bottom up is largely dependent on what design principles you seek to move towards.
The biggest concerns that I have from your proposed design is that the application tiers (Eg. Presentation/GUI, Middle Tier, Database, etc...) are muddied. There is nothing inherently wrong with a single tiered approach to application design, however if an Architectural Requirement or Assumption is provided that this must be a distributed multi-tier application then your design is already violating these principles.
If you are identifying the Database procedure as a seperate Component in a Component Oriented Architecture then you are now also introducing tight coupling. This however would not be tight coupling if your Components are all to be designed with vertical integration in mind. This is another architectural assumption you will need to check on.
Beyond that I have actually worked on such projects before that employed a similar design scheme and have seen the pros and cons of this design approach personally. In my honest opinion the Cons outweigh the Pros here. The pros here are that changes to layout and components on a screen become a schema change. If you anticipate that power users will have the ability to deeply customize their screens then it is an ideal model, however if this is not the case then it can be constraining, especially when new requirements dictate specific UI features.
Look into component based web frameworks like ASP.NET or JSF to see if these might better serve your needs without violating MVC or other architectural principles.
It seems that your requirements indeed dictate that users will have the ability to create their own screens and forms. In this case, the bottom up approach is best.
This can still work with a multi-tier architecture and MVC model, but it will be complicated. The following are some key points to keep in mind during your design process:
Keep your screen builder modules seperate from other domain business logic and data access. Keeping these decoupled allows the application to be more maintainable and scalable as features are added.
The model in this case will be your application business logic, and data access as well as any domain model entities that you wish to declare. The screen builder model is seperate from this.
View (Screen Builder MVC and other Views)
The View will consist of the hard coded view pages as well as the entire Screen Builder module.
What does this mean?
Basically your View contains a completely sepereate self contained MVC design for user dynamic screens.
- Screen Builder Model: The data access to the stored procedure that returns the data on screen elements. This is also the domain model of the data returned.
- Screen Builder View: The code that generates the dynamic user generated view.
- Screen Builder Controller: The stored procedure, and other controller related tasks that mitigate between fetching and translating the model, and building the view for the user.
The controller in this case will be your web application framework controller.
The following model affords you a decoupled multi-tier approach by approaching the design of the dynamic form generation as a seperate MVC component operating inside of the web based MVC design of your overall application.