Separation of logic from presentation: HTTP variable names?

Question

Hello all,

This could probably be considered an academic question, rather than a real world one - but throwing it out to see if anyone has any great ideas! We all know that keeping the business logic of an application separate from the presentation is a good idea (I'm looking at web-apps atm), but there needs to be an understanding between the business logic for what HTTP variables to expect (and then process) and the variable names which are sent by the presentation layer.

Is this simply a matter of telling the designer what variable names to use in a template? The template doesn't need to know what the variable names are (unless using them for JS/CSS selectors), so why should they be 'hardcoded' in there. Or should the business logic put the names into variables to be printed out? Another layer of complexity for the templates?

Does anyone have any experience of this, or thoughts on how to deal with it?

Thanks, Allan

Answer 1

Hi Allan,

My thoughts ... I guess it depends on the developer. Whenever I build apps, I , as you suggested, seperate the business and view logic, and usualy define a ViewModel. The viewModel then becomes the contract between business logic and the view. This allows both teams (UI and business logic developers) to develop independantly and of course allows easy testing etc..

I appreciate there are various approaches to view logic seperation, but, through experience if you can define a contract bewteen the two (in whichver form it takes depending on what pattern you are using) it makes development easier, especially when you have seperate teams building sperate components.

Answer 2

When I'd previously worked in web-development (currently I'm in admin/support) the problem was that the designers couldn't get their heads around the idea of using placeholders which would be substituted later - and for some complex layouts (e.g. a dynamic accordion type hierarchical navigation menu) there was a chicken and egg problem around designing the parts of the stylesheets which handled animation and functionality vs controlling fonts and colours.

Even with the most capable of designers, the tools they use don't lend themselves to solving the problem.

The approach we ended up taking was that the developers would provide examples of HTML fragments which the designers would then build the pages around, and then the developers would replace the fragments with the dynamically generated content and clean up the style sheets, merging any classes.

It was the most pragmatic solution we could arrive at.

C.