Possible to extend SmartGwt components in plain javascript?

[martintaal]

Hi,
Part of my application is static and part is generated at runtime using templates. Until now I have used Smartclient js (to support some runtime generation of the user interface and to make use of some specific js features) but an interesting question is if I can use Smartgwt for the static parts of the application and plain js for the dynamic parts. The plain js part should be able to refer to Smartgwt class names (also the ones we add) and members. Is this possible or am I looking in the wrong direction?
(considering that gwt does obfuscation, which can be/should be turned of also i guess)

gr. Martin

[Isomorphic]

Mixing is possible - obfuscation creates obstacles, but there's both the possibility of turning it off, or extending the GWT compiler to provide non-obfuscated APIs.

But the big question is why - what are you trying to accomplish?

[martintaal]

Hi,
Users have the possibility to add/remove fields, create new views, and add logic in javascript at runtime. So we generate javascript at runtime to accomplish this. However while developing I found that more and more code is in fact static (not generated), to add standard behavior to Smartclient components. This non-generated code could be programmed in java/Smartgwt. At least that's what I am wondering now. So we would have static code using Smartgwt and parts which are generated in javascript (which we load dynamically).

A somewhat related topic is, is it possible to transition gradually from Smartjs to Smartgwt? So can I have part of the components written in SmartGwt and other parts written in Smartjs (and generated at runtime).
I checked the SmartGwt source code and it seems to work/create Smartjs components at runtime.

For example I want to be able to instantiate a Smartgwt-developed component in javascript and set its properties in javascript. Or add a Smartgwt developed subclass of Canvas to a Smartjs layout.
This would make it possible for me to gradually replace our Smartjs components and move them to SmartGwt while still having the main (javascript) application work correctly.

Is this like a feasible scenario or are the great obstacles you see?

gr. Martin

[Isomorphic]

We understand the mechanism, the question was, what is the purpose of doing this?

Looking at superficially, it's substantially more complex, since you'd need JSNI code in various places to interact with your custom JavaScript.

[martintaal]

The first purpose is to be able to transition gradually over to smartgwt, the other is to have more flexibility at runtime.

My idea is that our custom javascript will only be Smartjs components (canvas etc.). So the custom javascript is not something totally different.
So the assumption is that Smartgwt will only need to work with Smartjs components (and the other way around) following the same api/approach as Smartjs, so something like this:
var layout = isc.HLayout.create({});
layout.addMember(isc.myGreatSmartGWTClass.create({}));

As smartgwt components in the end are also based on Smartjs (looking at the source code it seems), it somehow feels feasible... But i am not sure that this is an impossible route to follow.

gr. Martin

[Isomorphic]

If you want more flexibility at runtime, you're best off not introducing GWT at all. GWT doesn't support Java Reflection, and although SmartGWT provides the ability to get around this via JSNI in many cases, that's more complex than just continuing with SmartClient alone.

As far as the SmartGWT/SmartClient boundary, note that while new ListGrid() does ultimately call isc.ListGrid.create(), subclasses and methods written in Java in SmartGWT do not become SmartClient subclasses and ordinary SmartClient methods. It's significantly more complicated than that, and that's one of the reasons why you want to have a very clear reason to mix the technologies - there's quite a bit to understand in order to do so effectively.