When using traditional templating solutions it's common that you'll see something like the following:
{% for x in coll %} <h>{{ x.heading }}</h> <p>{{ x.content }}</p> {% endfor %]
Note that there is no containing element for the <h> and <p> elements. How would one loop over something like this using Enlive snippets + templates? If there was a container element it would be simple, but without it I don't see anything obvious. Is there a way to support this case easily?
On Sun, Jan 31, 2010 at 8:48 PM, David Nolen <dnolen.li...@gmail.com> wrote: > When using traditional templating solutions it's common that you'll > see something like the following:
> {% for x in coll %} > <h>{{ x.heading }}</h> > <p>{{ x.content }}</p> > {% endfor %]
> Note that there is no containing element for the <h> and <p> elements. > How would one loop over something like this using Enlive snippets + > templates? If there was a container element it would be simple, but > without it I don't see anything obvious. Is there a way to support > this case easily?
> Thanks, > David
> -- > You received this message because you are subscribed to the Google Groups "Enlive" group. > To post to this group, send email to enlive-clj@googlegroups.com. > To unsubscribe from this group, send email to enlive-clj+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/enlive-clj?hl=en.
> Here you can see that I only ever reference the <option> element, but > obviously it could be any standalone node.
> Rob
> On Sun, Jan 31, 2010 at 8:48 PM, David Nolen > <dnolen.li...@gmail.com> wrote: >> When using traditional templating solutions it's common that you'll >> see something like the following:
>> {% for x in coll %} >> <h>{{ x.heading }}</h> >> <p>{{ x.content }}</p> >> {% endfor %]
>> Note that there is no containing element for the <h> and <p> >> elements. >> How would one loop over something like this using Enlive snippets + >> templates? If there was a container element it would be simple, but >> without it I don't see anything obvious. Is there a way to support >> this case easily?
>> Thanks, >> David
>> -- >> You received this message because you are subscribed to the Google >> Groups "Enlive" group. >> To post to this group, send email to enlive-clj@googlegroups.com. >> To unsubscribe from this group, send email to enlive-clj+unsubscribe@googlegroups.com >> . >> For more options, visit this group at http://groups.google.com/group/enlive-clj?hl=en >> .
> -- > You received this message because you are subscribed to the Google > Groups "Enlive" group. > To post to this group, send email to enlive-clj@googlegroups.com. > To unsubscribe from this group, send email to enlive-clj+unsubscribe@googlegroups.com > . > For more options, visit this group at http://groups.google.com/group/enlive-clj?hl=en > .
On Sun, Jan 31, 2010 at 8:48 PM, David Nolen <dnolen.li...@gmail.com> wrote: > When using traditional templating solutions it's common that you'll > see something like the following:
> {% for x in coll %} > <h>{{ x.heading }}</h> > <p>{{ x.content }}</p> > {% endfor %]
> Note that there is no containing element for the <h> and <p> elements.
Indeed there's no facility to transform a group of adjacent nodes without a container. Off the top of my head:
> How would one loop over something like this using Enlive snippets + > templates? If there was a container element it would be simple, but > without it I don't see anything obvious. Is there a way to support > this case easily?
If there was a container element, one could also clone it and then strip it from the result to leave only the repeated inner nodes.
In order to support (just musing not promising anything) such cases, how would one define a group of adjacent nodes?
I like this because preserve the idea of the selector/fn pair. If both selectors aren't matched we just fail and move on to the next selector/ fn pair.
On Tue, Feb 2, 2010 at 3:47 AM, David Nolen <dnolen.li...@gmail.com> wrote: > My issue with this is that we are now offloading the problem onto the > person that is writing the markup. Ideally Enlive can just support > common cases.
I agree.
> But I was thinking it would be nice to combine this with my "model" > idea from the earlier mailing list post:
An extent (if antyone has a better name please chime in) being all the nodes between two siblings, the leftmost being selected by the first selector, the rightmost being selected by the second selector.
What do you think?
> I like this because preserve the idea of the selector/fn pair. If both > selectors aren't matched we just fail and move on to the next selector/ > fn pair.
What I propose is to have an new class of selectors which don't select a single node but several *adjacent* nodes (including whitespaces and comments) at once. The fn would, in this case, take a seq of nodes.
> An extent (if antyone has a better name please chime in) being all the > nodes between two siblings, the leftmost being selected by the first > selector, the rightmost being selected by the second selector.
> An extent (if antyone has a better name please chime in) being all the > nodes between two siblings, the leftmost being selected by the first > selector, the rightmost being selected by the second selector.
> What do you think?
Regarding terminology, I'd call it a 'slice', which I think fits in with the slice operation that many people are familiar with in python, etc.
However...
On Tue, Feb 2, 2010 at 3:47 AM, David Nolen <dnolen.li...@gmail.com> wrote:
> My issue with this is that we are now offloading the problem onto the > person that is writing the markup. Ideally Enlive can just support > common cases.
Just out of curiosity, is this really a common case? In my (admittedly limited) experience, if one is looking to emit repeated sequences of elements as described, then the CSS is going to almost certainly need some container around each such sequence anyway. Is this less universal than I suspect?
On Wed, Feb 3, 2010 at 6:54 AM, Chas Emerick <cemer...@snowtide.com> wrote: > Regarding terminology, I'd call it a 'slice', which I think fits in with > the slice operation that many people are familiar with in python, etc.
'extent' and 'slice' are both cool with me.
> However...
> Just out of curiosity, is this really a common case? In my (admittedly > limited) experience, if one is looking to emit repeated sequences of > elements as described, then the CSS is going to almost certainly need some > container around each such sequence anyway. Is this less universal than I > suspect?
You don't need a container to style repeating elements with CSS. I've seen this pattern a lot in PHP as well as in Django templates. I've been handed markup that looks this from designers as well. Many JavaScript accordions expect this pattern.
> Just out of curiosity, is this really a common case? In my > (admittedly limited) experience, if one is looking to emit repeated > sequences of elements as described, then the CSS is going to almost > certainly need some container around each such sequence anyway. Is > this less universal than I suspect?
> You don't need a container to style repeating elements with CSS. > I've seen this pattern a lot in PHP as well as in Django templates. > I've been handed markup that looks this from designers as well. Many > JavaScript accordions expect this pattern.
What about {[:h1] [:p]} to denote the extent/slice selector?
In this html snippet: <div><h1>title</h1><p>p1</p><p>p2</p></div> do you think that {[:h1] [:p]} should select: * <h1>title</h1><p>p1</p> * <h1>title</h1><p>p1</p><p>p2</p> * both
Right now my vote is on the first choice as it seems the least surprising.
On Wed, Feb 3, 2010 at 7:05 PM, Chas Emerick <cemer...@snowtide.com> wrote:
> On Feb 3, 2010, at 11:18 AM, David Nolen wrote:
>> Just out of curiosity, is this really a common case? In my (admittedly >> limited) experience, if one is looking to emit repeated sequences of >> elements as described, then the CSS is going to almost certainly need some >> container around each such sequence anyway. Is this less universal than I >> suspect?
> You don't need a container to style repeating elements with CSS. I've seen > this pattern a lot in PHP as well as in Django templates. I've been handed > markup that looks this from designers as well. Many JavaScript accordions > expect this pattern. > http://docs.jquery.com/UI/Accordion
> Thanks very much for the clarification and reference. > - Chas
> -- > You received this message because you are subscribed to the Google Groups > "Enlive" group. > To post to this group, send email to enlive-clj@googlegroups.com. > To unsubscribe from this group, send email to > enlive-clj+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/enlive-clj?hl=en.
On Thu, Feb 4, 2010 at 2:21 PM, Christophe Grand <christo...@cgrand.net>wrote:
> What about {[:h1] [:p]} to denote the extent/slice selector?
> In this html snippet: <div><h1>title</h1><p>p1</p><p>p2</p></div> do > you think that {[:h1] [:p]} should select: > * <h1>title</h1><p>p1</p> > * <h1>title</h1><p>p1</p><p>p2</p> > * both
> Right now my vote is on the first choice as it seems the least surprising.
What about a greedy option?
{[:h1] [:p]} defaults to not greedy
{[:h1] [:p] :greedy true}
Or something more elegant to describe the greedy option?
On Thu, Feb 4, 2010 at 8:42 PM, David Nolen <dnolen.li...@gmail.com> wrote: > On Thu, Feb 4, 2010 at 2:21 PM, Christophe Grand <christo...@cgrand.net> > wrote:
>> What about {[:h1] [:p]} to denote the extent/slice selector?
>> In this html snippet: <div><h1>title</h1><p>p1</p><p>p2</p></div> do >> you think that {[:h1] [:p]} should select: >> * <h1>title</h1><p>p1</p> >> * <h1>title</h1><p>p1</p><p>p2</p> >> * both
>> Right now my vote is on the first choice as it seems the least surprising.
> What about a greedy option? > {[:h1] [:p]} defaults to not greedy > {[:h1] [:p] :greedy true} > Or something more elegant to describe the greedy option?
It's a possibility but I'd like to pick a single option for the moment and see if the need for the other arises. Note that {[:h1] [:p] :greedy true} can be written {[:h1] [[last-of-type :p]]}
So, do you have a strong opinion on which option to choose?
On Thu, Feb 4, 2010 at 3:33 PM, Christophe Grand <christo...@cgrand.net>wrote:
> It's a possibility but I'd like to pick a single option for the moment > and see if the need for the other arises. > Note that {[:h1] [:p] :greedy true} can be written {[:h1] [[last-of-type > :p]]}
Great, works for me.
> So, do you have a strong opinion on which option to choose?
On Thu, Feb 4, 2010 at 9:42 PM, David Nolen <dnolen.li...@gmail.com> wrote: > On Thu, Feb 4, 2010 at 3:33 PM, Christophe Grand <christo...@cgrand.net> > wrote:
>> It's a possibility but I'd like to pick a single option for the moment >> and see if the need for the other arises. >> Note that {[:h1] [:p] :greedy true} can be written {[:h1] [[last-of-type >> :p]]}
> Great, works for me.
>> So, do you have a strong opinion on which option to choose?
