Re: [gwt-contrib] Phasing in a new, unified linker
I don't have a strong opinion about it. They can be non-final, with simply no particular effort to truly make them extensible. > I think it might be possible to move the template JS files to > GWT-translated code with extension points managed through rebinding and > overriding. Until then, making changes that involve JS modifications > effectively require you to cut and paste the whole file. > > There is now some templating, by the way. You asked about the __COMPUTE_SCRIPT_BASE__ reference. SelectionScriptLinker -- the base class for all the linkers in the subject line -- substitutes that string for the contents of computeScriptBase.js, a file included within gwt-user.jar. Thus, linkers that want the standard implementation of computeScriptBase() can simply include that string rather than copying the whole chunk of JS. Such templating is pretty limited even in principle, however, and in practice it's so far only done for that file and for one other one. Incidentally, you mention moving code into Java. That strategy actually came to pass for runAsync code fetching. Originally, linkers would emit a function that the code loader calls to download code. Now, there is a deferred binding, and the choice of linker causes the deferred binding choice to differ. Thus, code loaders are now simply Java classes that implement a simple Java interface. It's much easier to maintain. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Phasing in a new, unified linker
On 2010-07-26, at 4:56 PM, John Tamplin wrote: > Is the new linker designed to curtail extension, or to sanely encourage it? > The existing primary linkers ended up getting extended in brittle ways. > > That's a good point. Let's make it a final class to start with, and open up > extension points later as issues come up. There are no known needs for > extensions at this point. > > Well, we do know there will be other linkers, and if there aren't extension > points defined they will be done via cut-and-paste, which is what led to the > current state we are in. I'd prefer if these classes weren't final, with a big warning that they may have breaking changes, even in minor revisions. I don't know if it's possible to predict every tweak that developers might want to make to the primary linker, but allowing a subclass to just specify a different template script certain covers a great deal of ground. With the current hybrid JS/Java approach to linking, I think it would be very difficult to properly support any extensibility. I think it might be possible to move the template JS files to GWT-translated code with extension points managed through rebinding and overriding. Until then, making changes that involve JS modifications effectively require you to cut and paste the whole file. Matt. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Phasing in a new, unified linker
On Mon, Jul 26, 2010 at 6:56 PM, John Tamplin wrote: > > Well, we do know there will be other linkers, and if there aren't extension > points defined they will be done via cut-and-paste, which is what led to the > current state we are in. No question that extension points are useful. Let's add them, but only when we have an idea of what we are supporting with them. Note that IFrameLinker and XSLinker have several extension points, and yet nonetheless there is a lot of cut and paste going on. We didn't add (all of) the ones that people really ended up needing. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Phasing in a new, unified linker
On Mon, Jul 26, 2010 at 6:27 PM, Lex Spoon wrote: > On Mon, Jul 26, 2010 at 12:37 PM, Scott Blum wrote: > >> SGTM as far as process. >> >> Is the new linker designed to curtail extension, or to sanely encourage >> it? The existing primary linkers ended up getting extended in brittle ways. >> > > That's a good point. Let's make it a final class to start with, and open up > extension points later as issues come up. There are no known needs for > extensions at this point. > Well, we do know there will be other linkers, and if there aren't extension points defined they will be done via cut-and-paste, which is what led to the current state we are in. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Phasing in a new, unified linker
On Mon, Jul 26, 2010 at 12:37 PM, Scott Blum wrote: > SGTM as far as process. > > Is the new linker designed to curtail extension, or to sanely encourage it? > The existing primary linkers ended up getting extended in brittle ways. > That's a good point. Let's make it a final class to start with, and open up extension points later as issues come up. There are no known needs for extensions at this point. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Phasing in a new, unified linker
[+matt, who's one of the few people I know outside of Google creating custom linkers] I'm 100% on board with this as well. These things weren't all that carefully designed for extension from the beginning, so it's going to be difficult to make significant changes to them without breaking existing linker extensions. Having one "true" linker, except for fundamentally different cases (like Chrome and Firefox extensions) would be hugely convenient. Le 26 juillet 2010 12:37, Scott Blum a écrit : > SGTM as far as process. > > Is the new linker designed to curtail extension, or to sanely encourage it? > The existing primary linkers ended up getting extended in brittle ways. > > On Mon, Jul 26, 2010 at 12:06 PM, Lex Spoon wrote: > >> Joel, Miguel, GWTers, >> >> I am trying to phase in a new linker as the default GWT linker, and I >> could use some feedback on how that is accomplished. >> >> My first thought was to modify the cross-site linker in place, as was >> started by this patch: >> >> http://gwt-code-reviews.appspot.com/674802/show >> >> >> After further thought, though, the changes in that patch are simply not >> backward compatible. The most fundamental problem is that there are >> currently linkers extending the XSLinker class, and any major change to >> XSLinker will break these other ones. Additionally, the cross-site linker >> has $wnd==window, but that's no longer true in the unified linker. Both of >> these problems won't affect most apps, but an indeterminate few will be >> broken by simply committing the above patch. >> >> Here's an alternate phase-in plan that avoids the above two problems: >> >> 1. Make a new linker class and new linker name, so as not to disturb any >> code inheriting from our existing linkers. Commit the above patch under the >> new names. Anyone who can live without dev mode support can use it >> immediately. >> >> 2. Add development mode support to the new linker. >> >> 3. Redirect the "std" linker to the new one. We could add a deprecated >> "iframe" name for the iframe linker for anyone who desperately needs it. >> Note that people using the "std" linker must already be using $wnd in the >> necessary places. >> >> 4. Deprecate the iframe and xs linkers, and after a year or two remove >> them. Users of the cross-site linker will need to make sure they use $wnd in >> the right places before they change over. >> >> >> A benefit of this approach is that most apps use the "std" linker and will >> simply pick up the improvements without needing any changes. Updating people >> currently on the cross-site linker is trickier, but I don't see any way to >> get around the $wnd/window problem. Their code simply needs to be updated. >> >> -Lex >> >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Phasing in a new, unified linker
SGTM as far as process. Is the new linker designed to curtail extension, or to sanely encourage it? The existing primary linkers ended up getting extended in brittle ways. On Mon, Jul 26, 2010 at 12:06 PM, Lex Spoon wrote: > Joel, Miguel, GWTers, > > I am trying to phase in a new linker as the default GWT linker, and I could > use some feedback on how that is accomplished. > > My first thought was to modify the cross-site linker in place, as was > started by this patch: > > http://gwt-code-reviews.appspot.com/674802/show > > > After further thought, though, the changes in that patch are simply not > backward compatible. The most fundamental problem is that there are > currently linkers extending the XSLinker class, and any major change to > XSLinker will break these other ones. Additionally, the cross-site linker > has $wnd==window, but that's no longer true in the unified linker. Both of > these problems won't affect most apps, but an indeterminate few will be > broken by simply committing the above patch. > > Here's an alternate phase-in plan that avoids the above two problems: > > 1. Make a new linker class and new linker name, so as not to disturb any > code inheriting from our existing linkers. Commit the above patch under the > new names. Anyone who can live without dev mode support can use it > immediately. > > 2. Add development mode support to the new linker. > > 3. Redirect the "std" linker to the new one. We could add a deprecated > "iframe" name for the iframe linker for anyone who desperately needs it. > Note that people using the "std" linker must already be using $wnd in the > necessary places. > > 4. Deprecate the iframe and xs linkers, and after a year or two remove > them. Users of the cross-site linker will need to make sure they use $wnd in > the right places before they change over. > > > A benefit of this approach is that most apps use the "std" linker and will > simply pick up the improvements without needing any changes. Updating people > currently on the cross-site linker is trickier, but I don't see any way to > get around the $wnd/window problem. Their code simply needs to be updated. > > -Lex > > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Phasing in a new, unified linker
Joel, Miguel, GWTers, I am trying to phase in a new linker as the default GWT linker, and I could use some feedback on how that is accomplished. My first thought was to modify the cross-site linker in place, as was started by this patch: http://gwt-code-reviews.appspot.com/674802/show After further thought, though, the changes in that patch are simply not backward compatible. The most fundamental problem is that there are currently linkers extending the XSLinker class, and any major change to XSLinker will break these other ones. Additionally, the cross-site linker has $wnd==window, but that's no longer true in the unified linker. Both of these problems won't affect most apps, but an indeterminate few will be broken by simply committing the above patch. Here's an alternate phase-in plan that avoids the above two problems: 1. Make a new linker class and new linker name, so as not to disturb any code inheriting from our existing linkers. Commit the above patch under the new names. Anyone who can live without dev mode support can use it immediately. 2. Add development mode support to the new linker. 3. Redirect the "std" linker to the new one. We could add a deprecated "iframe" name for the iframe linker for anyone who desperately needs it. Note that people using the "std" linker must already be using $wnd in the necessary places. 4. Deprecate the iframe and xs linkers, and after a year or two remove them. Users of the cross-site linker will need to make sure they use $wnd in the right places before they change over. A benefit of this approach is that most apps use the "std" linker and will simply pick up the improvements without needing any changes. Updating people currently on the cross-site linker is trickier, but I don't see any way to get around the $wnd/window problem. Their code simply needs to be updated. -Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
