[jquery-dev] Re: window === window.top false in IE8, thus late ready...
Klaus Hartl wrote: > Hi all, in IE8 > > window === window.top > > is false, whereas > > window == window.top This may already be common knowledge, but it is new to me HTML5 mandates that window.top, window.parent, etc. all be WindowProxy objects rather than true Window objects. A WindowProxy acts just like a Window object because all of its properties are proxied directly to a Window. A Window and a WindowProxy are not the same object, however, and so they are not === to each other. I'm a little surprised that they are actually == to each other in IE8, but maybe that's the way all the browser vendors will do it. One fix to the code would be to use == instead of ===. Another, I suppose might be to test something like: window.top.document === window.document (The DOM isn't ready when this code is executed, but the document object exists, doesn't it?) I haven't seen an explanation of why the WindowProxy is necessary, though I suppose that something must exist in the HTML 5 mailing lists. I'd love to understand this, if anyone has pointers. David > evaluates to true. Because of this the ready event will always rely on > document's onreadystatechange event instead of using Diego Perini's > doScroll trick, see line 833 in event.js. I assume his trick is better > in terms if "earliness". > > Can somebody please confirm this? Or is it that we want to rely on the > event in IE8? > > > --Klaus > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: prototypal inheritance as part of jQuery core?
:-) For what its worth, the next edition of the book will have more focus on prototypal inheritance and somewhat less emphasis on classical inheritance patterns. And also a chapter on jQuery. David Michael Geary wrote: > Well! Maybe you *should* read a good book on JavaScript before you go making > careless posts again. > > All we know about here is jQuery, but the guys on comp.lang.javascript said > there's only one good JavaScript book. > > Definitive something or other. It shouldn't be too hard to track down. > > I hear it's pretty good, maybe you could learn something from it! > > -Mike > >> From: David Flanagan >> >> My carelessness, however, is not sufficient reason for you to >> accuse me of posting without reading or thinking. This is a >> -dev level mailing list. You must assume that all posters >> here are well-read and thoughtful. Otherwise you sound paternalistic! > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: prototypal inheritance as part of jQuery core?
You're right: the constructor property doesn't work property even in an unoptimized beget() function. I retract my previous message. I sent it without testing my assertion. That was careless, and I apologize. My carelessness, however, is not sufficient reason for you to accuse me of posting without reading or thinking. This is a -dev level mailing list. You must assume that all posters here are well-read and thoughtful. Otherwise you sound paternalistic! David Flanagan Andrea Giammarchi wrote: > David, read carefully, think, and try again > > On Tue, Aug 11, 2009 at 11:16 PM, David Flanagan > mailto:da...@davidflanagan.com>> wrote: > > > Of course, if you optimize it in this way to share a single constructor > function, you can't find the prototype of an object created with beget() > with o.constructor.prototype. Not sure how important that is, but there > is a downside to the optimization. > >David > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: prototypal inheritance as part of jQuery core?
Of course, if you optimize it in this way to share a single constructor
function, you can't find the prototype of an object created with beget()
with o.constructor.prototype. Not sure how important that is, but there
is a downside to the optimization.
David
Andrea Giammarchi wrote:
> Dunno how many times that bedge has been optimized ;-)
>
> (function(){
> var F = function(){};
> jQuery.beget = function (proto, props) {
> F.prototype = proto;
> return props ? $.extend(new F, props) : new F;
> };
> })();
>
> Regards
>
>
> On Thu, Jul 30, 2009 at 3:48 PM, Már Örlygsson > wrote:
>
>
> Hi.
> If it hasn't been already considered (and rejected), I'd like to float
> the idea of adding support for prototypal inheritance into the jQuery
> core library.
>
> Something like this...
>
>jQuery.beget = function (proto, props) {
>var F = function () {};
>F.prototype = proto;
>var instance = new F();
>return props ? $.extend(instance, props) : instance;
> };
>
> ...becomes immensely powerful - especially during plugin development
> when allowing users to extend/override default options
>
>options = $.beget($.myplugin.defaults, options || {});
>
> ...and in various other common use cases - including $.fn.data()
> assignments, etc.
>
>
> I for one would love to see this feature added.
>
> --
> Már
>
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: prototypal inheritance as part of jQuery core?
If you're going to add a beget() function, you ought to plan for how it
is going to interact with the Object.create() function coming in es5...
My concern is that it will be confusing to have functions like beget
that take plain objects as sets of properties to copy when
Object.create() takes a set of property descriptors instead. I suggest
that you might want to keep object creation and object extension
separate and require an idiom like this:
$.extend($.beget(proto), props)
David
Andrea Giammarchi wrote:
> Dunno how many times that bedge has been optimized ;-)
>
> (function(){
> var F = function(){};
> jQuery.beget = function (proto, props) {
> F.prototype = proto;
> return props ? $.extend(new F, props) : new F;
> };
> })();
>
> Regards
>
>
> On Thu, Jul 30, 2009 at 3:48 PM, Már Örlygsson > wrote:
>
>
> Hi.
> If it hasn't been already considered (and rejected), I'd like to float
> the idea of adding support for prototypal inheritance into the jQuery
> core library.
>
> Something like this...
>
>jQuery.beget = function (proto, props) {
>var F = function () {};
>F.prototype = proto;
>var instance = new F();
>return props ? $.extend(instance, props) : instance;
> };
>
> ...becomes immensely powerful - especially during plugin development
> when allowing users to extend/override default options
>
>options = $.beget($.myplugin.defaults, options || {});
>
> ...and in various other common use cases - including $.fn.data()
> assignments, etc.
>
>
> I for one would love to see this feature added.
>
> --
> Már
>
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Proposal: New parameter to traversal callbacks
What about the performance implications of creating those jQuery objects
for each call? Could you check the length property of the callback
function and only pass the jQuery object if it is actually declared to
expect 2 arguments?
What about modifying each() so that it passes three arguments to its
callback: the index, the element, and the wrapped element:
function(i, e, $e) { // e === $e[0] }
That avoids the compatibility problem, but loses the parallel with the
other methods, unless you pass both e and $e to their callback as well.
David
John Resig wrote:
> A quick example:
>
> $(".msg").each(function(i, $this){
> $(".hide", this).click(function(){
> $this.hide();
> });
> });
>
> I actually proposed this set of changes to Yehuda on IM and then had a
> back and forth as to how to best implement them. I think they actually
> hold some promise. I like this since it's relatively pain-free which
> helping to reduce extra syntax (when dealing with closures in jQuery
> it's common that you'll need to declare references to the wrapped jQuery
> set - something that this avoids).
>
> The proposal is a set of 3 changes - each change is making the second
> argument of a callback function equal to $(this).
>
> - Modifying existing callbacks that have no second argument (like
> .filter, as Yehuda mentioned).
> - Modifying event callbacks to have a second argument be $(this)
> (which, can conflict with .trigger(event, data)).
> - Modifying each callbacks to have a second argument be $(this)
> (replacing the existing second argument of this).
>
> Obviously changing the second incoming argument to
> .each(function(i,$this)) is going to require a little bit of finesse. I
> did a quick search on Google Codesearch but didn't see any immediate
> warning signs:
> http://www.google.com/codesearch?hl=en&lr=&q=
> \.each\%28\s*function\%28\s*\w%2B%2C\s*\w%2B\s*\%29+lang%3Ajavascript&sbtn=Search
>
> If we make a change like this I would like it to be an all-or-nothing
> proposition (having a half-baked API modification landing seems kind of
> lame) BUT it must be done in a way that we're sure won't break important
> code. (At the very least, a change like this would have to be done in a
> major 1.x release.)
>
> A quick note: It's probably important to use function(i, $this) in the
> examples (to help differentiate it from a "normal" self [which generally
> equates to var self = this;]).
>
> --John
>
>
> On Mon, Jul 20, 2009 at 11:14 PM, Yehuda Katz > wrote:
>
> At the moment, traversal callbacks, like the ones passed to
> find/filter/etc. take a single "index" parameter. I'd like to
> propose that they are unified with .each as follows:
>
> $("div").filter(function(i, self) {
> // stuff
> });
>
> As a separate concern, I'd like to discuss changing the second
> parameter in both to be a jQuery object. Obviously, it would need to
> be done via slow deprecation for .each, but I don't think it'd break
> all that much code:
>
> $("div").filter(function(i, self) {
> // self == $(this)
> })
>
> Thoughts?
>
> --
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
>
>
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Static regexps
Nick Fitzsimons wrote: > 2009/7/20 Ariel Flesler : >> I'm really aware of how the different interpreters work, but it seems to me >> that immutable literals (strings, numbers, regexps) are the first thing I'd >> cache in a constant. Maybe current interpreters do that already internally ? >> > ECMA-262 3rd Edition section 7.8.5 [1] states: > > "A regular expression literal is an input element that is converted to > a RegExp object (section 15.10) > when it is scanned. The object is created before evaluation of the > containing program or function begins. > Evaluation of the literal produces a reference to that object; it does > not create a new object." This is changing in ECMAScript 5. Each evaluation of a regexp literal will (in the future) create a new object. (I think IE already does this, and they got this one right. The other browser vendors will change their implementations to match.) So this is the perfect time for John to be minimizing the number of literals in the program. David Flanagan > So inline regular expressions are not evaluated multiple times, they > are turned into a RegExp object at compile time and become a reference > to that object. This means that there is unlikely to be any benefit > from assigning them to a variable, and if dereferencing that variable > takes longer than simply dereferencing the RegExp object reference, > then moving them to the variable would actually decrease performance. > > I would assume that this is something that all JS engines have > implemented correctly, as it would take more work to _fail_ to > implement it according to spec. Certainly, Microsoft's document > "JScript Deviations from ES3" [2] has no mention of JScript's > implementation violating this portion of the spec. > > RegExp objects created at runtime using the RegExp constructor would > however benefit from caching; in fact I applied this technique in my > own implementation of getElementsByClassName a couple of years ago. > > Cheers, > > Nick. > > [1] <http://www.ecma-international.org/publications/standards/Ecma-262.htm> > [2] > <http://wiki.ecmascript.org/lib/exe/fetch.php?id=resources%3Aresources&cache=cache&media=resources:jscriptdeviationsfromes3.pdf> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] more about wrap() methods
If I do this:
$("h1").wrap("")
Then I get two copies of each of the h1 tags. The return value of the
wrap() method does not include the extra copies, however. Is this a bug?
If so, maybe change this line in wrapAll:
var wrap = jQuery( html, this[0].ownerDocument).clone();
To this:
var wrap = jQuery( html, this[0].ownerDocument).eq(0).clone();
David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] wrap(), wrapAll(), wrapInner()
If the argument to a wrap function is a string that contains text, it
doesn't do what I'd expect it to.
For example: $("h1").wrap("\u00a7")
I'd expect that to wrap all h1 elements in tags, with a section sign
(\u00a7) before the h1.
I think the following patch to wrapAll() fixes it. On the other hand,
it doesn't make this work: $("h1").wrap("\u00a7"), so
perhaps this is a documentation bug: maybe the docs just need to be more
explicit about the legal arguments to the wrap() methods.
David
Index: manipulation.js
===
--- manipulation.js (revision 6415)
+++ manipulation.js (working copy)
@@ -28,7 +28,7 @@
wrap.map(function(){
var elem = this;
- while ( elem.firstChild )
+ while ( elem.firstChild &&
elem.firstChild.nodeType == 1)
elem = elem.firstChild;
return elem;
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Re: Proposal: $("'text") for $(document.createTextNode(text))
John Resig wrote:
> Well, you could also do:
> $("h1").prepend("§");
Yeah. I didn't mean to imply that my code was a serious use-case. Its
just where I tripped myself up, thinking I could create a jQuery object
that held "html" text that didn't happen to have any angle brackets in
it :-). It was kind of surprising to realize that I needed to call
createTextNode explicitly in that case. And so I proposed this syntax
as a cool shortcut for createTextNode()
> The reasoning behind handling selectors (and HTML) in $(...) and then
> later appending/prepending/etc. them into the document is that you can
> modify them in the interim.
>
> For example:
> $("Something").click(function(){ }).prependTo("div.section");
That's pretty cool. I think I would have assumed that elements had to
be inserted before doing other things with them.
> Whereas there's really no associated use case for pure text nodes
So I guess you're saying that there shouldn't be a need to work with
text nodes, so no shortcut is necessary. Fair enough.
David
> --John
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
[jquery-dev] Proposal: $("'text") for $(document.createTextNode(text))
I'd like to propose that the jQuery() function accept a simple new
syntax to allow it to create simple text nodes. If the string argument
begins with an apostrophe, then treat the rest of the argument as plain
text and return a jQuery object that wraps a single text node.
I ask for this because I was trying to do this:
$("§").prependTo("h1");
Then I realized that since my string doesn't contain any angle brackets
it is being treated as a selector rather than as a string of HTML, and I
have to write this:
$(document.createTextNode("§")).prependTo("h1");
I don't know how valuable this feature would be, but I've attached a
simple (and barely tested) patch to implement it.
With the patch, the code above gets a single apostrophe added to it and
becomes:
$("'§").prependTo("h1");
David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
Index: core.js
===
--- core.js (revision 6415)
+++ core.js (working copy)
@@ -17,7 +17,7 @@
// A simple way to check for HTML strings or ID strings
// (both of which we optimize for)
- quickExpr = /^[^<]*(<(.|\s)+>)[^>]*$|^#([\w-]+)$/,
+ quickExpr = /^[^<]*(<(.|\s)+>)[^>]*$|^#([\w-]+)$|^'(.*)$/,
// Is it a simple selector
isSimple = /^.[^:#\[\.,]*$/,
@@ -51,24 +51,28 @@
// Handle HTML strings
if ( typeof selector === "string" ) {
- // Are we dealing with HTML string or an ID?
+ // Are we dealing with HTML string or an ID or a text
node?
match = quickExpr.exec( selector );
// Verify a match, and that no context was specified
for #id
- if ( match && (match[1] || !context) ) {
+ if ( match && (match[1] || match[4] || !context) ) {
// HANDLE: $(html) -> $(array)
if ( match[1] ) {
selector = jQuery.clean( [ match[1] ],
context );
- // HANDLE: $("#id")
+ // HANDLE: $("#id") and $("'text")
} else {
- elem = document.getElementById(
match[3] );
+ if ( match[3] ) {
+ elem = document.getElementById(
match[3] );
- // Handle the case where IE and Opera
return items
- // by name instead of ID
- if ( elem && elem.id !== match[3] ) {
- return rootjQuery.find(
selector );
+ // Handle the case where IE and
Opera return items
+ // by name instead of ID
+ if ( elem && elem.id !==
match[3] ) {
+ return rootjQuery.find(
selector );
+ }
+ } else {
+ elem = document.createTextNode(
match[4] );
}
// Otherwise, we inject the element
directly into the jQuery object
[jquery-dev] Re: #4876: various documentation bugs
Thanks. Last time I tried that it said the pages were locked or something. Seems to work for me now, however. David Jörn Zaefferer wrote: > They are all edited on the wiki (docs.jquery.com); you need to > register and login to edit. > > Jörn > > On Jul 14, 7:52 pm, David Flanagan wrote: >> Thanks for these fixes. I don't see the docs anywhere in the SVN tree. >> If someone tells me where they are, I can try to submit patches if >> I've got other nits to pick with them... >> >> David >> >> jQuery wrote: >>> #4876: various documentation bugs >>> +--- >>> Reporter: davidflanagan | Owner: >>> Type: bug| Status: new >>> Priority: minor | Milestone: 1.3.3 >>> Component: docs | Version: 1.3.2 >>> Resolution: |Keywords: >>> Need: Review | >>> +--- >>> Comment(by joern): >>> I've updated the css() docs, though that probably needs improvements: >>> http://docs.jquery.com/CSS/css > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] Re: [jQuery] #4876: various documentation bugs
Thanks for these fixes. I don't see the docs anywhere in the SVN tree. If someone tells me where they are, I can try to submit patches if I've got other nits to pick with them... David jQuery wrote: > #4876: various documentation bugs > +--- > Reporter: davidflanagan | Owner: > Type: bug| Status: new > Priority: minor | Milestone: 1.3.3 > Component: docs | Version: 1.3.2 > Resolution: |Keywords: > Need: Review | > +--- > > Comment(by joern): > > I've updated the css() docs, though that probably needs improvements: > http://docs.jquery.com/CSS/css > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~--~~~~--~~--~--~---
[jquery-dev] bug in 1.3.3pre version of attr()
The 1.3.3pre version of the attr() method doesn't handle object
arguments where property values are functions in the same way that 1.3.2
does (and the way that the docs say it should). I think because in the
code reorganization the jQuery.prop() helper function went away. I
believe that a very similar bug exists in the css() method, but I
haven't looked closely enough at it.
I can't figure out how to submit a bug report against 1.3.3pre, so I'm
posting this here. Let me know if I should file it as a bug against
some other version on the tracker.
I've attached a patch to src/attributes.js and also to
tests/unit/attributes.js
In my patch I also try to optimze the (I assume common) case where
attr() is called with two arguments. It no longer creates and then
iterates over a new object in this case. But it does make the code
slightly longer.
David Flanagan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~--~~~~--~~--~--~---
Index: test/unit/attributes.js
===
--- test/unit/attributes.js (revision 6415)
+++ test/unit/attributes.js (working copy)
@@ -68,12 +68,15 @@
});
test("attr(Hash)", function() {
- expect(1);
+ expect(3);
var pass = true;
jQuery("div").attr({foo: 'baz', zoo: 'ping'}).each(function(){
if ( this.getAttribute('foo') != "baz" &&
this.getAttribute('zoo') != "ping" ) pass = false;
});
ok( pass, "Set Multiple Attributes" );
+ equals( jQuery('#text1').attr({'value': function() { return this.id;
}})[0].value, "text1", "Set attribute to computed value #1" );
+ equals( jQuery('#text1').attr({'title': function(i) { return i;
}}).attr('title'), "0", "Set attribute to computed value #2");
+
});
test("attr(String, Object)", function() {
@@ -334,9 +337,9 @@
e.toggleClass(false);
e.toggleClass();
ok( e.is(".testD.testE"), "Assert class present (restored from data)" );
-
-
+
+
// Cleanup
e.removeClass("testD");
e.removeData('__className__');
Index: src/attributes.js
===
--- src/attributes.js (revision 6415)
+++ src/attributes.js (working copy)
@@ -1,34 +1,30 @@
jQuery.fn.extend({
attr: function( name, value ) {
- var options = name, isFunction = jQuery.isFunction( value );
+ var elem, options;
- if ( typeof name === "string" ) {
- // Are we setting the attribute?
- if ( value === undefined ) {
+ if ( typeof name === "string" ) { // A single attribute
+ if ( value === undefined ) {// Query it on
first element
return this.length ?
jQuery.attr( this[0], name ) :
null;
-
- // Convert name, value params to options hash format
- } else {
- options = {};
- options[ name ] = value;
+ } else {// Set it on all
elements
+ for ( var i = 0, l = this.length; i < l; i++ ) {
+ elem = this[i];
+ if ( jQuery.isFunction(value) )
+ value = value.call(elem,i);
+ jQuery.attr( elem, name, value );
+ }
}
- }
-
- // For each element...
- for ( var i = 0, l = this.length; i < l; i++ ) {
- var elem = this[i];
-
- // Set all the attributes
- for ( var prop in options ) {
- value = options[prop];
-
- if ( isFunction ) {
- value = value.call( elem, i );
+ } else { // Multiple attributes to
set on all
+ options = name;
+
