Philip Brittan's Blog

RAD Tool Let-down

Rapid application development tools let you put together a great-looking mock-up of your app in no time, but often are of little use for the production version of your system. Visual GUI builders and data-aware controls are two such culprits.

In yesterday�s post, I mentioned that all too often tools that help developers put out a really quick version of their application are frustrating to use when trying to create a sophisticated production version of the same application. This forces the developer to back-track and gives rise to the concept of the "throw-away" prototype, meaning that any effort put into the prototype has to be chalked up solely for the purpose of getting early feed-back but has to be tossed when it comes time to build the "real" system.

Today I'd like to illustrate what I mean with two very common examples of this phenomenon: visual GUI builders and data-aware controls. I have a love-hate relationship with them both.

By visual GUI builders, I mean WYSIWYG editors for laying out components in an application window. It's great to be able to sit down at a blank project and just start grabbing controls and laying them out on the screen, one after the other, changing positions if you change your mind about the layout, setting properties and seeing those properties immediately reflected in the representation of the window you are building. It is very satisfying to be able to put together a window so quickly, and it is much easier than instantiating all those widgets and setting their properties in code.

However, building the GUI through code does have some big advantages, and, personally, I almost never use a GUI builder for a production application. Here�s why. GUI builders give developers a component-by-component interface onto the window and treat properties as literal values. So, if I want to set the background color of a bunch of my components to red, I have to go and set the background color property of each of those components manually in the GUI builder. And, if I want to change the background color of all those components to something else, say orange, then I have to go through and change them all manually again. The GUI builder gives me a really quick way to put the window together but ends up with a pretty brittle design that requires lots of manual labor to make subsequent changes.

If, on the other hand, I set the background color of those properties in code, I can simply make a variable that represents the background color, set the color properties of those components to the variable, and then set the variable to red. It takes more time to set this up, and it�s a non-visual development process, but my design is now more flexible and I can change the background color of all those components by simply resetting the value of the variable to orange. This is exactly the benefit that Web apps get from CSS, and Joshua Marinacci posted a great article yesterday, CSS and Swing, about how you can achieve similar results to CSS in a Swing app by making a properties file that is read in at run-time. The problem, however, is that this takes you out of the GUI builder and into the code. I want a GUI builder that can handle this for me. Fortunately, many GUI builders generate source code which allows you to take a hybrid approach: use the GUI builder to generate basic component instantiations and properties, and then modify the generated code by hand from there. Still, I wish I didn't have to switch modes -- and that approach is generally a one-way street.

This problem can be more much sophisticated than just setting properties on components. I find that I often want to create bunches of components programmatically, with a loop, reading component specs from a database or config file or based on some algorithm. At that point, even a CSS mechanism can�t help me. I long for a GUL builder that can give me a visual environment to see what my window looks like at all times but to be able to create and manipulate components algorithmically as easily as I can create and manipulate them visually.

I feel similarly about data-aware controls. Manually wiring up GUI controls to database values is admittedly a pain, so data-aware controls are also a great boon in helping developers get a basic version of their app up and running quickly. However, I have rarely written a sophisticated data-driven app where I didn�t need to massage data while reading or writing from/to the database. Hard-wiring controls to the database tends to be pretty brittle. So, once again, for production-quality apps, I have to abandon the data-aware controls for a manual, code-intensive process that gives me the flexibility I need.

I would sorely love to have versions of these tools that can support the flexibility I need for production systems as well as the RAD capabilities I value for prototypes without having to backtrack and change gears along the way. Maybe such things exist, but I haven�t seen them.

Comments

