[ssequeira]

"Canvas.getById() didn't exist 5 years ago either"

It did.

"It's the same approach. Libraries for doing interapp communication did not exist 5 years ago, so the "boilerplate" you're referring to is just a PoC-level implementation of the same approach used by interapp."

It's not a library, it's a pattern.

"Canvas.getById() was designed for retrieving widgets created by Component XML, it assumes there is no other GWT application around that also has a reference to the underlying SmartClient widget. So when you retrieve a widget this way, you either create a duplicate SmartGWT wrapper for the underlying SC widget, or one GWT app tries to re-use the wrapper from another."

Which one is it? Duplicate wrapper or re-using the wrapper. Can they both happen? If yes, is it random? If not, what decides which behavior is applied?
Am I wrong to assume you would know these details?


From your answers I can't honestly figure out if the use case is valid or not, because throughout your threads you simple state things you believe are facts but are not. And for the concerns you have, you haven't been able to list a single measurable evidence that they are valid. You just consider them valid because you don't support the use case.

-----------------

Memory leak.



See attachment for better visualization.
If you are interested in the raw data I can provide it. I have both timeline and heapprofile.
~2 minute usage / portlets were added and destroyed at a rate of 1/0.5sec.

I haven't done many profiles, especially on JS side, but I'd think this is not a profile which screams memory leak. If it is, you also have a problem in the standard use case, since they look pretty much the same.

------------------

"...crash either at the typecast, or on subsequent invocations, because the method names are obfuscated differently. Which behavior happens probably depends on which version of SmartGWT you're using, because we've made changes over the years in how wrappers are allocated and tracked."

No crash happened so far. So we can dismiss this concern? If a crash or error were to happen, we would see it, no?

------------------

"It also depends on the mode you're running in (compiled vs SDM vs classic DevMode)."

I am interested in compiled mode only, no need to bring new variables to the mix...

------------------

"If we wanted to actually support this use case, we'd need to make a variety of different changes and set up a few new APIs, create docs describing exactly what's valid and invalid in this scenario, but most importantly, we'd create quite a few automated tests to make sure this scenario keeps working."

I come to you with a scenario, describing exactly what it is and what it is doing. You say it does not work, or that it has problems, but don't give any evidence why.

"...but this use case isn't supported until Isomorphic says it is..."

I got the message many replies ago. But the fact that it isn't supported doesn't mean it doesn't work or that it has problems.

"So, if you want this work estimated, let us know."

I approached Isomorphic before starting the thread, asking which way would be the best to handle this case. You, Isomorphic, pointed me to write a thread in the forum.

[Isomorphic]

Yes, if you look at compiled mode only, and you set things up so that both projects use the exact same obfuscated names, you can get through the limited demo you've shown, because one application will actually use the wrapper object from the other application, not realizing it is even a foreign application's object.

We were already aware of this.

The reason we didn't bring it up is that it is yet another useless result: it's not reasonable to limit testing to only compiled mode, nor is it reasonable to impose all the rules that would guarantee perfectly matching obfuscated names - certainly not when other approaches, like the one we showed 5 years ago, have no such limitations!

If you want to see the issues we are talking about, run in other modes, or just compile in such a way that obfuscated names won't match.

I approached Isomorphic before starting the thread, asking which way would be the best to handle this case. You, Isomorphic, pointed me to write a thread in the forum.

We did indeed invite you to post to the forums, anticipating a fruitful Q&A session. We certainly did not expect you would start a long thread repeatedly and erroneously trying to contradict our answers, which has been a monumental waste of time - remember, we showed you the right way to do this 5 years ago!

When you are ready to proceed with the working approach, let us know, and we can estimate the remaining work.

In the meantime, please understand that we can't waste any more time explaining exactly how you are going down a dead end. We've covered the same basic concept (obfuscated names won't match) in 3 or 4 different guises now, you have more than enough information to connect the remaining dots on your own, without further help from us.

[ssequeira]

"Yes, if you look at compiled mode only, and you set things up so that both projects use the exact same obfuscated names, you can get through the limited demo you've shown, because one application will actually use the wrapper object from the other application, not realizing it is even a foreign application's object. "

This works for me, limited as it may be.

[Isomorphic]

To recap:

1. We showed you an approach that allows any development mode to be used, and doesn't involve using APIs in an unsupported manner

2. You prefer an approach that restricts testing to compiled mode, requires teams to closely coordinate to ensure obfuscated names match perfectly, and uses SmartGWT APIs in an unsupported manner

It's nice that you have that preference, but, as far as this becoming a supported usage of SmartGWT, we would not accept a project to take approach #2, since it's obviously worse in every way - more effort for a much much less usable solution.