Our cheat sheet for converting smart client solutions and form work over to web client as of Servoy 6.1.x. Will keep updated as we run into things -- especially the "gotchas" section at the end. Feel free to augment!

Split beans are not web client compatible and need to be converted to split tab panels. (Split tab panels were introduced in Servoy 5.x and should be used for smart client as well now.)

Design conversion:

- note the size of the largest bean element and it's location- remove the beans from the form- note the forms that make up the tab panel and relation info.- remove the bottom or right tab panel- resize the remaining tab panel to the size of the bean- set the tab orientation property SPLIT_VERITCAL- anchor the tab panel to left, top, bottom, right (or as you see fit)- add forms to split tab panel. position labels to get desired left/right or top/bottom split

Code conversion:

Split bean setup code is usually located in the onLoad event. Comment out (or remove) and add new code in the onShow event (firstShow parameter). Example:

Any other code that modifies the split bean at runtime needs to be corrected to modify the split pane. In general, the runtime functions of the split beans and split tab panels are fairly similar. So pretty easy to track down and fix.

Use styles instead of element properties

A lot of older smart client solutions have various elements styled directly with properties even though styles have been available for a long time. This is a good time to convert everything over to using style sheets. Some wiki references:

An example using the above split bean conversion: create style classes for split tab panels that correspond to the look of what you had setup for split beans. (Make sure your form(s) have style sheets assigned.)

The following code sample uses the new sub class feature to define styles for different split tab panels:

A lot of us imbed web client in an iFrame. The URL of the iFrame is a web client deep link. This requires advanced knowledge of client-side javascripting and associated libraries. The trade-off is that it allows for for powerful "wrapper" manipulation of your solution. Some of the things we're doing:

- Dedicated wrappers for various mobile devices to setup and organize specific css and functionality. Example is that on an ipad the user is prompted to save the web app to their home screen as an icon. Another: open Google Maps app from an address in in web client.

- Google analytics. With real/consistent/meaningful URL's -- going to specific screens and records google analytics works very well now. Also able to use robots.txt and humans.txt to help search engines.

- Implemented favicon.ico and associated named variants for Android and iOS to get the URL badge graphic.

Advanced CSS ideas

- External graphic sprites for all icons. Use instead of Servoy media images via css background assignment. Advantage: Servoy sends medias used on forms individually each time a form is shown. A sprite is sent once for your entire solution.

Note how we included some fairly generic style classes. Of course all html area code appears at some point in the final html markup in web client. This could be (and usually is) after any Servoy style information is loaded.

The gotcha is that if you have some generic classes in html area markup (like td and tr.'s shown above), this can override earlier CSS for those classes/tags and the rest of your screen will take the values from your html area field instead of what you defined in a Servoy style sheet or elsewhere.