Introducing at() for sub-nodes lookup

[Yurii Rashkovskii]

Hello,

I'm about to make a following change to Lilu soon:

Deprecate current String => value meaning in update/replace.
Currently it means that Lilu will lookup for a sub-node with path
(String), and if you will use Symbol, it will lookup for an
attribute. I don't find it very obvious or convenient. My idea is to
replace node lookup with at(path) syntax. I.e. if you had:

update('#blog-entry').with :id => "blog-#{@blog.id}", 'a' =>
{ :href => @blog.url }

you will need to rewrite it to something like

update('#blog-entry').with :id => "blog-#{@blog.id}", at('a') =>
{ :href => @blog.url }
or
update('#blog-entry').with 'id' => "blog-#{@blog.id}", at('a')
=> { 'href' => @blog.url }

I'm about to commit this backward incompatible change shortly.

What do you think about it?

Thank you,
Yurii.

[tomPorter]

Hello Yurii,

First off, Thanks for lilu, I really like the approach a lot.

Now I have to think a bit more, since I just figured out how things
work in the current version.

I like keeping all attributes as symbols, as your first example shows.

Tom P.

On Jul 6, 9:47 am, Yurii Rashkovskii <yra...@gmail.com> wrote:
> Hello,
>
> I'm about to make a following change to Lilu soon:
>
> Deprecate current String => value meaning in update/replace.
> Currently it means that Lilu will lookup for a sub-node with path
> (String), and if you will use Symbol, it will lookup for an
> attribute. I don't find it very obvious or convenient. My idea is to
> replace node lookup with at(path) syntax. I.e. if you had:
>

> update('#blog-entry').with :id => "blog...@blog.id}", 'a' =>

> { :href => @blog.url }
>
> you will need to rewrite it to something like
>

> update('#blog-entry').with :id => "blog...@blog.id}", at('a') =>
> { :href => @blog.url }
> or
> update('#blog-entry').with 'id' => "blog...@blog.id}", at('a')

[Yurii Rashkovskii]

Hey Tom,

On Jul 6, 2007, at 7:55 PM, tomPorter wrote:

>
> Hello Yurii,
>
> First off, Thanks for lilu, I really like the approach a lot.
>
> Now I have to think a bit more, since I just figured out how things
> work in the current version.
>
> I like keeping all attributes as symbols, as your first example shows.
>

With this change (which is still not commited to trunk), you will
still be able to use symbols for attributes, though for sub-nodes,
you will need to use at(path) instead of strings with path. So the
question was that whether most of us find it better?

Yurii

[Thomas Porter]

I guess I like the current "String" = element as it means less typing,
particularly when using #populate where the hash of hashes after
mapping can contain element specifications as in your #populate
example from your presentation to the Oslo group.

Would this

populate('#blog-entry').for(:each, @user.blog_entries) do |e|
mapping 'a' => {:href => e.url, self => e.title}, :id => "blog-entry-#{e.id}"
end

change to

populate('#blog-entry').for(:each, @user.blog_entries) do |e|
mapping at('a') => {:href => e.url, self => e.title}, :id =>
"blog-entry-#{e.id}"
end

Or am I misunderstanding how elements would be identified when in the
mapping portion of a #populate or #update(:all,..)

Tom P.

[Yurii Rashkovskii]

Thomas,

On Jul 6, 2007, at 8:13 PM, Thomas Porter wrote:

>
> I guess I like the current "String" = element as it means less typing,
> particularly when using #populate where the hash of hashes after
> mapping can contain element specifications as in your #populate
> example from your presentation to the Oslo group.

Yes, "String" is shorter, but is it obvious? I find that it could be
quite confusing (Symbol/String meaning difference).

>
> Would this
>
> populate('#blog-entry').for(:each, @user.blog_entries) do |e|
> mapping 'a' => {:href => e.url, self => e.title}, :id => "blog-
> entry-#{e.id}"
> end
>
> change to
>
> populate('#blog-entry').for(:each, @user.blog_entries) do |e|
> mapping at('a') => {:href => e.url, self => e.title}, :id =>
> "blog-entry-#{e.id}"
> end

Yes, exactly. 'a' becomes at('a').

May be it will be reasonable to leave both syntaxes? I.e. leave
Symbol for attributes, String for sub-nodes and at() for sub-nodes as
well to see how this transition will work?

My point is that I want to make most of backward incompatible changes
as soon as possible. Late syntax changes really suck :)

Yurii.

[Gregor Schmidt]

Hi all,

thanks for lilu. It is a great libary, although I'm using it not for
temlating, but to manipulate HTML chunks, it fits perfectly my needs.

Concerning your desired changes: I think it is way easier to read the
new syntax. Nobody would guess in the first place, that Symbols and
Strings have these very different sematics, especially, when you are
coming from Rails, where the framework often handles symbol and string
keys equally.

I would prefer the new syntax, although it is a bit longer.

It would interesting to know, that the actual return value of

at("a")

would be. And will

at(:a)

work as well?

Cheers and thanks for asking,

Gregor

[yra...@gmail.com]

Gregor,

> thanks for lilu. It is a great libary, although I'm using it not for
> temlating, but to manipulate HTML chunks, it fits perfectly my needs.

Nice to hear!

> Concerning your desired changes: I think it is way easier to read the
> new syntax. Nobody would guess in the first place, that Symbols and
> Strings have these very different sematics, especially, when you are
> coming from Rails, where the framework often handles symbol and string
> keys equally.

Yes, that was my point.

>
> I would prefer the new syntax, although it is a bit longer.
>
> It would interesting to know, that the actual return value of
>
> at("a")
>
> would be.

It will return a helper class ElementAt instance, which will be
handled by update.with and friends.

> And will
>
> at(:a)
>
> work as well?

Oh yes, since Hpricot supports it :)

> Cheers and thanks for asking,

You welcome!

Yurii.

[yra...@gmail.com]

I've commited initial implementation to a branch:

http://trac.railsware.com/lilu/browser/lilu/branches/ticket-14

Subversion: svn://dev.railsware.com/lilu/lilu/branches/ticket-14