Quick question:
Is there a legitimate reason other than writing less code for chaining
methods? Specifically, is there a performance advantage other than
overall site performance thanks to download speeds as a consequence of
less code?
In the example I have:
this.element = new Element("div");
this.element.addClassName( this.settings.className );
this.element.absolutize();
this.element.hide();
and I know I can write this like so:
this.element = new Element("div",
{"class":this.settings.className}).absolutize().hide();
but was wondering about the benefit. I don't like chaining too many
methods b/c after a certain point I find them difficult to read but I
will if there's a good reason for it.
PS: I'm trying to avoid doing the multiline chaining:
this.element = new Element("div",{"class":this.settings.className})
.absolutize()
.hide();
Thanks!
On Jun 5, 12:27 am, Luisgo <lgo...@gmail.com> wrote:
> Great tips! Thanks.
>
> I've made changes 1 and 2 as suggested and left the callbacks scoped
> under this.settings (I think I do this so calling those methods sounds
> better in my head - ie: modal.onBeforeClose() clearly refers to modal,
> modal.settings.onBeforeClose() sounds weird - I have a problem... I
> know :)).
>
> I left out the observer altogether to keep it simple and focused. I
> can simply use documentation to let others know how to apply the
> observers.
>
> Thank you very much for your input.
>
> Luis
>
> On Jun 4, 8:54 pm, Andrew Dupont <goo...@andrewdupont.net> wrote:
>
>
>
> > On Jun 4, 2009, at 8:36 PM, Luisgo wrote:
>
> > > 1. Is there a better way to handle callback definition? See lines
> > > 7-11.
>
> > You've got the right idea here. I'd use `Prototype.emptyFunction`
> > instead because there's no reason to define more than one empty
> > function, but this is of negligible importance.
>
> > > 2. Is there a better way of referring to "body"? See line 33.
>
> > `$(document.body)` would be more concise. Works in all browsers I'm
> > aware of.
>
> > > 3. Is there a better way of "injecting" callbacks into functions so I
> > > don't have to clutter methods like "on" and "off"? See lines 81, 91,
> > > 98, 108.
>
> > You seem reluctant to keep them on the `settings` object — why? Only
> > difference is that you'd call `this.settings.onBeforeOpen()` instead.
> > Scope would be preserved.
>
> > A _different_ approach to callbacks would be to use custom events — to
> > fire "modal:opened:before" and "modal:opened:after" (etc.) — but there
> > are pros and cons for each.
>
> > > 4. Is there a way to use prototype classes that take an element as
> > > extensions to such element? Meaning, I would like to be able apply a
> > > "click" observer to the instance of the class directly. Something
> > > like:
>
> > > `modal.observe("click", someHandler)`
>
> > > and have that passed to the element to which the class is applied to.
> > > In the class: `this.element` or in this example `modal.element`
>
> > No, but if you wanted that sort of thing, you could write your own
> > `observe` method which passed all its arguments to
> > `modal.element.observe`.
>
> > Cheers,
> > Andrew
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---
