[Isomorphic]

That question needs a little more context to answer - at a very high level, if it's periodic and/or server-triggered in a way the client can't know about, use the Messaging module (http streaming of updates) or poll for updates, otherwise, if it's related to the operation taking place but the client just can't know the specific records affected, consider manually flushing caches where they exist (invalidateCache() is available on dataBoundComponents).

[csillag]

As far as working with domain objects on the client-side [...] if you really prefer beans, first convert a Record to a bean and then act on the bean.

I tried to do this by specifying beanClassName in the DS XML (SQL backend), but then the dataBoundComponents bound to this dataSource stopped working.

How do I get around this?

[Isomorphic]

beanClassName does nothing of the kind (see the docs for what it does do), so nothing to "get around", you would simply add client-side code to create beans from Records wherever it make sense.

[csillag]

SmartGWT Enterprise Edition (SmartGWT EE for short) is a commercially licensed version of SmartGWT that includes Java Server side functionality, additional tools, and a classic commercial license in lieu of the LGPL.

Where should I ask questions about SmartGWT EE licensing?

[Isomorphic]

General license information including full text of the standard licenses and a FAQ on licensing is here. If you are trying to clarify the posted licenses or license policies, you can ask on the forums. If you are trying to get a quote for specific terms you need, use this contact form.

[csillag]

Loading all datasources automatically

Dear Isomorphic,

I understand that to load a datasource, I need to insert a

<script src="isomorphic/DataSourceLoader?dataSource=ds1,ds2"/>

tag to my HTML page.

Is there a way to avoid listing eash datasource manually? (I am thinking of a magic keyword like "*" or "<all>", which would automatically return all DataSources from the shared/ds directory.)

Is something like this supported?

[Isomorphic]

@csillag Not really. DataSources frequently exist only for server-side use and so it would be a dangerous thing to load them all - newly created DataSources not intended for client-side use could get inadvertently included.

[csillag]

forbidden ds names

Dear Isomorphic,

I have noticed that if I create a DS XML definition with the filename (and id) groups.ds.xml, the server side crashes with a stack overflow on the next restart.

If I rename the DS, it works ok.

This seems to be 100% reproduceable for be.

Is this expected?

(The content of the DS XML does not seem to matter.)

[OpenESignForms]

Support for SmartGWT 1.3?

Not sure if they are related, but the EE download is 1.2.1, while the latest for SmartGWT LGPL is 1.3. Does EE 1.2.1 include the 1.3 code, or how long will it before EE is up to the later 1.3 release?

[csillag]

I there a thread somewhere to praise the work of Isomorphic?

[Isomorphic]

SmartGWT Pro/EE 2.0 has been released. Download the evaluation here.

New client-side features are described here.

[sdetweil]

so, I download the EE Eval version, started up the embedded server, and opened the browser, found the IDE.. and bummer. the ONE thing I wanted to see is not in the components, dynamic data bound tree.

Sam

[Isomorphic]

It's not particularly hard to find the complete running sample with source.

[csillag]

While it's possible to build specialized client-side domain objects that have limited business logic, it's usually more effective to just use a "Flyweight" pattern where you have a library of utility functions that act on the generic Record class,

Where can I find an example of doing this?

or if you really prefer beans, first convert a Record to a bean and then act on the bean.

Is there any built-in support for doing this, or should I do this manually?

DataSource.getBeanClassName() seems to be related. Is this the intended use of it? Where can I find an example of it?

[Isomorphic]

The best place to look for an explanation of the Flyweight design pattern is probably the original "Gang of Four" Design Patterns book, and/or the many web sites recapitulating that content.

Due to the lack of Java reflection in GWT, to convert a Record into an instance of some custom bean, there's nothing you can do but retrieve each attribute via record.getAttribute() and call each setter method (eg setName()) manually.

This is why we recommend the Flyweight pattern being used with the Record class. There is very very little business logic that can meaningfully run either client or server-side, and most of it is already captured in the Validator system.

We see a lot of people get very excited by the idea of a single Bean class that exists both client and server side, and then spend a spectacular amount of effort trying to somehow separate out the server-side business logic that they naturally want to attach to the bean but which can't be added there if they want the bean to go through the GWT compiler. Two months of tricky Java dependency management later they have "solved" the problem and managed to factor a bean with 2 methods (yes only 2) so that they run either client or server.

But another team that chose not to tilt at this particular windmill just made equivalent static methods, with no dependencies on a particular bean and which go through the GWT compiler with no issues, and never wasted those two months.