SmartGWT UI definition using XML - gwt

I have been using UIBinder on SmartGWT widgets rather successfully.
However, I have to extend each SmartGWT widget that I use to comply with UIBinder's requirement. Occasionally, I have to masquerade a SmartGWT widget into com.google.gwt namespace, or masquerade a non-GWT-widget as a GWT widget. I extend widgets on as-needed basis.
So, I am starting to wonder, may be SmartGWT already has a UI XML format and I might be doing all this UIBinder acclimatization just to reinvent SmartGWT's wheel.
I have read and reread source codes of the showcase and delved into some of the SmartGWT source code, as well as reading the javadocs.
All I found is XML or Json for communication between server and client.
Is there any UI def XML available for SmartGWT whether gwt-compiled to client-side javascript or like Vaadin's server-side generated UIDL?
And if you happen to be an Isomorphic agent, could you tell us if there are any plans to let SmartGWT play with UIBinder (to preclude me from having to massage SmartGWT widgets on my own anymore)?

Yes, there is a SmartGWT XML component definition - the one used by Visual Builder and Reify, and which you can also write directly. See these docs and this FAQ item:
http://www.smartclient.com/smartgwtee-latest/javadoc/com/smartgwt/client/docs/ComponentXML.html
http://forums.smartclient.com/showthread.php?t=8159#loadVBScreen
As the FAQ clarifies, we recommend using this XML format for a set of use cases that heavily overlaps with what UIBinder is for, that is, keeping your layout and basic component definitions in a declarative format that designers can edit and which can be edited by visual tools, and having your actual Java event handling and other programmatic code separate.
However we strongly recommend against having that declarative format be HTML (as UIBinder does it) because that introduces lots and lots of cross-browser layout issues.
We are likely to eventually support UIBinder as well for the few use cases where it is not redundant with our own XML format. If you need that to happen sooner, consider Feature Sponsorship:
http://www.smartclient.com/services/index.jsp#features

For XML smartclient has the componentxml which is XML based ui design and use JavaScript to have client side logics. You need not compile your app every time in development environment and just reloading of the browser will have the change included and you can test it.

Related

Google Web Toolkit - UiBinder

I am new in GWT. I want to ask some questions about UI binder:
<ui:with field='res' type='com.my.app.widgets.logoname.Resources'/>
(1) Refer to code above. What is the meaning of type? Is meant the file location?
(2) Why need to use external resource for the UI binder?
(3) When I write css, in java file should I need to write the "extends CssResource" word?
I really don't understand. Please help me to answer the question. Thanks.
<ui:with field='res' type='com.my.app.widgets.logoname.Resources'/>
Refer to code above. What is the meaning of type? Is meant the file location?
Here type is equivalent to below java code
Resources res = new com.my.app.widgets.logoname.Resources();
Why need to use external resource for the UI binder?
Sometimes your template will need to work with styles or other objects that come from outside of your template.
When I write css, in java file should I need to write the "extends CssResource" word?
Yes you have to use extends CssResource
For detailed explaination and samples please have a look at GWT UIBinder - Using an external resource.
Find a sample code here about GWT - Using UiBinder.
Here is the key points of using UIBinder:
The UiBinder is a framework designed to separate Functionality and View of User Interface.
The UiBinder framework allows developers to build gwt applications as HTML pages with GWT widgets configured throughout them.
The UiBinder framework makes easier collaboration with UI designers who are more comfortable with XML, HTML and CSS than Java source code
The UIBinder provides a declarative way of defining User Interface.
The UIBinder seperates the programmic logic from UI.
The UIBinder is similar to what JSP is to Servlets.

Is it possible to eliminate the need to hardcode in CSS and HTML with GQuery compile time selectors

