r:children:if_first r:children:if_last

[Simon Josi]

The tag r:children could provide two more tags that can be used to
determine with which element we are working with in each iteration.

This example implements the functionality with currently available tags:
<ul class="blog_entries">
  <r:find url="/blog">
    <r:children:each limit="1">
      <li class="first"><r:snippet name="blogentry_preview"/></li>
    </r:children:each>
    <r:children:each order="asc" limit="5" offset="1">
      <li><r:snippet name="blogentry_preview"/></li>
    </r:children:each>
    <r:children:each order="asc" limit="1" offset="4">
      <li class="last"><r:snippet name="blogentry_preview"/></li>
    </r:children:each>
  </r:find>
</ul>

I need to assign the class "first" to the first element and the class
"last" to the last element.

It would be nice to make it work like that:
<ul class="blog_entries">
  <r:find url="/newsblog">
    <r:children:each limit="7">
      <li class="<r:snippet name="blogentry_preview_class"/>">
        <r:snippet name="blogentry_preview"/>
      </li>
    </r:children:each>
  </r:find>
</ul>

The snippet blogentry_preview_class would look like this:
<r:children:if_first> first </r:children:if_first>
<r:children:if_last> last </r:children:if_last>

Would anyone else would want to have these tags available?

cheers
/simon
_______________________________________________
Radiant mailing list
Post:   Radiant@...
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

[Jim Gay-2]

I think it should allow a "group" or "size" option.

<r:if_first size="3"> would apply to the first 3. Working with more  
than just one would be useful.

I would want to have these tags with that option:
if_first / unless_first
if_last / unless_last

I'm not sure about the name of the parameter though. Perhaps  
<r:if_first window="3">

On Jun 26, 2008, at 8:27 AM, Simon Josi wrote:

> The tag r:children could provide two more tags that can be used to
> determine with which element we are working with in each iteration.
>
> This example implements the functionality with currently available  
> tags:
> <ul class="blog_entries">
>  <r:find url="/blog">
>    <r:children:each limit="1">
>      <li class="first"><r:snippet name="blogentry_preview"/></li>
>    </r:children:each>
>    <r:children:each order="asc" limit="5" offset="1">
>      <li><r:snippet name="blogentry_preview"/></li>
>    </r:children:each>
>    <r:children:each order="asc" limit="1" offset="4">
>      <li class="last"><r:snippet name="blogentry_preview"/></li>
>    </r:children:each>
>  </r:find>
> </ul>
>
> I need to assign the class "first" to the first element and the class
> "last" to the last element.
>
> It would be nice to make it work like that:
> <ul class="blog_entries">
>  <r:find url="/newsblog">
>    <r:children:each limit="7">
>      <li class="<r:snippet name="blogentry_preview_class"/>">
>        <r:snippet name="blogentry_preview"/>
>      </li>
>    </r:children:each>
>  </r:find>
> </ul>
>
> The snippet blogentry_preview_class would look like this:
> <r:children:if_first> first </r:children:if_first>
> <r:children:if_last> last </r:children:if_last>
>
> Would anyone else would want to have these tags available?
>
> cheers
> /simon
> _______________________________________________
> Radiant mailing list
> Post:   Radiant@...
> Search: http://radiantcms.org/mailing-list/search/
> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

_______________________________________________
Radiant mailing list
Post:   Radiant@...
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

[John W. Long-3]

On Jun 26, 2008, at 8:36 AM, Jim Gay wrote:

> I think it should allow a "group" or "size" option.
>
> <r:if_first size="3"> would apply to the first 3. Working with more  
> than just one would be useful.
>
> I would want to have these tags with that option:
> if_first / unless_first
> if_last / unless_last
>
> I'm not sure about the name of the parameter though. Perhaps  
> <r:if_first window="3">

How about:

<r:if_index in="1,2,3">    # if it's one of the first 3 children
<r:if_index in="-1,-2,-3"> # if it's one of the last 3 children
<r:if_index is="1">        # equivalent to <r:if_first />
<r:if_index is="-1">       # equivalent to <r:if_last />
<r:if_index is="even">     # if it's an even row
<r:if_index is="odd">      # if index is an odd row

