General approach in GWT is to use Panels and then apply custom CSS themes to get a customized look. While I can achieve a certain extent of personalization of my GWT app through CSS tinkering, I was wondering how others generally approach styling.
Some of the suggestions I came across the web were to manage layout with plain HTML, through use of HTMLPanel's. This way one can straightaway use the HTML mock-up within the application without having to code all the layout.
So what in your opinion is the best and least painful way to approach layout and custom styling of GWT application?
So far, the best approach I found:
get rid of any default GWT theme
use UiBinder as much as possible
place your CSS in ui.xml that describes the widget
have one public Common CssResource with rules reused by many widgets
that way you don't need to maintain one global stylesheet which always is a pain (common problem: where is this rule used?)
It all depends - on you, your experience, your team, etc:
The usual/older approach of Panels, Widgets and Compositing will be easier to work with/more familiar:
If you are a Java programmer experienced with frameworks like Swing, etc. (I think that was the point of the GWT team),
Or if you come from the "desktop world" in general.
The UiBinder approach is the newer one:
Recommended if you are just starting your experience with GWT (it seems UiBinder is here to stay, and it allows more flexibility than the above approach),
Recommended if you have experience with web development (or desktop frameworks that use markup, like .NET's XAML, etc), since you'll be working in the familiar world of HTML/XML,
If you are working in a larger team, where you have designated designers in charge of the look of the web application (and they don't know/care about GWT). Cutting up the layout into HTML code should be pretty straightforward for them and you can, with little work, convert those templates into UiBinder's XML templates.
None of the above approaches is perfect - that's why it's worth to know their strong and weak points - but the end decision should be yours alone, since you know your/your team's capabilities best :)
Related
I started working on projects in GWT last month. It was all well until I needed drag and drop(DND). After trying gwt-dnd library like everyone else I got infatuated by smart-gwt widgets. But everywhere I read that its a very thin wrapper over Javascript. But I've still decided to go with it. I have some general questions regarding GWT.
Is it okay to write the GUI in a mix of plain-GWT and smart-gwt ?
Can I implement drag and drop only with plain-GWT without the help of external libraries?
Should I write the smart-GWT like widgets in plain-GWT myself?
No you shouldn't and neither is proposed from the smartgwt creators, There are some tweaks that can make it work, but it is at a per case base ...
You could try to achieve this, especially with the latest 2.5 version and its Elemental library.
Depends what you need and the resources you have for the task. You could make look-like lighter elements macthing the smartgwt ones, but it can be tricky if you are looking after operations like filtering etc. Bottom line is, you wouldn't be considering the smartgwt or any other similar library, if you had the time and resources to develop its widgets.
I am a student getting started with web development with GWT. I have previous experience with Java however I am no UI design experience.
However I believe I can catch up on CSS easily.
I was browsing the official Google's UiBinder document, which is very concise(one page). I am not able to figure out much just from this document. It might be that things are not much obvious to me at the moment due to lack of experience in this field.
How should I dig deeper and get hang of designing UI with uibinder?
Any resources and strategies can be of great help.
I'd try using GWT designer which is part of the Google Plugin for Eclipse. It'll add handlers to buttons / forms / widgets for you and populate uifields in the Java classes. I've found just playing around with it helped me quickly find UIBinder features. You can easily switch between XML and design mode if you want to see what it's creating for you.
Our webapp is implemented in GWT 2.2, with heavy use of UIBinder. I really like UIBinder's ability to define styles either inline with the HTML, or at least in a <ui:style> section. As a programmer, this modularity really appeals to me, as it puts the styling right where it's used.
And for styles that are used in more than one place, I refactor them to a CommonStyles.css/CommonStyles.java, and refer to that in my *.ui.xml files.
This has worked great so far, but now the company has contracted an HTML/CSS designer to re-work the design. We spent a few days trying to get him up to speed on Eclipse & GWT, without much success. To meet a deadline, we ended up having him just deliver an old-school giant CSS file to us, which we then painstakingly refactored back into the various ui.xml modules.
My question: Is it better to maintain a single, old-fashioned giant CSS file for a UIBinder app, so that designers can work with it? It pains me as a programmer to do things this way, but it seems like it's the only practical way to have non-programmers work on the design.
Is it unreasonable to expect designers to know an IDE such as Eclipse or Intellij?
From the perspective of the programmer of a company with one programmer and one designer:
The designer on my team never used eclipse or Java before our current project. We started using UiBinder stuff heavily about two months ago and, with maybe a couple of hours of help from me, he's managed to become quite proficient. He's now checking finished & laid out widgets into the source himself, with perfect CssResource etc modularization. I still set up the corresponding .css and .java files for him, but then I throw the setup at him, he writes 90% of the ui.xml & .css bit himself, and I come back and implement his ui in java afterwards. Occasionally I have to change a <div> to a <g:Panel> or whatever. He has not complained about it being too hard. Now he's starting to explore the extensions to css that gwt provides, like constants and expressions.
I'd say you shouldn't have to give up the benefits of UiBinder for the sake of your designers. In my own project, I expect to have to set up all of the code and generate templates for all of the Java interfaces, but I expect my partner to be able to add his own styles, separate css intelligently (e.g. CommonStyles.java vs. ThisWidgetStyles.java), and understand what's happening when his style names turn into GVDWK.
I have my first GWT project that I created using UiBinder (GWT 2.0 way) which I found to be easier than write my UI creation Java source code (GWT 1.0 way).
But I saw this thing called GWT Designer that Google are releasing for free. It has nice features and wizards which were missing with the standard Google Eclipse Plugin. I like it, but I still think that using UiBinder is better. I think GWT Designer will be really useful when it can help you write UiBinder XML files (GWT 2.0 way), and not just source code (GWT 1.0 way).
What do you think about it?
Do I need to migrate to GWT Designer project?
Will it be better if I migrate but still keep UiBinder UI creation?
The latest GWT Designer now has support for UiBinder, and it works great.
http://download.instantiations.com/D2GWTDoc/continuous/latest/docs/html/wizards/gwt/uibinder_composite.html
UiBinder can give you better performance and a better optimized download than traditional widget construction; to me that's enough of a reason to stick with UiBinder. If your app is light and fast enough as it is then the choice probably comes down to what style of development suits you best.
I wouldn't go as far as to port your existing UiBinder templates into the designer. Google will be adding support for them to GWT designer soon enough.
I haven't used the newly-freed GWT Designer yet myself, but I wouldn't expect that it would warrant migrating your entire project over to it if it's already written using UIBinder.
Remember that the two methods of constructing a UI are not mutually exclusive -- you can use the GWT Designer to create a new widget and use it in an existing UIBinder project, and if you decide it's that much better, you can consider migrating at that point. Or not, since they can still happily coexist.
If you are doing professional development in an organization that utilizes experts in CSS and html, then GWt is going to be a tough sell if you don't use something like UIBinder for layouting as well as individual pages. I also think that a CSS designer can do a better job at responding to UI requirement changes than a java developer using GWT layouting techniques.
However if your java staff has control of the requirements and don't have to answer to UI designers, then I suppose choosing between delcarative templates and something like GWT Designer is just a matter preference.
As said in the relaunch announcement:
Now that these products are available again, we hope you’ll start using them within your GWT projects. Meanwhile, our next step is to more deeply unify them into the GWT family of tools by blending the fantastic Instantiations technology into the Google Plugin for Eclipse (GPE). So, there’s much more to come, including things we’re pretty sure you’ll like, such as UiBinder support in GWT Designer.
It wouldn't make sense to get ride of your UiBinder code since GWT Designer will support it soon.
DON'T use the designer plugin. The most recent update (8.1.1 at the time of this post) contains buttons that allow the user to add elements that are incompatible with IE, for instance CellTable, DeckPanel, HorizontalPanel and VerticalPanel.
This means whoever uses the plugin, uses it entirely at their peril. If IE7 tries to pull in these elements, it will load a partial page but fail to load components that use these elements. IE8 may not be able to load the application at all.
I need recommendations from people whom have implemented an easy to use GWT editable datagrid.
I spent 4 hours with the PagingScrollTable in the gwt-incubator-july-14-2009.jar, and would now like to try other options.
What I'm looking for:
easy to get started (ex. drop a jar, edit .gwt.xml)
advanced features once you have gotten started
documentation of advanced features
self-contained module with minimal dependencies on other modules, jars or components
low cost/free
Thats all :)
Please, for goodness' sake, stick with vanilla GWT. Just use GWT data cell tables, lists and trees.
Smart-GWT and GXT really look good in their demo. e.g., Smart-GWT has widgets that accepts xml/json datasource directly that would save you time.
But, you find that your application requirements would "just need that tiny tweak" in the way the widget eats the datasource. Both GXT and Smart-GWT have attractive convenient widgets, but you find you need "just a little" tweak to make them suit your requirement.
Is your "little" tweak "important" enough? So, you resort to writing your patch for that "little" tweak. And soon you find that there is a whole entrail of "little" tweaks. You experiment and research and try untried means.
Finally, you discover that you might just as well had used vanilla GWT for which you would have taken less time to get the behaviour you want. Vanilla GWT is tried and proven.
Do not be tempted by the showcases of SmartGWT or GXT. Learn CSS and learn how to integrate CSS into vanilla GWT, which would make your widgets just as attractive as SmartGWT or GXT.
Then you would not regret because you would not face any impediments toward using other GWT features.
What is good enough for Google is good enough for me.
Hi HJO there are many solutions to problem depends on what you want. The GWT-EXT, EXT-GWt and SmartGWT libraries all have editable data grid implemented. Or you can make your own with FlexTable,ScrollPanel,TextBox and add a few event handlers. Both GWT-EXT and SmartGWT are in LGPL license and I believe EXT-GWT is GPL license. If you not doing it for production then any will do, but if you are doing it for big production environment I suggest to really test each of their performance first. I suggest to choose something light weight and robust instead of simplicity or appearance on production environments. At the end, the less data/widget loaded + less handlers = performance and happy user.
Take care,
NingZhang.info
I do not recommend to use GWT DataGrid for production (in GWT 2.4), unless you like coding workarounds for several bugs (most of them on Internet Explorer):
http://code.google.com/p/google-web-toolkit/issues/detail?id=7065
http://code.google.com/p/google-web-toolkit/issues/detail?id=7347
http://code.google.com/p/google-web-toolkit/issues/detail?id=7139
http://code.google.com/p/google-web-toolkit/issues/detail?id=6747
I use CellTable instead of DataGrid and wait for bugfixing from GWT team.