Hi All, The require.js branch is nearing completion, and I expect it will be ready to bring back into trunk within the next day or two. Should the merge be submitted as a patch through the review board, or should I just go ahead with it when it is ready, and provide an 0.21 -> 0.22 guide?
On Thu, Jun 20, 2013 at 5:20 PM, Erin Noe-Payne <[email protected]> wrote: > Hey all, just to be clear since Dan's patch created a bit of confusion > - I created a "require" branch for this task. Since this is a pretty > broad change I felt we needed a branch to collaborate and complete the > changes. I am expecting a number of patches to be submitted against it > in the next couple weeks. > > Let me know if there are any concerns. > > On Wed, Jun 19, 2013 at 6:43 PM, Matt Franklin <[email protected]> > wrote: >> On Wed, Jun 19, 2013 at 10:25 AM, Chris Geer <[email protected]> wrote: >> >>> On Wed, Jun 19, 2013 at 6:28 AM, Erin Noe-Payne <[email protected] >>> >wrote: >>> >>> > Specifically, the idea of require js is to take all references off of >>> > the global namespace and to build out and resolve a dependency tree >>> > for your client side code. So if we made it optional, then someone >>> > who wanted to take advantage of the feature would need to overlay any >>> > place where there is a reference to the global rave object. That >>> > includes jsps where there is a script block that uses rave.*, and wrap >>> > that in a require block. You would also need to overlay the java class >>> > that inserts rave.registerWidget(...) onto the page and wrap those in >>> > require blocks. Also any jsp that has an onclick="rave.*" event >>> > handler, those would need to be moved to jquery bindings and wrapped >>> > in require blocks. Once you had that you would overlay the >>> > rave_script.js tag so that instead of link all the scripts, you just >>> > reference require.js with a data-main attribute pointing to your >>> > bootstrapping script. (See http://requirejs.org/docs/start.html). >>> > >>> > If instead we make a breaking change, then we would do all of the >>> > above work on trunk. An implementer who wanted to go to 0.22 would >>> > then be responsible for updating their scripts to be written as AMD >>> > modules (http://requirejs.org/docs/api.html#define). The script is >>> > wrapped in a require block, remove all references to global namespace >>> > objects and instead require those in. Any additional third party >>> > scripts you use will need to be added to the require config >>> > (http://requirejs.org/docs/api.html#jsfiles). >>> > >>> >>> Thanks Erin, my gut says if we make it optional no one (but maybe Mitre) >>> would use it in 0.22 due to the complexity of enabling it. Making it >>> optional is a breaking change but it sounds like it's a manageable amount >>> of work on implementors. I'll stick by my position that I'm ok with making >>> it required in 0.22 since it will be breaking eventually and the optional >>> track won't help get people prepared (just cause extra work). >>> >> >> >> +1 >> >> >> >>> >>> Chris >>> >>> > >>> > >>> > On Tue, Jun 18, 2013 at 6:24 PM, Chris Geer <[email protected]> >>> wrote: >>> > > What would be required exactly? >>> > > >>> > > On Tuesday, June 18, 2013, Erin Noe-Payne wrote: >>> > > >>> > >> If we make it optional, we will basically be conditionally AMD >>> > >> defining the rave js, and to actually use require it would be on an >>> > >> implementer to overlay every file that has script tags or inline >>> > >> "onclick" events. In other words it would be a big pain and not really >>> > >> worth it unless you really wanted the value of require.js immediately >>> > >> - at MITRE we would do that though. It would mostly just be giving 1 >>> > >> release warning that the old method will be deprecated. >>> > >> >>> > >> Personally I think the breaking change will be cleaner and more >>> > >> consistent with the end state of the angular application. But as it >>> > >> will force some amount of work on current implementations wanting to >>> > >> go to 0.22, I don't want to go that route unless there is buy-in. >>> > >> >>> > >> On Tue, Jun 18, 2013 at 6:10 PM, Chris Geer <[email protected] >>> > <javascript:;>> >>> > >> wrote: >>> > >> > On Mon, Jun 17, 2013 at 5:32 AM, Matt Franklin < >>> > [email protected]<javascript:;> >>> > >> >wrote: >>> > >> > >>> > >> >> On Mon, Jun 17, 2013 at 8:29 AM, Sean Cooper <[email protected] >>> > <javascript:;>> >>> > >> wrote: >>> > >> >> >>> > >> >> > I am ok with a breaking change as long as it is clearly called >>> out >>> > in >>> > >> the >>> > >> >> > release notes. I am worried that someone will get caught off >>> > guard by >>> > >> >> this >>> > >> >> > break. >>> > >> >> > >>> > >> >> >>> > >> >> IMO, if it isn't a significant effort we should deprecate the old >>> > way in >>> > >> >> 0.22 and go with the optional support for Require.js. >>> > >> >> >>> > >> > >>> > >> > How hard will it be to turn on the feature? If it's overly >>> complicated >>> > >> > there might not be much value in even putting it in as an optional >>> > >> feature. >>> > >> > If it's not too bad and we can document it well then optional is >>> fine. >>> > >> > Otherwise I wouldn't be against the breaking change since we are >>> still >>> > >> > pre-1.0 and breaking changes are pretty normal (0.21 was breaking as >>> > >> well). >>> > >> > >>> > >> > Chris >>> > >> > >>> > >> >> >>> > >> >> >>> > >> >> > On Jun 16, 2013 11:08 PM, "Erin Noe-Payne" < >>> > [email protected]<javascript:;> >>> > >> > >>> > >> >> > wrote: >>> > >> >> > >>> > >> >> > > Hey All, >>> > >> >> > > >>> > >> >> > > As I mentioned in the rave-angular thread, Require.js will be >>> an >>> > >> >> > > important part of the angular branch architecture. I am >>> thinking >>> > it >>> > >> >> > > would be reasonable to introduce AMD support into the trunk >>> even >>> > >> >> > > before we release the angular branch, to offer the performance >>> > >> >> > > benefits sooner and to introduce the new paradigm. My initial >>> > >> thought >>> > >> >> > > is to make AMD support optional and off by default, to avoid >>> > >> breaking >>> > >> >> > > changes. That would involve... >>> > >> >> > > >>> > >> >> > > - A couple new rave core and rave portal js files introduced to >>> > >> align >>> > >> >> > > with require.js modules, jsp tags updated accordingly. >>> > >> >> > > - Each of those js files checks for the existence of requirejs >>> in >>> > >> the >>> > >> >> > > environment and wraps itself in a define() if yes, otherwise >>> acts >>> > >> the >>> > >> >> > > same as before. >>> > >> >> > > >>> > >> >> > > In this scenario anyone who wanted to take advantage of >>> > require.js >>> > >> >> > > would need to do some amount of overlaying to introduce >>> require, >>> > >> >> > > update the script jsp tags, and so on. >>> > >> >> > > >>> > >> >> > > Alternatively, if there is interest we could introduce require >>> > as a >>> > >> >> > > breaking change for 0.22 and integrate the require.js optimizer >>> > into >>> > >> >> > > the build process. The advantage would be no need to overlay to >>> > get >>> > >> >> > > AMD support, the disadvantage is any implementation updating to >>> > 0.22 >>> > >> >> > > would need to update their container scripts to be compatible >>> > with >>> > >> >> > > AMD. In either case this would have no impact on gadgets. >>> > >> >> > > >>> > >> >> > > Thoughts? >>> > >> >> > > >>> > >> >> > >>> > >> >> >>> > >> >>> > >>>
