"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.
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.
Comment