Share via

Rendering Engine vs Forms on design time

  • Article

A couple of weeks ago I had an interesting design discussion about developing a smart client. This application is being developed with Windows Forms and is going to have more than a thousand forms. The center of the discussion was about creating the forms on design time -we can call it 'static' forms solution-, or creating a kind of rendering engine in order to paint the form on execution time - the 'dynamic' one-.

I advocated for the option of developing them in design time, but is true that in the last two or three years I have seen some apps -most of them were Java apps- designed with the rendering engine. My arguments were:

  1. We have a great tool for creating forms, VS.NET, that I don't want try to simulate or generate the data describing the form. I mean with the 'dynamic' forms we will need to create the rendering engine for run-time, but also a design tool, for the design-time. 
  2. Typically the 'static' forms will be richer, or harder to generate.
  3. The information needed in run-time about the layout of each form will make the 'dynamic' solution slower -we have 64 Kb lines with some branches-. This point can be improved caching that data.

I see three advantages on the 'dynamic' solution:

  1. Easier to deploy a new form or a updated one, but is something that can be improved on the 'static' solution with  a solution based on the updater application block.
  2. Seems to be easier to manage a high number of forms, be anyway is something to be developed. Also seems possible to improved this on the 'static' solution.
  3. The size of the binaries typically will be smaller.

Comments

  • Anonymous
    March 19, 2004
    How about a combination of the two. Generate static forms, but each in their own assembly. Load these 'assembly forms' when needed. On adding/updating forms you don't need to rollout a complete new application, only new forms assemblies.
  • Anonymous
    March 19, 2004
    I've always found that most applications with large number of forms really only have a small number of forms -- its just that the many are minor variations of the few. If you can also find that pattern, then building the few as static forms, while dynamically altering those few to make the many -- then you have the best of both worlds.
  • Anonymous
    March 19, 2004
    I would take a look at WFML. Seems this would fit the dynamic solution perfectly.

    http://windowsforms.net/articles/wfml.aspx

  • Anonymous
    March 19, 2004
    Why not just build a webservice backend and create the forms with InfoPath. Probably save you a ton of time and make the design time stuff a lot easier than winforms in VS.
  • Anonymous
    March 22, 2004
    The dynamic approach sounds <a href="http://xp.c2.com/YouArentGonnaNeedIt.html">YAGNI</a>

    Did you start to analyze the patterns of your forms? Are you sure about the current and future directions of your UI requirements?

    Think agile, start with the core forms, do it as usual (static), found the common pattern, extract it from your forms, share your build with admis and users, and get their feedback to start with the next cycle, probably you are in a best place to decide static vs dynamic.