• Thin client rich GUI development tool
  Philip you may want to check out a product called XTT (XML Tunneling Technology) from InsiTech Group.

  XTT is an application development framework for creating distributed, ultra-thin, rich GUI J2EE applications. XTT provides standardized patterns of development and intuitive wizards to enable the rapid building of distributed Java forms in a manner similar to Visual Basic� or PowerBuilder�.

  The XTT Framework is targeted at building enterprise-class applications with complex transaction-oriented user interfaces, required in vertical markets such as health care, financial services, insurance, and manufacturing. The XTT Framework delivers a robust RAD environment for creating rich, ultra-thin, Swing-based GUI J2EE applications with the benefit of having only a single code base to manage. XTT integrates with Sun ONE Studio, NetBeans and JBuilder IDEs, for integrated development and deployment of J2EE and rich GUI J2SE applications.

  The Free Community Edition of XTT can be downloaded from www.netbeans.org or www.insitechgroup.com. I think you will find that XTT’s rich feature set solves the problems of RAD Tool let down.
  

  Posted by: jvillano on October 15, 2003 at 12:37 PM

• Thin client rich GUI development tool
  The question is not one of architecture. My own company, Droplets, makes a rich thin client framework. So I�m not lacking a way to get a rich UI to the user. Our product integrates with Sun ONE, JBuilder, WSAD, JDeveloper, and other IDEs. I know what those environments are capable of.

  What I�m looking for is a RAD tool that supports a seamless integration of visual, configurational, and algorithmic GUI building. We�d gladly also support a tool like that.

  Philip
  

  Posted by: pbrittan on October 15, 2003 at 06:00 PM

• MS
  What can we learn from previous experience? Surely this is not a new problem. In the VB world, was the inevitability of not being able to touch GUI builder code just accepted? Any other GUI toolkit try to come up with a solution?

  Posted by: sumitkishore on October 15, 2003 at 10:39 PM

• Its about designing..
  I'm a bit surprised about your blog; since my reply to your previous blog mentioned these same problems including a solution, you missed that post?
  The problem is discussed in-depth on http://uic.sf.net and the tools and widgetsets provided there offer a solution.

  In short the solution is based on the idea that the GUI stuff (the boring code) is done in a designer where you create a panel which becomes a class, you extend from that class doing your customizations, including Gui handling and (if you want) adding of custom widgets etc etc etc.

  In our company we have sped up the creation of rich GUI clients to such a dramatic rate that RAD _is_ the development and we can alter the GUI while the client is looking over my shoulders. Letting him play with the result after an 'ant run'.

  Posted by: zander on October 16, 2003 at 06:17 AM

• Its about designing..
  Zander, honestly I had written my blog entry above long before your post to my previous entry (it's something that's been in the back of my mind for a long time). Secondly, I don't immediately see how your earlier reply relates to my entry above, but I will check out your project and that may clear things up. Thanks.

  Posted by: pbrittan on October 16, 2003 at 07:03 AM

• Data aware controls should bind to the Object Model
  As you say binding Data aware controls to a database is problematic. However data aware controls that bind to your object model are much better (provided Data is in your Object model in the format you want it).

  Our Kanabos Framework does this (http://www.kanabos.com)

  Posted by: c_armstrong on October 16, 2003 at 09:28 AM

• Data aware controls should bind to the Object Model
  Without really having used your application (the screenshot was a major turnoff) I'm worried that this will either provide just a partial solution or will move the intelligence to just another language.

  Having fixed many GUis after the first implementation was done I have (for example) moved checkboxes around or inverted the meaning to make it more readable. That means the GUI code changed; but the logic behind it does not, or just changed a little.
  This becomes quite hard in your proposed design.

  Second point is that only data-driven GUIs can be created like that, which means the rest still has to be done manually.
  After trying (I managed a couple of end-thesis students that implemented this to a full-blown app) I dare say its more trouble then its worth.

  That said I find the idea attractive and think this has potential for further investigation.

  Posted by: zander on October 18, 2003 at 02:59 AM

• Its about designing..
  No problem :)

  The link between my post and this Blog is about choosing one environment that will support the entire life-cycle of your application. The second link is to have mature widgets and a good way of working that is not only supported but encouraged by the tools.

  Creating a new GUI with UICompiler works like this;
  1) you get a set of requirements and mock up a UI, probably one big one with loads and loads of panels.
  2) Compile it with the debug flag enabled (an ant flag) and show the result to the client. Its started with 'java MyGui'.
  3) Alter GUI after comments and go to 2
  4) Take apart the GUI so you have more managable parts; its better to have 1 class for each tab, for instance. This is totally optional; but is just good practice, this means you get a series of UI files.
  5) Write extending classes which can fill the GUI, instanciating the different tabs and calling an addTab for example.
  6) Whenever a GUI problem occurs start up the designer again and alter any part; just recompile and it works.
  7) Write properties files for your translations; all you need to do is take the strings as they are on screen on the left and the translation on the right.

  Posted by: zander on October 18, 2003 at 03:12 AM

