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:
> 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:
> 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?
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:
> > 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?
> 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).
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 :)
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
> 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.