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? > > >> >> > > > > >> >> > > > >> >> > > >> > > >