• Data aware controls should bind to the Object Model
  You add Datapanels (the Data aware components) to the Screen using standard java code. There is NO other language. To change it just edit the sourcefile, as many times as you like.

  Didn't expect you to like the screenshot; very different priorities from UI Compiler... The aim is for a simple layout that allows localization (words and labels can change size with out messing up the layout).. and to have a multi-screen app, rather than cram as much as possible onto one screen.

  You second point is valid though. The Framework is aimed at data-intensive applications. I wouldn't suggest using it for a text editor app for example. You can put whatever you like on the screens (as said above they are just java files) but you will have to manually code anything not data related.

  Posted by: c_armstrong on October 18, 2003 at 05:19 AM

• Yes, RAD promises rain and leaves you dry
  I concur on the RAD letdown experience. Some time ago, I was tech lead and Java architect in a big telecom firm in New Hampshire. Here I was going through great efforts to properly architect the Java system when a couple of Java juniors used the RAD interface to quickly croft together really good looking interfaces that sopke to the back-end.

  They went around me and showed what they did to the manager who did not understand all the work required for the middle tier to give it flexibility for a production environment. Politics ensued and I was removed from the project. I quit the next day.

  As far as I know, they never went anywhere with their Java project, and I went on to greater and better things. But I am embittered at how RAD can give a false sense of progress to those not bright enough to understand what is required to make a production-class product.

  I am gratified to read your article, as I have myself never fully relied on the RAD to do production-level work, and everytime I did I wound up dealing with more issues and problems that killed any suppsosed "time savings" that RAD promises.

  There is no substitute at this juncture for doing the code for your GUI.

  And this, by the way, is not limited to Java either. Neary any sophisticated GUI app, whether it's a web site or a standalone, requires touching the code directly. There are no magic bullets except perhaps in very restricted domains.

  So let's set RAD aside, roll up our sleeves, and write that code!

  Posted by: flajann on October 18, 2003 at 09:37 AM

• 门诊
  癌症
  肿瘤
  胃癌
  肺癌
  肝癌
  白血病
  鼻咽癌
  大肠癌
  宫颈癌
  膀胱肿瘤
  食管癌
  乳腺癌
  抗癌新药
  肾癌
  胰腺癌
  胆囊癌
  甲状腺癌
  脑瘤
  恶性黑色素瘤
  恶性淋巴瘤
  阴道恶性肿瘤
  卵巢恶性肿瘤
  绒毛膜癌
  子宫内膜癌
  阴茎癌
  睾丸肿瘤
  前列腺癌
  癌症
  肿瘤
  胃癌
  肺癌
  肝癌
  白血病
  鼻咽癌
  大肠癌
  宫颈癌
  膀胱癌
  食管癌
  食道癌
  乳腺癌
  抗癌新药
  肾癌
  胰腺癌
  胆囊癌
  直肠癌
  甲状腺癌
  脑膜瘤
  恶性黑色素瘤
  恶性淋巴瘤
  阴道恶性肿瘤
  卵巢癌
  绒毛膜癌
  子宫内膜癌
  阴茎癌
  睾丸肿瘤
  前列腺癌
  肝病
  肝病治疗
  乙肝
  乙型肝炎
  丙肝
  脂肪肝
  肝纤维化
  肝硬化
  肝性脑病
  紫杉醇注射液
  开普拓
  美罗华
  赫赛汀
  天地欣
  香菇多糖
  艾普升
  宁得朗
  康士得
  诺雷得
  瑞宁得
  芙瑞
  瑞婷
  法乐通
  易瑞沙
  多吉美
  特罗凯
  泰勒宁
  路盖克
  皮肤病
  银屑病|牛皮癣
  白癜风
  尖锐湿疣
  脱发
  痤疮|青春痘
  皮炎
  灰指甲
  疤痕|瘢痕
  疱疹
  系统性红斑狼疮
  色斑
  艾滋病
  丽科杰
  里亚美
  明欣利迪
  疣迪
  明竹欣
  无为白癜风胶囊
  维阿露
  白癜净
  达霏欣
  狼疮丸
  适今可
  克银丸
  云香十五味丸
  化瘀祛斑胶囊
  疤痕敌
  每宜
  新药网
  肺癌
  鼻咽癌
  食道癌
  胃癌
  肝癌
  大肠癌
  乳腺癌
  卵巢癌
  膀胱癌
  白血病
  胰腺癌
  宫颈癌
  神经内科
  癫痫
  帕金森病
  老年性痴呆
  脑血管病
  多发性硬化症
  偏头痛
  小儿脑瘫
  心血管
  高血压
  高血脂症
  心血管疾病
  精神心理
  精神分裂症
  抑郁症|焦虑症|躁抑症
  强迫症
  睡眠障碍
  多动症
  神经衰弱
  糖尿病
  类风湿
  瑞美隆
  肉蔻五味丸
  喜普妙
  怡诺思
  优克
  恩经复
  申捷
  重塑杰
  施捷因
  神经妥乐平
  七十味珍珠丸
  珊瑚七十味丸
  郝智片
  参蛇偏瘫胶囊
  扎冲十三味丸
  洛斯宝
  安理申
  金思平
  泰舒达
  珂丹
  利鲁唑
  力如太
  静灵口服液
  地牡宁神口服液
  健儿贴
  哈伯因
  肺癌
  小细胞肺癌
  非小细胞肺癌
  肺膦癌
  肺腺癌
  香菇多糖
  瑞宁得
  复方斑蝥胶囊
  金复康口服液

  癌症博客
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  中国癌症之家
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  癌症博客之家
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  中国癌症博客
  癌症博客
  癌症博客
  癌症博客

  癌症博客
  癌症博客
  癌症博客
  癌症信息博客
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  癌症博客网
  癌症博客
  癌症博客中国人
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  中国癌症博客
  癌症博客
  癌症博客
  癌症博客
  癌症博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  抗癌博客
  抗癌博客
  抗癌博客
  抗癌博客
  抗癌博客
  抗癌博客
  抗癌博客
  抗癌博客
  抗癌博客
  抗癌博客
  抗癌博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  特罗凯博客
  易瑞沙博客
  易瑞沙博客
  易瑞沙博客
  易瑞沙博客
  易瑞沙博客
  易瑞沙博客
  易瑞沙博客
  易瑞沙博客
  易瑞沙博客
  易瑞沙博客
  易瑞沙博客
  易瑞沙博客
  易瑞沙博客

  Posted by: bxz on August 17, 2007 at 01:37 AM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: wowleveling3 on December 13, 2007 at 05:59 PM

• 网络营销软件
  网络营销软件
  网络营销软件
  群发软件
  群发软件
  ---
  群发软件
  网络营销软件
  论坛群发软件
  网站排名软件
  群发软件
  推广小助手破解版
  论坛群发软件
  网站排名软件
  群发软件
  网络营销软件
  网站推广软件
  信息群发软件
  论坛群发软件
  信息群发软件
  博客群发软件
  qq群发软件
  邮件群发软件
  博客群建软件
  企业名录搜索软件
  信息群发软件
  邮件群发软件
  论坛群发软件
  博客群发软件
  网站推广软件
  网络营销软件
  全能营销破解版

  Posted by: uuok999 on December 20, 2007 at 12:19 AM

This work is licensed under a Creative Commons License.