I am developing a web app with GWT. I'd strongly prefer to code everything in Java instead of hardcoding anything in HTML and CSS. I'm also using GQuery (or GWTQuery) and I'm wondering if using compile time selectors with GWTQuery completely eliminate the need to hardcode any HTML or CSS at all - and have the speed and performance of a fully hardcoded app?
Let me explain with few words what gwt and gquery are.
1- GWT is just a compiler which gives you the tools to produce optimized javascript from java.
2- The js produced with GWT is mainly used to modify the DOM (apart from calculations, business code, ajax etc).
3- GWT additionally gives you a set of widgets, as an abstraction of the DOM, so as you can work with panels, buttons, trees, etc. instead of raw HTML. I think this is what you call hardcoded html.
4- But GQuery is a complement to GWT. It gives you a set of utilities taken from jQuery and ported to java to write less code, it is mainly oriented to manipulate the DOM (select nodes, modify, animate, etc) apart from other cool features like an easier ajax syntax, safe typing, promises, json/xml data-binding, etc.
Said that, don't think that the gwt widget abstraction will make you completely forget about dom and css. Sooner that later you will need to create your own widgets, or customize the current ones.
I think that the only way to forgot almost the DOM is to use a 3rd party widget library like gxt, mosaic, smart-gwt, etc. Because the GWT widgets are tough, they are designed to give the designer the option of easy stylizing them with css.
In the other hand, gwtquery will not help you to forget the DOM at all. It is designed to enhance static DOM elements which are in the page, enhance the DOM of gwt widgets, or create your own DOM structure based on html.
About gQuery compiled selectors, they are used in the same way dynamic selectors are: to select DOM elements, but with a much better performance because the compiler optimizes them. I think you misunderstood their objective, they don't give you any way to eliminate hardcode HTML.
UPDATE: To answer your last comment, it is NOT possible to generate static HTML or CSS with
GWT or GQUERY. They always produce static JAVASCRIPT code written to .js files (or written into javascript tags in .html files depending on the linker)

Wicket Components - have to add() every time?

