> Other DOM builders out there are script.aculo.us' [2], which is IMO
> too big for core (what are those hacks for, anyway?);
Mostly for browser bugs, many of which may have been fixed in newer
browser versions. FF and IE both had very strange (and different)
issues, iirc. See the unit tests for builder.js for more on this.
Anyway, I'm not sure if we need a DOM Builder in Prototype core, though.
I find myself using it for only a very few special occasions, as IMHO
HTML is something the server should provide (as web dev frameworks
should be good at generating HTML), and that's also one of the
central things around Rails RJS templates.
YMMV, but that approach allows for having to write less JavaScript. :)
Best,
Thomas
I personally use Builder.node quite a bit and find it very
convenient. I like the lightweight-ness of your solution but by the
time you add in the special cases it will have grown quite a bit I
think.
$E({
div: {
table: { attributes: {id: style: className: },
tr: {
}
}
}
})
Anyway, yeah, I like the idea but would like to see something that is
syntactically prettier. I don't know what that would look like
exactly, but perhaps some data structure to replace the nested
function calls?
Could you explain your "calls functions" feature?
Thanks,
Colin
First we add Element.writeAttributes (or whatever it should be named
but since we already have readAttribute I thought this name should
match) to let chaining works when settings an element's attribute(s):
Element.addMethods({
// ...
writeAttributes: function(element, properties) {
element = $(element);
for (var property in properties)
element[property] = properties[property];
return element;
},
// ...
});
Then replace the current:
var Element = new Object();
with something like:
function Element(tagName, options) {
return Element.extend(document.createElement(tagName)).writeAttributes(options
|| {});
}
This way it would be really easy to create new elements when you don't
need the full functionallity from Builder with all it's fixes and
tweaks:
var myHeader = new Element('div', {id: 'header'});
$('container').appendChild(myHeader);
What do you think? I would happily provide a patch with tests if you
like this approach.
Btw, is there any way to view Sam's proposition for us without account
on the rails basecamp site?
Martin
Martin, I like your implementation a lot (especially the
Element.writeAttributes idea, which I think should be added no matter
what) but it's missing two things I like most about Dan Webb's
DOMBuilder:
* Tags as method names. Much easier to do x.DIV(foo, bar) than to do
new Element("div", foo, bar).
* Easy nesting (like "x.DIV( x.P ( x.SPAN() ) )"). DOMBuilder
responds differently based on the number and types of arguments
passed.
I think both these things are critical, or else there's little
advantage over the native DOM methods. Others may feel differently,
though.
Martin, keep in mind that Element.writeAttributes will need to make
the same accommodations for IE as Element.readAttribute. Tobie and I
know all too much about this, so let us know if you want help.
Cheers,
Andrew
On Feb 6, 4:56 pm, "Mislav Marohnić" <mislav.maroh...@gmail.com>
wrote:
I'll submit a patch asap!
Ciao
martin
-Justin
On Feb 6, 11:18 am, "Martin Ström" <martinstromli...@gmail.com> wrote:
> Exacly my point. This shouldn't be seen as a replacement for a more
> robust solution like the one earlier in this thread or the existing
> Builder but more of a document.createElement-wrapper.
>
> I'll submit a patch asap!
>
> Ciao
> martin
>
Yup, +1. I like the weightlessness of it. We'll have to stress that it
plays a lighter game than script.aculo.us' Builder though, so people
don't think one replaces the other entirely.
--
Christophe Porteneuve a.k.a. TDD
"[They] did not know it was impossible, so they did it." --Mark Twain
Email: t...@tddsworld.com
Sorry for joining this discussion really late but after fielding all
the bug reports for DOMBuilder (and using it heavily myself) it has to
be said that this solution definitely isn't going to cut it. In fact
I think adding it in is going to be destructive.
The thing is is that there's loads of cross browser problems with
setting attributes (as mentioned previously) and working around at
least the common problems with a tool like this is essential otherwise
your just going to end up sending developers on huge bug hunts almost
every time they use it which is no help to anyone really. For
instance, really common attributes like class, for, style, name etc
all work unpredicable across browsers so if people try to use this
they'll very quickly realise that its problematic and end up dropping
it so the end result is that you've just given the developer the run
around. Im not saying a solution like this needs to be cover every
single little bug but it should cover the common ones.
Besides that, in terms of syntaxic sugar Martin's solution, although
very compact in implementation, doesn't buy the developer much and
since a DOM builder is all about facilitating building none trivial
DOM structures with readable code it seems a little redundant. new
Element('div', ....) then creating all the childNodes and appending
each is just not much better than document.createElement().
It's not been mentioned yet but theres a slightly updated version of
my DOM Builder in Low Pro and instead of using the apply stuff it
creates the functions with a $ prefixed which I thought was more
Prototypish. $span, $div etc. It also does fix the most common bugs
(but not as much as the scriptaculous version which is very thorough)
and is pretty small. Predictably, my vote would go for my version :)
http://svn.danwebb.net/external/lowpro/trunk/src/dom.js
On the point of whether its worth including a DOM builder at all I'm
not sure. I use it heavily as do many scripters who code
unobtrusively. The common use case is that the flat page HTML should
not include any markup that is used to scaffold javascript operations
so that if its an old/firewalled/mobile/fucked up browser then the
page isn't filled with loader graphics (which is my pet hate :) and
random elements which often render the UI unusable. If the script
runs correctly then a DOM builder can be used to add in any extra
markup needed for the script to work.
At the moment Prototype isn't strong on supporting unobtrusive code
and although, obviously, I'd like to see it do so I'm also fine with
the fact that it's coded with another opinion in mind and maybe
pulling it in both directions is just going to bloat it.
On Feb 20, 4:10 am, "Dan Webb" <danwr...@gmail.com> wrote:
> The thing is is that there's loads of cross browser problems with
> setting attributes (as mentioned previously) and working around at
> least the common problems with a tool like this is essential otherwise
> your just going to end up sending developers on huge bug hunts almost
> every time they use it which is no help to anyone really. For
> instance, really common attributes like class, for, style, name etc
> all work unpredicable across browsers so if people try to use this
> they'll very quickly realise that its problematic and end up dropping
> it so the end result is that you've just given the developer the run
> around. Im not saying a solution like this needs to be cover every
> single little bug but it should cover the common ones.
The groundwork for managing these special cases has already been laid
with the work Tobie and I did on Element.readAttribute. "Class" and
"for" are easily translated into their necessary "className" and
"htmlFor" in IE. "Name" can be set in the document.createElement call
the way DOMBuilder does. And I think "style" is an edge case that
doesn't really concern me too much.
I'm sure there will be other speed bumps, but I don't think the
tyranny of the edge case is enough to hold this idea down.
> Besides that, in terms of syntaxic sugar Martin's solution, although
> very compact in implementation, doesn't buy the developer much and
> since a DOM builder is all about facilitating building none trivial
> DOM structures with readable code it seems a little redundant. new
> Element('div', ....) then creating all the childNodes and appending
> each is just not much better than document.createElement().
This is a point I raised earlier in the thread, but later withdrew.
Martin's solution is not intended to be a replacement of something
like DOMBuilder, but rather an intermediate step toward it.
> It's not been mentioned yet but theres a slightly updated version of
> my DOM Builder in Low Pro and instead of using the apply stuff it
> creates the functions with a $ prefixed which I thought was more
> Prototypish. $span, $div etc. It also does fix the most common bugs
> (but not as much as the scriptaculous version which is very thorough)
> and is pretty small. Predictably, my vote would go for my version :)
>
> http://svn.danwebb.net/external/lowpro/trunk/src/dom.js
I'm conflicted about this. I realize that DOM building convenience
methods are only convenient when the names are short, but at the same
time I worry about dropping into the $ namespace the namess of all
elements used in HTML4.
>> It's not been mentioned yet but theres a slightly updated version of
>> my DOM Builder in Low Pro and instead of using the apply stuff it
>> creates the functions with a $ prefixed which I thought was more
>> Prototypish. $span, $div etc. It also does fix the most common bugs
>> (but not as much as the scriptaculous version which is very thorough)
>> and is pretty small. Predictably, my vote would go for my version :)
>>
>> http://svn.danwebb.net/external/lowpro/trunk/src/dom.js
>
> I'm conflicted about this. I realize that DOM building convenience
> methods are only convenient when the names are short, but at the same
> time I worry about dropping into the $ namespace the namess of all
> elements used in HTML4.
Note that the script.aculo.us DOM builder has this as an option, you
can choose to have the shortcuts, either globally or added to an
object of your choice.
See http://dev.rubyonrails.org/browser/spinoffs/scriptaculous/test/
unit/builder_test.html#L191 ff
The Builder.dump() call creates the TAGNAME() shortcuts.
best,
thomas
My patch right now will allow one to set the boolean attributes (e.g.
checked, disabled, readonly & multiple) using the 'true' keyword since
that seems to make most sense:
element.writeAttributes({readonly: true});
in opposite of setting it to the attribute name:
element.writeAttributes({readonly: 'readonly'});
which is the way you would do it in (x)html:
<input type="test" readonly="readonly">
Do you think it should work like the first one or isn't it necessary
to respect these kind of things?
The same when setting false values. #writeAttributes will not use
#setAttribute if the value is an empty string or 'false' for booleans
attributes. Instead it will use #removeAttribute and therefore make
#readAttribute return null which I believe is how you would expect it
to work:
element.writeAttributes({readonly: false}).readAttribute('readonly')
=> null // boolean attributes
element.writeAttributes({src: ''}).readAttribute('src') => '' //
normal attributes
What do you think?
Btw, great work with the 1.5.1 release, the new Selector (and the
other stuff as well of course) is really awesome. Thanks!
Martin
What do you think?
If i missed any of the attribute fixes for IE or any other issue, feel
free to correct me or my patch :)
On 3/14/07, Martin Ström <martinst...@gmail.com> wrote:
> I think I have the patch ready and will submit it asap to trac.
> Actually my tests to create an input element and set it's name
> attribute using #writeAttributes worked fine (both IE6 and IE7) but
> maybe I didn't trigger the bug correctly.
>
> On 3/14/07, Mislav Marohnić <mislav....@gmail.com> wrote:
> > On 3/14/07, Martin Ström <martinst...@gmail.com> wrote:
> > >
> > > What do you think?
> >
> > Seems nice to me. Not everything has to be strict :)
> >
> > The only problem now remains IE and its read-only attributes like "name" ...
> > If only it weren't for that :(
> >
> >
> > > >
> >
>
>
> --
> burnfield.com/martin
>
On 2/5/07, Martin Ström <martinst...@gmail.com> wrote:
>
--
Regards, Kjell
www.m3nt0r.de
FYI: tests and code are now submitted to trac:
http://dev.rubyonrails.org/ticket/7476#comment:2
Some heated debate in perspective!
On Mar 15, 8:42 am, "Mislav Marohnić" <mislav.maroh...@gmail.com>
wrote:
I'd favor writeAttribute to be consistant with readAttribute... and
setStyle (which is not pluralized).
On 3/15/07, Tobie Langel <tobie....@gmail.com> wrote:
>
> I'd favor writeAttribute to be consistant with readAttribute... and
> setStyle (which is not pluralized).
>
> Some heated debate in perspective!
>
> On Mar 15, 8:42am, "Mislav Marohnić" <mislav.maroh...@gmail.com>
> wrote:
> > On 3/15/07, Martin Ström <martinstromli...@gmail.com> wrote:
> >
> >
> >
> > > FYI: tests and code are now submitted to trac:
> > >http://dev.rubyonrails.org/ticket/7476#comment:2
> >
> > Nice! This is a very solid foundation for a more featured Builder (IMO).
> >
> > But, I would rename writeAttributes to setAttributes for consistency with
> > setStyle (which also takes a hash).
>
>
> >
>
On Mar 15, 9:39 am, "Tobie Langel" <tobie.lan...@gmail.com> wrote:
> I'd favor writeAttribute to be consistant with readAttribute... and
> setStyle (which is not pluralized).
>
The issue here is that each attribute is a separate unit, whereas you
could argue that each of the properties you pass to setStyle is just
part of the overall "style" of the element.
Anyway, I'm not about to get us on a semantics tangent. But if we
call it writeAttribute, people will expect it to behave like
setAttribute (the way readAttribute behaves like getAttribute). So
let's write it so that you can pass in either two string arguments or
one hash of attributes.
Cheers,
Andrew
The issue here is that each attribute is a separate unit, whereas you
could argue that each of the properties you pass to setStyle is just
part of the overall "style" of the element.
Done! The patch on trac is updated to support both way (parameters or hash).
Ciao
Martin