Google Groups Home
Help | Sign in
Introducing at() for sub-nodes lookup
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  8 messages - Collapse all
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
Yurii Rashkovskii  
View profile
 More options Jul 6 2007, 9:47 am
From: Yurii Rashkovskii <yra...@gmail.com>
Date: Fri, 6 Jul 2007 15:47:26 +0200
Local: Fri, Jul 6 2007 9:47 am
Subject: Introducing at() for sub-nodes lookup
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.


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
tomPorter  
View profile
 More options Jul 6 2007, 1:55 pm
From: tomPorter <Tom.X.Por...@gmail.com>
Date: Fri, 06 Jul 2007 10:55:07 -0700
Local: Fri, Jul 6 2007 1:55 pm
Subject: Re: Introducing at() for sub-nodes lookup
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:


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Yurii Rashkovskii  
View profile
 More options Jul 6 2007, 1:57 pm
From: Yurii Rashkovskii <yra...@gmail.com>
Date: Fri, 6 Jul 2007 19:57:00 +0200
Subject: Re: [Lilu] Re: Introducing at() for sub-nodes lookup
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


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Thomas Porter  
View profile
 More options Jul 6 2007, 2:13 pm
From: "Thomas Porter" <tom.x.por...@gmail.com>
Date: Fri, 6 Jul 2007 14:13:21 -0400
Local: Fri, Jul 6 2007 2:13 pm
Subject: Re: [Lilu] Re: Introducing at() for sub-nodes lookup
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.

On 7/6/07, Yurii Rashkovskii <yra...@gmail.com> wrote:


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Yurii Rashkovskii  
View profile
 More options Jul 6 2007, 2:18 pm
From: Yurii Rashkovskii <yra...@gmail.com>
Date: Fri, 6 Jul 2007 20:18:43 +0200
Local: Fri, Jul 6 2007 2:18 pm
Subject: Re: [Lilu] Re: Introducing at() for sub-nodes lookup
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.


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Gregor Schmidt  
View profile
 More options Jul 6 2007, 2:34 pm
From: "Gregor Schmidt" <schmidtwis...@gmail.com>
Date: Fri, 6 Jul 2007 20:34:54 +0200
Local: Fri, Jul 6 2007 2:34 pm
Subject: Re: [Lilu] Re: Introducing at() for sub-nodes lookup
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


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
yrashk@gmail.com  
View profile
 More options Jul 6 2007, 2:45 pm
From: "yra...@gmail.com" <yra...@gmail.com>
Date: Fri, 06 Jul 2007 11:45:32 -0700
Local: Fri, Jul 6 2007 2:45 pm
Subject: Re: Introducing at() for sub-nodes lookup
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.


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
yrashk@gmail.com  
View profile
 More options Jul 6 2007, 5:32 pm
From: "yra...@gmail.com" <yra...@gmail.com>
Date: Fri, 06 Jul 2007 14:32:54 -0700
Local: Fri, Jul 6 2007 5:32 pm
Subject: Re: Introducing at() for sub-nodes lookup
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


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2008 Google