I think it all matters based on your context.  I do agree that I would
follow Sean's approach first.  For example, Alex, I might do this:

<r:box>
<div class="box">
 <h2>
   <img src="/images/icons/<r:icon />.png" />
   <r:title />
 </h2>
 <div class="content">
   <r:content />
 </div>
</div>
</r:box>

You can scope your radius tags so you don't have to repeat the box
part.  I'm not 100% on how name collisions happen but I'm sure Sean or
someone else can speak up to that.

Here's an example of a tag from my page event extension that I would
not break down, <r:events:calendar />.  It outputs a table tag filled
with all the rows for the current month's calendar.  As the tag
designer I decided to keep the calendar html structure hard-coded.  I
expect that if people want to change how it looks they'll use css.

So in the end you'll have to determine if your tag's use should allow
more customization or be hard-coded inside the tag.  There can be more
work breaking down each tag than doing a single whole tag. However, if
you ever have to change it (like via attributes or some such) you have
been wishing that you hadn't gone with a single tag.

Cheers,
Marty



On Wed, Jun 25, 2008 at 11:29 AM, Alex Wayne <[EMAIL PROTECTED]> wrote:
> Learn new things everyday.  Do you have a brief example of that?  One of the
> reasons I have written some custom tags such as this is because there is no
> way to pass arguments to snippets.
>
> So if I understood you right, I can have a snippet:
>
> <div class="box">
>  <h2>
>    <img src="/images/icons/<r:box:icon />.png" />
>    <r:box:title />
>  </h2>
>  <div class="content">
>    <r:box:content />
>  </div>
> </div>
>
> Then I define my <r:box> tag to render that snippet, capturing "icon" and
> "title" from the attributes of the tag, and use that in the expansion of
> <r:box:title> and <r:box:icon>?
>
> That does seem quite a bit cleaner.  Perhaps not having render(tag).with_tag
> matcher is some syntatic vinegar to discourage what I did in the first
> place.  Also, this approach may not be the best case for writing your first
> extension then.  It involves a bit more steps and probably is better as a
> later lesson.
>
>
> -Alex
> http://beautifulpixel.com
_______________________________________________
Radiant mailing list
Post:   Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Reply via email to