I am attempting to build a simple application using wicket and have been impressed so far. I have been taking advantage of the Component class to determine behavior of elements on the page based on user input or the model. I see the component model similarities with JSF, but find the wicket lifecycle easier to manage.
What i haven't been able to understand is having to add every component to the tree for every wicket:id mentioned on a page, especially for ones without any children. it seems heavy handed to have to build up the tree in java code when the tree has already been somewhat defined within the markup. what am i missing?
edit
I should probably give an example. I have a label for an input box that in some cases i want to be able to modify. 95% of the time the text and attributes i have for the label in markup will be fine.
Short answer: Yes, you have to add them.
Long answer: You can create custom code to do this, but I doubt it's worth the effort.
With JSF, you use a non-html tag, which has one component type associated to it - for example, h:inputText correspond to the class HtmlInputText -, so it knows what class to instantiate.
With Wicket, the HTML file contains only (with a few exceptions) HTML tags, and you have to instantiate a concrete component for each wicket:id-marked tag you add to the markup, because it can't know for sure if <span wicket:id='xyz'> means a Label, a FeedbackPanel, a WebMarkupContainer, or some custom component.
With JSF you do in the markup what, with Wicket, you do in Java code, that is, to build the component tree, bind components to properties, and handle events. It keeps everything in one file (you don't have to create a class for every template file), which has many, many cons (some may think it has some pros, I digress).
You page is never just a simple form that does nothing. You want to convert and validate the input, you want to process the submit, you want to update components using Ajax. With JSF, you do all that in the (non-compilable, type-unsafe, poorly tooled, non-refactorable) template, making it bloated with expressions, configuration tags, and - gawd forbid - business logic.
If Wicket had support for this (and, for the matter, it has the flexibility needed for you to build this add-on yourself), you would have to add lots of extra annotations (special, non-standard tags and attributes) to the markup, to declare what class to instantiate, what model to update, what validations to execute, etc., compromising two of the beauties of the framework, the clean HTML template, and the clear separation between visuals and logic.
One framework that tries to do more in the template, while remaining less bloated than JSF (which isn't that hard anyway) is Apache Tapestry. But as can be seen in its tutorial, you still end up having to use non-standard tags and following arbitrary conventions to bind the template to the code (you may like it, but if this is the case you have baaad taste, sorry :P).
I have a label for an input box that in some cases i want to be able to modify. 95% of the time the text and attributes i have for the label in markup will be fine.
You could try to wrap the content of the label in a Model, enclose that label in a container and repaint the container (target.add(container);).
Offcurse you should add them.One of the most powerful facilities of wicket is that allow you to make a reusable components espacially html components.
There are a million ways to build a house, but most people wouldn’t
consider building toilets, bathtubs, and glass windows from scratch.
Why build a toilet yourself when you can buy one for less money than
it would cost you to construct it, and when it’s unlikely you’ll
produce a better one than you can get in a shop? In the same fashion,
most software engineers try to reuse software modules. “Make or buy”
decisions encompass more than whether a module is available;
generally, reusing software modules is cheaper and leads to more
robust systems. Reusing software also means you don’t have to code the
same functionality over and over again.(wicket in action:manning)
So to have a reusable wicket pages, wicket just needs a html page to show it's components hierarchy or their positions. The types and model of these components left to programmer.

Creating a responsive design using CQ5 templates

I'm investigating Adobe CQ5 and would like any advice on how to integrate its drag-and-drop UI to create a responsive website. It seems as if it works on a concept of fairly bland templates with components that can be dropped in pretty much anywhere, including things like "three-column control" - which would make designing a responsive grid structure very hard (as it would be hard to prevent users from dropping in a control that could ruin the layout).
Does anyone have any experience or advice on this? I'm really looking for deep technical details on the structure of templates vs components (paragraphs), and where/how to manage to the CSS.
CQ5 offers ways to control what can be done within a template, so thinking that components "can be dropped in pretty much anywhere" may be misleading. Page templates are designed and configured so that you control which components can be added to a certain area of a page. This allows you to only make those components available that will work with the template layout, excluding components that would wreck the layout. Then authors are only allowed to use things that will work. If they attempt to drag a component onto a paragraph (parsys) where that component has not been configured as available, the UI will not allow them to use it there. So CQ actually makes it easy to prevent users from dropping a control somewhere that would ruin the layout.
This is outlined a bit here:
http://dev.day.com/docs/en/cq/current/howto/components_develop.html#Adding%20a%20new%20component%20to%20the%20paragraph%20system%20%28design%20%20%20%20%20mode%29 which states that
"The components can be activated (or deactivated) to determine which
are offered to the author when editing a page."
When it comes to CSS and JavaScript, you can create a client library and then include the relevant client library on the page. Backend CQ functionality will take care of combining multiple CSS (or JavaScript) files into a single minified file to allow for a single HTTP request of an optimized file. This it outlined a bit here:
http://dev.day.com/docs/en/cq/current/developing/widgets.html#Including%20the%20Client-Sided%20Code%20in%20a%20Page as well as
http://dev.day.com/docs/en/cq/current/howto/taglib.html#%3Ccq:includeClientLib%3E
So you might develop several components that share a client library, then when any of the components is added to a paragraph the client library will be included on the page. You may also want a CSS library that applies to all the templates to give a common look and feel, yet allow components to add their own when they are used.
These guidelines for using templates and components outline how you provide control, yet flexibility:
http://dev.day.com/docs/en/cq/5-5/developing/developing_guidelines_bestpractices.html#Guidelines%20for%20Using%20Templates%20and%20Components
I'll document our successful WIP experience with RWD and CQ5
Assumptions:
A well documented style guide.
Our First Steps:
Modified existing column control component css to utilize twitter bootstrap grid css.
Create a base page property allowing two different classes on the grid container to be set and inherited by child pages. (container||container-fluid).
Leverage out-of-the-box components where ever possible.
All component widths inherit the width of their parent container allowing for components to be dropped into any location within a template.
Issues:
The out-of-the-box column control component can not be nested.
We are looking into building a custom column control component.
Takeaways: this is an evolutionary project and we are constantly iterating.
With the recent launch of AEM 6.0, they have an example website called as Geomatrixx Media. This website is responsive.
You can take this example as reference and start building on top of it.

GWT widget library that doesn't want to be the whole app framework?

I've looked at all of the libraries listed in: Best GWT widget library?
Honestly, gwt-ext looks the best, but it's no longer being maintained (and the old project lead for some reason recommends SmartGWT instead.) I don't like the approach of SmartGWT, both because it wraps Javascript, and because it wants me to wrap my backend classes in its various data components (I don't want to have to translate my model objects just to use its widgets). Vaadin looks nice, but again doesn't seem to want to let me just use it as a client widget library; I have to use its server components. GXT looks fine, but the open source license doesn't apply to my organization.
Everything else on the list hasn't been updated in a long time.
Is there no GWT widget library that just focuses on providing better widgets, and doesn't want to force you to use its architecture to develop your UI?
GWT Mosaic is another widget library using the more lenient Apache license