 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / GUI / June 2004Toward smarter Layouts
One thing I have found incredibly time consuming and ditzy is the way you have to create Label objects for every piece of labeling text on the screen. I can see at least two more convenient ways of handling it: 1. allowing you to attach a name to each component. Then in the layout, specify if and where you want that name to a appear relative to the component. 2. In the add call, put in the naming string, and where you want it to appear relative to the component. Let the LayoutManager build the Label objects as needed. Back in 1980 I implemented self-labeling objects in Abundance layouts for the Apple ][, and I can't believe nobody has yet done it for Java. I did a crude version of self labeling object for Java that used a GridBagLayout with rows and cols multiplied by 3 to leave room for the labels.  SignatureCanadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. > One thing I have found incredibly time consuming and ditzy is the way > you have to create Label objects for every piece of labeling text on [quoted text clipped - 15 lines] > GridBagLayout with rows and cols multiplied by 3 to leave room for the > labels. Hallo Roedy, what you did is what anyone with a bit of sence would do before starting on a project. And you could go much further than that in building your own components. Gerard >what you did is what anyone with a bit of sence would do before starting >on a project. And you could go much further than that in building your >own components. The other problem is the incredible amount of application level code you to deal with very ordinary things: 1. copying back and forth between computational variables and gui variables. 2. validating text to make sure it is numeric, in bounds, has right number of decimal places etc. 3. checking for mandatory fields. 4. composing SQL record descriptions. 5. taking info from SQL ResultSets and putting it back in gui objects. This is a ruddy nightmare vis a vis maintenance. There are perhaps a dozen lines needed for every field, and that is for the simple ones. This should all be done declaratively, the way you do it in Abundance. Further, it should be done with style sheet logic, rather than explicitly nailing down every detail on every declaration. It then becomes the component's job to make sure only valid data leaks out. It becomes the component's job to provide error messages for the user. In an app I am writing now, I am experimenting with changing the background color to indicate good/bad on each field. Unfortunately there are no tool tips in AWT I could use to give error messages on request, and no setFocus. SignatureCanadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. >>what you did is what anyone with a bit of sence would do before starting >>on a project. And you could go much further than that in building your [quoted text clipped - 14 lines] > > 5. taking info from SQL ResultSets and putting it back in gui objects. I am currently working on a database application with Swing front-end. I decided to use Torque (http://db.apache.org/torque/), which is a layer on top of JDBC. The DB schema is written in XML and Torque generates a whole lot of DB access code from the schema using Velocity (http://jakarta.apache.org/velocity) templates. But the concept described below could, of course, be used without Torque's DB access layer. I have gone further than that and generated GUI field specifications from that too (just by adding a few more Velocity templates). Using Jakarta Commons Configuration (http://jakarta.apache.org/commons/configuration/) additional manually entered properties can easily be entered in a second XML config file. For VARCHAR columns the GUI fieldspec contains, for instance, the length of the field. For NUMERIC fields, I generate a format (###.##). From the XML schema I also know whether a field might be a required field. The label text information is read from ResourceBundles - the properties are tied to the FieldSpecification by naming conventions. I have created a class FieldSpecification, which keeps all this config information for each display field, and based on that, associates the right formatter with a JFormattedTextField. For instance, for String fields, I have a length formatter, which doesn't allow exceeding the specified number of characters. I have another class, which creates the field and its label based on the FieldSpecification and returns those to the GUI. Unless otherwise instructed, a JFormattedTextField or JCheckBox is created depending on field type. As I keep on using the same components and virtually always lay them out in the same way, I have written a layout manager, which requires me only to add the components (alternating label, field, ...), which are then displayed in two columns. Error messages for required fields are produced from SQLException and some error message parsing :-( . The additional information I pass in a wrapped and re-thrown exception might contain the field that violated a NOT NULL constraint. The field is identified via the generated FieldSpecification used to parameterize a localized error message using java.text.MessageFormat. Thus, the main GUI application code is not cluttered by layouting or error handling code. Even without using Torque as DB access layer, you could use a similar generalistic approach for creating a higher abstraction of the GUI. SignatureRegards, Tarlika Elisabeth Schmitz >Error messages for required fields are produced from SQLException and >some error message parsing :-( . The additional information I pass in a >wrapped and re-thrown exception might contain the field that violated a >NOT NULL constraint. The field is identified via the generated >FieldSpecification used to parameterize a localized error message using > java.text.MessageFormat. Eventually you need to get to where you have central repository about each field where you declare everything there is to know about displaying, and editing it. Then whatever code to implement those policies can be generated as needed dynamically AND what is even more important, you can be sure that is done consistently. It seems to me that the same information could be used by the database, the servlet and an Applet data gatherer to do validation at each stage, including keystroke validation. Ditto prompts and additional descriptive information can be made available on demand. SignatureCanadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. > >Error messages for required fields are produced from SQLException and > >some error message parsing :-( . The additional information I pass in a [quoted text clipped - 15 lines] > Ditto prompts and additional descriptive information can be made > available on demand. There were articles on this very sort of thing on www.javaworld.com a little while ago. I though they were a tad extreme, but on the other hand, when you looked at the actual implemented code to access and display data it looked very clean... http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox_p.html For myself, I've ended up implementing small pane classes that do small specific tasks, because I've never been happy with the it does everything you'll ever need' approach of GridBag and some other layout managers. They often have obscure bugs, and their complexity For instance, I have one pane that lets me add a vertical stack of components with labels (on the left) I can control the label alignment, the gap between labels and their associated components and the gaps between rows. The component side gets all the extra horizontal space. No new layout managers, but a borderlayout and a couple of box layouts in the east and west. If I want to make it fixed height I pop it into a BorderLayout.NORTH. Steve > For myself, I've ended up implementing small pane classes that do > small specific tasks, [...] I ended up with builder classes that *use* a panel, not extended it, to do small specific tasks. For example, build a button bar, button stack, stack of action labels, default forms, etc. Builders allow you to change the layout container, for example if you want to build on a WatermarkPanel, GradientPanel, etc. > For instance, I have one pane that lets me add a vertical stack of > components with labels (on the left) I can control the label > alignment, the gap between labels and their associated components and > the gaps between rows. [...] The free JGoodies Forms provides builder classes that stack components, and build button bars and obey configurable sets of layout style guides. This way you can specify a layout that follows the Mac Aqua Interface Guide and the Microsoft layout style guide at the same time. See http://forms.dev.java.net/ Regards, Karsten >One thing I have found incredibly time consuming and ditzy is the way >you have to create Label objects for every piece of labeling text on [quoted text clipped - 15 lines] >GridBagLayout with rows and cols multiplied by 3 to leave room for the >labels. Isn't this just another example of the disadvantages associated with using a low level language when most applications only require high level constructs like data entry, storage and display. "Enterprise" Java IDE's will generate a data entry screen including labels but there is no way of maintaining the unreadable generated code outside a proprietary IDE. What is needed is a mandated "commercial" programming language that vendors are obliged to support. Unfortunately, Grace Hopper is no longer with us now that we really need her. > Isn't this just another example of the disadvantages associated with > using a low level language when most applications only require high [quoted text clipped - 4 lines] > language that vendors are obliged to support. Unfortunately, Grace > Hopper is no longer with us now that we really need her. Even then, I'd argue it's difficult to maintain WITH the proprietary IDE. The most interesting issue to me is simply that there hasn't been a lot of momentum in the OSS world for this kind of thing. I can go and download a dozen Servlet frameworks of varying power and complexity, but I have yet to see one OSS high level toolkit for generic "green screen" CRUD applications in Java. Writing a simple "Customer Maintenance" application is basically traumatic. In a 20 year old 4GL, you could write that in an hour. But, Java is not a 4GL, and it's remarkably difficult to MAKE it a 4GL, which is why we have the plethora of XML config files, or "annotated Java" solutions. One of the big benefits of 4GL is simply that they are able to warp synatctic sugar around the mundane tasks of writing these applications. On the one hand these capabilities made them really productive, but inevitably they limited them as well. If you wanted to creep outside the domain of the what the 4GLs could handle, many times you had to toss the whole thing away. But as long as you could live within their world, which was really 90+% of the application space, they were very handy. Of course, we have lots of flexibility within Java, but we simply can not (easily) abstract things at the actual language level, without external tools. Regards, Will Hartung (willh@msoft.com) One thing we can do - f'rinstance - is create a 'NumberBox' class which extends JTextField - for those times when you need a text box that accepts only numbers.... then you can inherit it and make it accept only 'certain numbers' or range of numbers. --stuff-n-such like that-thar. > One thing I have found incredibly time consuming and ditzy is the way > you have to create Label objects for every piece of labeling text on [quoted text clipped - 15 lines] > GridBagLayout with rows and cols multiplied by 3 to leave room for the > labels. It's already in Swing... use JFormattedTextField, put a number in and it will only accept numbers, put a date in and ....... use InputVerifier and you even have (basic) validation support right there for you! >>The other problem is the incredible amount of application level code >>you to deal with very ordinary things: I made my own application framework for Swing wich handles all this kind of stuff for you! >1. copying back and forth between computational variables and gui >variables. support for databinding is standard. >2. validating text to make sure it is numeric, in bounds, has right >number of decimal places etc. >3. checking for mandatory fields. Support for field (=required) validation(s) (min/max/range/etc is standard. >4. composing SQL record descriptions. >5. taking info from SQL ResultSets and putting it back in gui objects. Generated by my own tool inclusive (data)models. >In an app I am writing now, I am experimenting with changing the >background color to indicate good/bad on each field. Standard in my framework, currently focused field has gray background and field wich has validation error(s) has red background color. (ofcourse colors are fully customizable) >Unfortunately there are no tool tips in AWT I could use to give error >messages on request, and no setFocus. Again... this is standard in my framework. I can mention a lot more missing here that is in my framework, if you're interested take a look here http://jform.coderight.nl Regards, Will www.coderight.nl > One thing we can do - f'rinstance - is create a 'NumberBox' class which > extends JTextField - for those times when you need a text box that accepts [quoted text clipped - 26 lines] > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.690 / Virus Database: 451 - Release Date: 5/22/2004 On 9 Jun 2004 11:47:43 -0700, will@coderight.nl (Will) wrote or quoted >It's already in Swing... use JFormattedTextField, put a number in and >it will only accept numbers, put a date in and ....... use >InputVerifier and you even have (basic) validation support right there >for you! It is only 10% of what I envision a smart object should do. 1. It offers no prompting. 2. It has no bounds checking 3. I don't think it does keystroke by keystroke editing. 4. It does not offer any prompting help 5. It does not generate any localised error messages for the user. 6. It does not convert itself to binary format 7. It does not persist itself to a database. SignatureCanadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. What you mention is not part of the component interface but then again it's all there and can be done with little effort. I do find that something like bounds checking should be part of the component's interface as this is so general and needed many times. > 6. It does not convert itself to binary format I do not understand what you mean by this? why binary who wants binary these days??? serialization to xml is supported. > 7. It does not persist itself to a database. This should not be standard functionality of a gui component. You want persistance to a database I want xml and the next person wants a flat text file... and all this should be handled by the (same) component right? and all ofcourse without additional coding... >It does not let the user copy paste to fill in the data. This is a >ridiculous oversight in web based forms. What have web based forms to do with com.lang.java.gui??? >It is only 10% of what I envision a smart object should do. For me what's there is good enough for someonelse even with your 10% added functionality it still doesn't come close to a smart object... Will > On 9 Jun 2004 11:47:43 -0700, will@coderight.nl (Will) wrote or quoted > : [quoted text clipped - 19 lines] > > 7. It does not persist itself to a database. On 9 Jun 2004 23:45:21 -0700, will@coderight.nl (Will) wrote or quoted >I do not understand what you mean by this? why binary who wants binary >these days??? serialization to xml is supported. If you want to calculate with a date you need it in binary. ditto a dollar value, ditto a length. Ideally you should be able to use a guy component in the context of an int and have getIntValue or setIntValue called for you automatically, so you could get away with only one set of variables. Zips can be more compactly stored as ints. SignatureCanadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. >Ideally you should be able to use a guy component in the context of an >int and have getIntValue or setIntValue called for you automatically. that should read: Ideally you should be able to use a GUI component in the context of an int and have getIntValue or setIntValue called for you automatically. SignatureCanadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. >If you want to calculate with a date you need it in binary. ditto a >dollar value, ditto a length. I think what you mean is the (data) type from the gui component like Date, int, double, etc right? So when you call getValue you get an Object back and you have to explicitly cast to the type you want right? (this should be history if you use jdk1.5 with autoboxing...) I have an InputField that does this. As a developer you don't have to worry about the data type because my framework databinding supports auto type conversion. You put an int in you get an int back (even works for custom types:) I really suggest you buy my framework :) It seems to solve a lot of you (and other peoples) 'problems' Will > >Ideally you should be able to use a guy component in the context of an > >int and have getIntValue or setIntValue called for you automatically. [quoted text clipped - 3 lines] > Ideally you should be able to use a GUI component in the context of an > int and have getIntValue or setIntValue called for you automatically. >I think what you mean is the (data) type from the gui component like >Date, int, double, etc right? So when you call getValue you get an >Object back and you have to explicitly cast to the type you want >right? I want to go further than that. I want autoboxing to treat the gui as if it were the corresponding primitive. So I want to be able to say: NumericGui age = new NumericGui( 18, 102 ); age = 21; age += 10; SignatureCanadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. On 9 Jun 2004 11:47:43 -0700, will@coderight.nl (Will) wrote or quoted >It's already in Swing... use JFormattedTextField, put a number in and >it will only accept numbers, put a date in and ....... use >InputVerifier and you even have (basic) validation support right there >for you! It does not let the user copy paste to fill in the data. This is a ridiculous oversight in web based forms. SignatureCanadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. Could you be more specic please? Copy from were? Copy from clipboard to gui components is standard supported by Swing... If you mean copy paste from one form/field to another you're right, you have to manually support this but again :) this is minimal effort. You cannot expect from Sun to make a framework that does EVERYTHING for you. Will > On 9 Jun 2004 11:47:43 -0700, will@coderight.nl (Will) wrote or quoted > : [quoted text clipped - 6 lines] > It does not let the user copy paste to fill in the data. This is a > ridiculous oversight in web based forms. On 9 Jun 2004 11:47:43 -0700, will@coderight.nl (Will) wrote or quoted >Again... this is standard in my framework. But I can't use your framework, and it means everyone has to invent their own. It also means code is not portable. SignatureCanadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. > On 9 Jun 2004 11:47:43 -0700, will@coderight.nl (Will) wrote or quoted > > >Again... this is standard in my framework. > > But I can't use your framework, and it means everyone has to invent > their own. It also means code is not portable. Yup. Everybody has to invent their own as dictated by their circumstances (some could simply choose to purchase a framework such as Will's). It has taken Sun ~5 years to get something with the sophistication of JSF, which is just now surpassing the capabilities of an ANCIENT (though maintained) web framework, Struts. Meanwhile, there are literally dozens of available Web App frameworks available. How long are you willing to wait for Sun to come out with a "standard"? How long do you wish to hold back your productivity? With the recent "push" for Java on the desktop, perhaps we will see more frameworks like Will's showing up. Even if Sun did come out with something, I guarantee it won't work for everyone, maybe not even you. Finally, this "enterprise" capability is a solid value add for the IDE vendors (which is why you can't ever seem to get these capabilities for free). Sun can give away servlet engines and weak J2EE servers all day long, but when it comes to clusters, failover, etc, there's a market for that and there's no reason to give that market away. Regards, Will Hartung (willh@msoft.com) VERY WELL SAID!!! Let me add this: Swing is a gui framework, it provides components for building user interfaces. What you people are looking for is an application framework for Swing same like Struts is an application framework for web apps. What if Struts wasn't there? You only had servlets to work with. So in order to get functionality like Struts means you have to build your own controllers etc. Swing provides the basics (components) the rest is up to you. That's why I build my framework, i'm not going to wait (5jrs:) for Sun to come with functionalities we need so badly and even then have to wait and see if it is good enough for me... > > But I can't use your framework, and it means everyone has to invent > > their own. It also means code is not portable. Unfortunatly but true... When I develop Swing apps for a customer the first thing we start with are abstract views, controllers and models. For example part of this could be custom components like the 'label component' mentioned in this post. I do not however understand why (my) code would not be portable? (As long as it is pure java that shouldn't be a problem) > Yup. Everybody has to invent their own as dictated by their circumstances > (some could simply choose to purchase a framework such as Will's). Not a bad idea :) > Finally, this "enterprise" capability is a solid value add for the IDE > vendors (which is why you can't ever seem to get these capabilities for > free). You can ofcourse write your own. But writing your own is (usually) always more expensive... (and you have to maintain it yourself...) Will CodeRight > > On 9 Jun 2004 11:47:43 -0700, will@coderight.nl (Will) wrote or quoted > > : [quoted text clipped - 31 lines] > Will Hartung > (willh@msoft.com) > One thing I have found incredibly time consuming and ditzy is the way > you have to create Label objects for every piece of labeling text on > the screen. I tried to make layout product faster and cheaper. But I couldn't find a general approach for auto-labeling that saves time and money while ensuring good design. However, for the special case of default forms with label and comonpent columns, I provide builder classes that build panels quickly, create labels on-the-fly and obey style guides. For example I write: builder.append("Email", emailField); builder.append("City", cityField); etc. But in good design you want to add value and meaning, want to illuminate, simplify, clarify, dramatize, group and relate. And that can hardly be done by a self-labeling approach. See for example the dialogs in the Mac Aqua Human Interface Guideline. In my opinion its difficult to come up with an automatism that provides the same design quality. But most of the designs shown in this guide can be layed out quickly by hand (and brain). You can find source code examples for the approach that I like best - at least for hand-building UIS. See the builder example sources in the Forms tutorial that ships with every build of the JGoodies Forms. http://forms.dev.java.net/ Best regards, Karsten >You can find source code examples for the approach >that I like best - at least for hand-building UIS. >See the builder example sources in the Forms tutorial >that ships with every build of the JGoodies Forms. >http://forms.dev.java.net/ I see no reason that the samples you show on that page could not have been done with autolabelling. They look very similar to the sorts of layouts I do in DOS. Next sometimes you want a dynamically generated layout where you don't have a person present to hand tune it. SignatureCanadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. >>http://forms.dev.java.net/ > > I see no reason that the samples you show on that page could not have > been done with autolabelling. They look very similar to the sorts of > layouts I do in DOS. I referred to the design examples shown in the Mac Aqua Human Interface Guidelines. The ones on the Forms page and in the Forms tutorial can be done cheaper; that's what Forms does and that what the tutorial is about. Best regards, Karsten >You can find source code examples for the approach >that I like best - at least for hand-building UIS. >See the builder example sources in the Forms tutorial >that ships with every build of the JGoodies Forms. >http://forms.dev.java.net/ With autolabelling you can autohide the labels if the space gets tight. SignatureCanadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.