note dfaure <blockquote>I think it is never trully possible to seperate design and logic </blockquote> IMHO, you should take care to differentiate applicative-logic and GUI-logic, and consider 3 abstraction layers: <ol> <li>HTML-Template data, aka GUI elements, look-and-feel, skins, whatever you call it.</li> <li>GUI-logic, tiny code elements, totally dedicated to data appearance. There you'll use HTML::Template modules or equivalent to handle HTML data from above layer. Taking an OO-approach, you may define here a "widgets" hierarchy of specialized objects.</li> <li>Lastly, You'll have applicative-logic dedicated to manage applicative-datas and providing them to users through the help of above layer functionnalities.</li> </ol> <readmore> <code> +-------+ | Users | +-------+ ^ | v +------------+ +-----------+ | HTML-Datas |-->| GUI-logic | +------------+ +-----------+ ^ | v +-------------------+ | Applicative-logic | +-------------------+ ^ | v +-------+ | Datas | +-------+ </code> </readmore> Pro: Design and logic are separated. Cons: You'll have to stricly follow the rules of responsability separation when developping the differents layers. Anyway, you'll have a bit more code to produce and support all caveats involvde (more code => more bugs => more tests required => less time). This kind of slicing gives you the basements to build applications decribed as 'Model-View-Controller' in Design-Pattern litteracy. Updated:corrected some typos and added schematic. <div class="pmsig"><div class="pmsig-326467"> ____ [id://262941|HTH], Dominique My two favorites: If the only tool you have is a hammer, you will see every problem as a nail. --Abraham Maslow Bien faire, et le faire savoir... </div></div> 371039 371039