rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erin Noe-Payne <erin.noe.pa...@gmail.com>
Subject Re: Require.js in 0.22
Date Mon, 01 Jul 2013 14:32:04 GMT
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
<erin.noe.payne@gmail.com> 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 <m.ben.franklin@gmail.com> wrote:
>> On Wed, Jun 19, 2013 at 10:25 AM, Chris Geer <chris@cxtsoftware.com> wrote:
>>
>>> On Wed, Jun 19, 2013 at 6:28 AM, Erin Noe-Payne <erin.noe.payne@gmail.com
>>> >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 <chris@cxtsoftware.com>
>>> 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 <chris@cxtsoftware.com
>>> > <javascript:;>>
>>> > >> wrote:
>>> > >> > On Mon, Jun 17, 2013 at 5:32 AM, Matt Franklin <
>>> > m.ben.franklin@gmail.com<javascript:;>
>>> > >> >wrote:
>>> > >> >
>>> > >> >> On Mon, Jun 17, 2013 at 8:29 AM, Sean Cooper <secooper@apache.org
>>> > <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" <
>>> > erin.noe.payne@gmail.com<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?
>>> > >> >> > >
>>> > >> >> >
>>> > >> >>
>>> > >>
>>> >
>>>

Mime
View raw message