Seems like a 1 based index would be most helpful here.

--
John Long
http://wiseheartdesign.com
_______________________________________________
Radiant mailing list
Post:   Radiant@...
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

[Chris Parrish-6]

All this discussion of yet more "<r:if_x>" tags and another recent
thread with the desire to pass values to snippets has me thinking of
digging up my old conditional/variables extension.  I'm sure it needs
revamped for the current versions of Radiant and I'd like to clean up
the syntax some but, mostly, I'd like to know if folks out there would
find it useful...

Here's what I'm thinking.  Please let me know if it'd be helpful to you,
if you have any suggestions, and if you'd be interested in contributing:

   1. General conditional statements.  For instance, instead of solving
      this post's problem by creating a new tag (more tags for our users
      to learn), with a syntax different than the other <r:if_x> (also
      complicating things for them), we'd simply have a single <r:if>
      tag so you could write: <r:if cond="children.index = 1">.

      The <r:if> tag already knows how to parse the cond attribute, and
      how to evaluate the condition (true, false, greater than, string
      compare, regexp matching, etc) so you don't have to rewrite the
      logic every time.  To solve this problem, all that would be needed
      is to tell it how to evaluate "children.index" (or some such
      notation).  Currently I have implemented:
          * page.url
          * page.title
          * page.slug
          * page.breadcrumb
          * page.children.count
          * page.part[part_name]
          * vars[my_variable_name] (more on this in point #2)

   2. Ways to get/set basic variables.  For this one I had created a
      <r:store /> tag that could be used like:
          <r:store vars="my_var1: 'some string text'; my_var2: 100;
      my_var3: false />
          <r:puts value_for="vars[my_var1]" />   -->  "some string text"

      You could also use puts with the above like...
          <r:puts value_for="page.children.count" />  (not sure how
      useful this is...)

      Where it got nice though is using it with the conditionals like:
        ---- in page ----
          <r:store vars="linkText: 'Some example link text'; url:
      my/target/url;
              class: myClass" />
          <r:snippet name="link" />

        ---- in snippet ----
          <a href="<r:puts value_for="vars[url]" />"
          <r:if cond="vars[class]"> class="<r:puts
      value_for="vars[class]" />"</r:if>>
            <r:puts value_for="vars[linkText]" />
          </a>

      I had also implemented a modified <r:snippet> tag to make the
      first part easier so you could just do:
        ---- in page ----
          <r:snippet name="link" vars="linkText: 'Some example link
      text'; url: my/target/url;
            class: myClass" />

Ok, so that's a long explanation.  I'm happy to resurrect the extension,
but the big question is would this (or something similar) be useful?

Let me know...

-Chris



John W. Long wrote:

> On Jun 26, 2008, at 8:36 AM, Jim Gay wrote:
>> I think it should allow a "group" or "size" option.
>>
>> <r:if_first size="3"> would apply to the first 3. Working with more
>> than just one would be useful.
>>
>> I would want to have these tags with that option:
>> if_first / unless_first
>> if_last / unless_last
>>
>> I'm not sure about the name of the parameter though. Perhaps
>> <r:if_first window="3">
>
> How about:
>
> <r:if_index in="1,2,3">    # if it's one of the first 3 children
> <r:if_index in="-1,-2,-3"> # if it's one of the last 3 children
> <r:if_index is="1">        # equivalent to <r:if_first />
> <r:if_index is="-1">       # equivalent to <r:if_last />
> <r:if_index is="even">     # if it's an even row
> <r:if_index is="odd">      # if index is an odd row
>
> Seems like a 1 based index would be most helpful here.
>
> --
> John Long
> http://wiseheartdesign.com
> _______________________________________________
> Radiant mailing list
> Post:   Radiant@...
> Search: http://radiantcms.org/mailing-list/search/
> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

_______________________________________________
Radiant mailing list
Post:   Radiant@...
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

[Jim Gay-2]

I agree that the list of if_this unless_that can get very long, but  
there is a benefit in that the intentions of the code are clear.
I remember seeing emails about your extension and being very  
interested in the past, Chris, but I didn't have time to take a look  
at it.

I agree with the principle that a single r:if would make life simpler,  
but my gut reaction is that it starts looking less natural. But maybe  
I'd feel better with some nomenclature changes.

Please resurrect it. I've got some questions that might just be  
cleared by using it. But here are my comments from 10,000 feet:

Something just bugs me when I see shortcuts such as the attribute  
"cond" when I feel like "condition" would be clearer. I think that in  
a system like Radiant, which seems to have some good coverage with non-
technical users, clear intentions are important.

I would scope the variables stuff more explicitly, such as
<r:variables:store> and <r:variables:output>
Because, although I haven't done it yet, I think a simple ecommerce  
web store would be a nice extension and <r:store> would make sense  
there.

You mentioned using <r:if cond="children.index = 1"> but should that  
have a double equal (==)?
Does it allow the use of RegExp matching with =~ ?
Does the extension provide a way to easily describe how to parse  
things like "children.index" or "this.that" ?
Does it have the equivalent unless tag?

I disagree with John's suggestion too. <r:if_index in="-1,-2,-3">  
makes me think, "huh?"

Just this evening I was walking a client through parts of their  
Radiant site. I always say something to the effect of "you can always  
contact us when things need to be changed, but this is how its done..."
Some people speak up and say "Ok, forget it, I don't need to see that"  
while others pay attention.
When I walked through a few examples we have with <r:if_content  
part="part_name"> the client said, "Oh, cool". The intentions of that  
code are very clear and I have little fear (depending on the user)  
that someone can screw that up.

That's not to say that everything should be dumbed down, but to me  
something like <r:if_first group_of="10"> is very friendly. So a DRYer  
<r:if> would be nice, but I think a friendly dialect (for lack of a  
better term) is very important.

-Jim


On Jun 26, 2008, at 10:58 AM, Chris Parrish wrote:

> All this discussion of yet more "<r:if_x>" tags and another recent  
> thread with the desire to pass values to snippets has me thinking of  
> digging up my old conditional/variables extension.  I'm sure it  
> needs revamped for the current versions of Radiant and I'd like to  
> clean up the syntax some but, mostly, I'd like to know if folks out  
> there would find it useful...
>
> Here's what I'm thinking.  Please let me know if it'd be helpful to  
> you, if you have any suggestions, and if you'd be interested in  
> contributing:
>
>  1. General conditional statements.  For instance, instead of solving
>     this post's problem by creating a new tag (more tags for our users
>     to learn), with a syntax different than the other <r:if_x> (also
>     complicating things for them), we'd simply have a single <r:if>
>     tag so you could write: <r:if cond="children.index = 1">.
>
>     The <r:if> tag already knows how to parse the cond attribute, and
>     how to evaluate the condition (true, false, greater than, string
>     compare, regexp matching, etc) so you don't have to rewrite the
>     logic every time.  To solve this problem, all that would be needed
>     is to tell it how to evaluate "children.index" (or some such
>     notation).  Currently I have implemented:
>         * page.url
>         * page.title
>         * page.slug
>         * page.breadcrumb
>         * page.children.count
>         * page.part[part_name]
>         * vars[my_variable_name] (more on this in point #2)
>
>  2. Ways to get/set basic variables.  For this one I had created a
>     <r:store /> tag that could be used like:
>         <r:store vars="my_var1: 'some string text'; my_var2: 100;
>     my_var3: false />
>         <r:puts value_for="vars[my_var1]" />   -->  "some string text"
>
>     You could also use puts with the above like...
>         <r:puts value_for="page.children.count" />  (not sure how
>     useful this is...)
>
>     Where it got nice though is using it with the conditionals like:
>       ---- in page ----
>         <r:store vars="linkText: 'Some example link text'; url:
>     my/target/url;
>             class: myClass" />
>         <r:snippet name="link" />
>
>       ---- in snippet ----
>         <a href="<r:puts value_for="vars[url]" />"
>         <r:if cond="vars[class]"> class="<r:puts
>     value_for="vars[class]" />"</r:if>>
>           <r:puts value_for="vars[linkText]" />
>         </a>
>
>     I had also implemented a modified <r:snippet> tag to make the
>     first part easier so you could just do:
>       ---- in page ----
>         <r:snippet name="link" vars="linkText: 'Some example link
>     text'; url: my/target/url;
>           class: myClass" />
>
> Ok, so that's a long explanation.  I'm happy to resurrect the  
> extension, but the big question is would this (or something similar)  
> be useful?
>
> Let me know...
>
> -Chris
>
>
>
> John W. Long wrote:
>> On Jun 26, 2008, at 8:36 AM, Jim Gay wrote:
>>> I think it should allow a "group" or "size" option.
>>>
>>> <r:if_first size="3"> would apply to the first 3. Working with  
>>> more than just one would be useful.
>>>
>>> I would want to have these tags with that option:
>>> if_first / unless_first
>>> if_last / unless_last
>>>
>>> I'm not sure about the name of the parameter though. Perhaps  
>>> <r:if_first window="3">
>>
>> How about:
>>
>> <r:if_index in="1,2,3">    # if it's one of the first 3 children
>> <r:if_index in="-1,-2,-3"> # if it's one of the last 3 children
>> <r:if_index is="1">        # equivalent to <r:if_first />
>> <r:if_index is="-1">       # equivalent to <r:if_last />
>> <r:if_index is="even">     # if it's an even row
>> <r:if_index is="odd">      # if index is an odd row
>>
>> Seems like a 1 based index would be most helpful here.
>>

_______________________________________________
Radiant mailing list
Post:   Radiant@...
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

[Chris Parrish-6]

Thanks for your response and kind words, Jim.  See my comments below...

Jim Gay wrote:

> I agree that the list of if_this unless_that can get very long, but
> there is a benefit in that the intentions of the code are clear.
> I remember seeing emails about your extension and being very
> interested in the past, Chris, but I didn't have time to take a look
> at it.
>
> I agree with the principle that a single r:if would make life simpler,
> but my gut reaction is that it starts looking less natural. But maybe
> I'd feel better with some nomenclature changes.
>
> Please resurrect it. I've got some questions that might just be
> cleared by using it.

At this point, I plan to bring it back.  I have two issues I'd like to
address and time is the big factor.

>
> Something just bugs me when I see shortcuts such as the attribute
> "cond" when I feel like "condition" would be clearer. I think that in
> a system like Radiant, which seems to have some good coverage with
> non-technical users, clear intentions are important.

I agree.  Actually, in my original version I permitted both cond="xxx"
and condition="xxx" to allow for quicker typing among the geeks.

>
> I would scope the variables stuff more explicitly, such as
> <r:variables:store> and <r:variables:output>
> Because, although I haven't done it yet, I think a simple ecommerce
> web store would be a nice extension and <r:store> would make sense there.

Good idea.  Other variations included <r:set var[s]="x: 1; y: 20">  I'm
now thinking that a better approach would be <r:vars x="10" book="John"
chapter="3" verse="16" />.  It seems more readable.

By the way, I opted to only create a specific variable setter but a
generalized getter.  Since my <r:if condition="page.title == foo"> had
to be able to evaluate page.title to compare it, it seemed natural to
create a way to output anything evaluation-able.  So you can also:
    <r:puts value_for="page.title" />  or
    <r:puts value_for="page.part[my part]" />

Now, these two examples overlap with the existing <r:title> and
<r:content part="my part"> which are more concise, but it makes it nice
for extension writers to easily offer:
    <r:puts value_for="this.that" />

(more on "this.that" below...)


>
> You mentioned using <r:if cond="children.index = 1"> but should that
> have a double equal (==)?

It currently allows "x=1", "x ==1", or  "x equals 1" since radiant is
geared at the non-programmer.  Incidentally, "x == y" is also permitted.

> Does it allow the use of RegExp matching with =~ ?

It currently allows "x matches /regexp/" and "x match /regexp/" but also
including "=~" would be trivial.

In addition, the following comparisons are permitted:

    * "x exists", "x exists?", or just "x"
    * "x blank", "x is_blank", or "x blank?"
    * "x empty", "x is_empty", or "x empty?"
    * "x not 12" or "y != 'my string value'"
    * "x < y" or "1 lt 2" (> and gt also available)
    * "y <= 'A'" or "x lte z" (>= and gte also available)


> Does the extension provide a way to easily describe how to parse
> things like "children.index" or "this.that" ?

No -- though I've always considered this critically needed.  This is
where I got stuck as my ruby and radiant chops just weren't there.  I'd
love to look into it now that I am much more familiar with radiant but
this is also the place I would very much welcome help.

Basically, my code parses the condition into left and right symbols and
the comparison element and then hands off the symbols to be evaluated.  
I'd want extension writers to be able to add in code to define how to
evaluate their own custom symbols.  I need a good mechanism for that.  
So if you define a current_shopper.index, you could instantly offer:
    <r:if condition="current_shopper.index equals 1000000>
        <strong>Hurray! You're the millionth shopper!</strong>
    </r:if>

> Does it have the equivalent unless tag?

Sure does.

>
> I disagree with John's suggestion too. <r:if_index in="-1,-2,-3">
> makes me think, "huh?"
>
> Just this evening I was walking a client through parts of their
> Radiant site. I always say something to the effect of "you can always
> contact us when things need to be changed, but this is how its done..."
> Some people speak up and say "Ok, forget it, I don't need to see that"
> while others pay attention.
> When I walked through a few examples we have with <r:if_content
> part="part_name"> the client said, "Oh, cool". The intentions of that
> code are very clear and I have little fear (depending on the user)
> that someone can screw that up.
>
> That's not to say that everything should be dumbed down, but to me
> something like <r:if_first group_of="10"> is very friendly. So a DRYer
> <r:if> would be nice, but I think a friendly dialect (for lack of a
> better term) is very important.

What he said.

I too, want to see maximum usability and comprehension for the
non-techie.  And I *certainly* welcome input as to how to improve the
wording/syntax/approach used here to deliver on this.

-Chris

_______________________________________________
Radiant mailing list
Post:   Radiant@...
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

[Simon Josi]

I mostly agree with what Jim said. It'd be more natural to work with
"speaking" tags like <r:if_index> or <r:if_first>. Radius tags are a
cornerstone of radiant, and as complexity grows, more tags emerge.
Sticking all functionality into one <r:if> does IMHO not reduce
complexity nor does the user have less to learn. Nonetheless there is
certainly room for extensions like the one from Chris. I'd especially
like the variables part, i could use it to "parametrize" snippets, a
feature which I'm missing too.

Chris, is your extension available on GitHub?

/simon

 On Thu, 26 Jun 2008 21:41:11 -0600
Chris Parrish <chris.parrish-forummail@...> wrote:

> Thanks for your response and kind words, Jim.  See my comments
> below...
>
> Jim Gay wrote:
> > I agree that the list of if_this unless_that can get very long, but
> > there is a benefit in that the intentions of the code are clear.
> > I remember seeing emails about your extension and being very
> > interested in the past, Chris, but I didn't have time to take a
> > look at it.
> >
> > I agree with the principle that a single r:if would make life
> > simpler, but my gut reaction is that it starts looking less
> > natural. But maybe I'd feel better with some nomenclature changes.
> >
> > Please resurrect it. I've got some questions that might just be
> > cleared by using it.
>
> At this point, I plan to bring it back.  I have two issues I'd like
> to address and time is the big factor.
>
> >
> > Something just bugs me when I see shortcuts such as the attribute
> > "cond" when I feel like "condition" would be clearer. I think that
> > in a system like Radiant, which seems to have some good coverage
> > with non-technical users, clear intentions are important.
>
> I agree.  Actually, in my original version I permitted both
> cond="xxx" and condition="xxx" to allow for quicker typing among the
> geeks.
>
> >
> > I would scope the variables stuff more explicitly, such as
> > <r:variables:store> and <r:variables:output>
> > Because, although I haven't done it yet, I think a simple ecommerce
> > web store would be a nice extension and <r:store> would make sense
> > there.
>
> Good idea.  Other variations included <r:set var[s]="x: 1; y: 20">
> I'm now thinking that a better approach would be <r:vars x="10"
> book="John" chapter="3" verse="16" />.  It seems more readable.
>
> By the way, I opted to only create a specific variable setter but a
> generalized getter.  Since my <r:if condition="page.title == foo">
> had to be able to evaluate page.title to compare it, it seemed
> natural to create a way to output anything evaluation-able.  So you
> can also: <r:puts value_for="page.title" />  or
>     <r:puts value_for="page.part[my part]" />
>
> Now, these two examples overlap with the existing <r:title> and
> <r:content part="my part"> which are more concise, but it makes it
> nice for extension writers to easily offer:
>     <r:puts value_for="this.that" />
>
> (more on "this.that" below...)
>
>
> >
> > You mentioned using <r:if cond="children.index = 1"> but should
> > that have a double equal (==)?
>
> It currently allows "x=1", "x ==1", or  "x equals 1" since radiant is
> geared at the non-programmer.  Incidentally, "x == y" is also
> permitted.
>
> > Does it allow the use of RegExp matching with =~ ?
>
> It currently allows "x matches /regexp/" and "x match /regexp/" but
> also including "=~" would be trivial.
>
> In addition, the following comparisons are permitted:
>
>     * "x exists", "x exists?", or just "x"
>     * "x blank", "x is_blank", or "x blank?"
>     * "x empty", "x is_empty", or "x empty?"
>     * "x not 12" or "y != 'my string value'"
>     * "x < y" or "1 lt 2" (> and gt also available)
>     * "y <= 'A'" or "x lte z" (>= and gte also available)
>
>
> > Does the extension provide a way to easily describe how to parse
> > things like "children.index" or "this.that" ?
>
> No -- though I've always considered this critically needed.  This is
> where I got stuck as my ruby and radiant chops just weren't there.
> I'd love to look into it now that I am much more familiar with
> radiant but this is also the place I would very much welcome help.
>
> Basically, my code parses the condition into left and right symbols
> and the comparison element and then hands off the symbols to be
> evaluated. I'd want extension writers to be able to add in code to
> define how to evaluate their own custom symbols.  I need a good
> mechanism for that. So if you define a current_shopper.index, you
> could instantly offer: <r:if condition="current_shopper.index equals
> 1000000> <strong>Hurray! You're the millionth shopper!</strong>
>     </r:if>
>
> > Does it have the equivalent unless tag?
>
> Sure does.
>
> >
> > I disagree with John's suggestion too. <r:if_index in="-1,-2,-3">
> > makes me think, "huh?"
> >
> > Just this evening I was walking a client through parts of their
> > Radiant site. I always say something to the effect of "you can
> > always contact us when things need to be changed, but this is how
> > its done..." Some people speak up and say "Ok, forget it, I don't
> > need to see that" while others pay attention.
> > When I walked through a few examples we have with <r:if_content
> > part="part_name"> the client said, "Oh, cool". The intentions of
> > that code are very clear and I have little fear (depending on the
> > user) that someone can screw that up.
> >
> > That's not to say that everything should be dumbed down, but to me
> > something like <r:if_first group_of="10"> is very friendly. So a
> > DRYer <r:if> would be nice, but I think a friendly dialect (for
> > lack of a better term) is very important.
>
> What he said.
>
> I too, want to see maximum usability and comprehension for the
> non-techie.  And I *certainly* welcome input as to how to improve the
> wording/syntax/approach used here to deliver on this.
>
> -Chris
>
> _______________________________________________
> Radiant mailing list
> Post:   Radiant@...
> Search: http://radiantcms.org/mailing-list/search/
> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

_______________________________________________
Radiant mailing list
Post:   Radiant@...
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant