On Apr 28, 2008, at 12:10 , Rickard Öberg wrote: > Me2: Well, there's two very different kinds of coding involved when > doing UI's. First there's the work needed to build widgets. This can > be > done in relative peace and quiet, and you can spend time making the > widget feature-rich and of high quality. The second is when you take > these widgets and put them together into a real application, which > deals > with a specific problem or domain. That's where speed really is an > issue, and you want to be able to quickly get things done, and try out > different ways of solving a problem. > Me: So scripting then would be good for the second, but terrible for > the > first? > Me2: Yeah, probably.
Me: There's two types of UI's: 1) UI's for custom made applications, tailored to the exact needs of a customer; 2) UI's for products, designed to be flexible and configurable for the target audience. For the first type, I agree with your thinking that scripting is good for glueing together standard components. For the second type, my experiences are that this creates a maintenance nightmare and hard to adjust UI's. Here you often have to accommodate requirements like: - having different user roles that see different parts of windows; - having configurable entities, where application administrators can add fields and relationships and change many settings that affect the UI; - ... In a past life, I've done a few products of the second type, and there we always came back to programmatically defining the whole UI in a non- scripting language because that was easier to maintain and test. On the other hand, such an environment does take more time to get started (learning curve wise as well as building a library and/or "DSL" for quickly creating such UI's). Greetings, Marcel _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
