I see your point Sean, and I think I realized that about halfway
through writing the extension.  :) As Alex points out, the problem is
not being able to pass data in with snippets.

I've solved this in other places using the Data Pages extension (due
to the fact that the data context from the page is still available in
a snippet).  Only problem is it currently only works with JSON backed
data sources...  Maybe it's time I take another look and see if I can
make it a bit more generalized so we can finally have parametric
snippets.

-Andrew

On Wed, Jun 25, 2008 at 1:29 PM, 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
>
> On Jun 25, 2008, at 9:43 AM, Sean Cribbs wrote:
>
>> I realize this problem may be for a specific project, so take my
>> commentary with a grain of salt. It has always been my intention (and John's
>> too) to keep any markup out of Radius tags, and it usually ends up
>> simplifying testing them.  Markup in a tag definition is a bad code smell to
>> me (use a snippet instead!), especially since Radiant is content-type
>> agnostic.  When designing a new tag or set of tags, here's a strategy I
>> usually take.
>>
>> 1) Write a snippet of what I would want the tag(s) to look like.  This is
>> usually something that is derived from a block of HTML or other code given
>> to me by the designer.
>>
>> 2) Write some tests or specs that define the behavior of one tag in the
>> snippet.
>>
>> 3) Implement the tag to pass that test.
>>
>> 4) Rinse and repeat until all tags are implemented.
>>
>> The advantage of this is that it forces you to think about the individual
>> logic of each Radius tag and not have them tied to the markup too heavily.
>>  You start with the result and work your way back to the implementation.
>>  The other side-effect is that if the designer wants to change the markup,
>> it's really easy to do and doesn't require the developer's intervention.
>>
>> Sean
>>
>> Alex Wayne wrote:
>>>
>>> But the provided matcher that does
>>>
>>>  page.should render(tag).as(expected)
>>>
>>> is so handy!  But you are definitely right.  White space issues
>>> especially make this a bit cumbersome.  Perhaps that matcher needs to be
>>> expanded.  What if you could do this:
>>>
>>>  page.should render(tag).with_tag('h1', 'Test Title')
>>>
>>> or even
>>>
>>>  page.should render(tag).with_tags do |output|
>>>   output.should have_tag('div') do |div|
>>>     div.should have_tag('p', 'Content')
>>>   end
>>>  end
>>>
>>> that would make speccing custom tags far easier I think.  Plus it should
>>> be easy to just hook into the have_tag matcher.  I smell another patch
>>> brewing...
>>>
>>> -Alex
>>> http://beautifulpixel.com
>>>
>>> On Jun 25, 2008, at 8:24 AM, Andrew O'Brien wrote:
>>>
>>>> Nice work!
>>>>
>>>> One thing I'd add to your spec section (and I'll let you decide how
>>>> you want to integrate this into the article) is to use "should
>>>> have_tag" instead of string comparison.  The main disadvantage I've
>>>> found with strings is that it's hard to track down individual
>>>> characters sometimes (especially if they're blanks) and can be quite
>>>> fragile when the code is changed.
>>>>
>>>> I've put up a pastie with some spec code that uses "should have_tag":
>>>>
>>>> http://pastie.org/private/xgab7akob3tqbxdltzeeg
>>>>
>>>> (The "before" is a little nasty -- I wrote this before scenarios where
>>>> available.)  Feel free to adapt this to the examples in the article
>>>> (or get in touch with me if you'd like some assistance).
>>>>
>>>> -Andrew
>>>>
>>>> On Tue, Jun 24, 2008 at 11:15 PM, Alex Wayne <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>
>>>>> Radiant 0.6.7 generates extensions with a spec directory by default,
>>>>> and no
>>>>> test directory at all. Its all hooked up already for ya.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On Jun 24, 2008, at 7:50 PM, "Marty Haught" <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> On Tue, Jun 24, 2008 at 3:26 PM, Alex Wayne <[EMAIL PROTECTED]>
>>>>>> wrote:
>>>>>>>
>>>>>>> I got inspired this morning and managed to complete an article about
>>>>>>> writing
>>>>>>> an extension to implement a custom tag, with a spec driven process.
>>>>>>>
>>>>>>> http://wiki.radiantcms.org/Creating_an_extension_I
>>>>>>>
>>>>>>> I hope its accurate, as I am still a bit of a noob with Radiant.
>>>>>>
>>>>>> Nice start to the article.  I'm curious on your steps on integrating
>>>>>> rspec and scenarios into your extension.  I just started the migration
>>>>>> to spec and scenarios from test:unit and fixtures and am getting some
>>>>>> strange errors.  We should definitely document any additional steps
>>>>>> beyond running the extension generator for getting up and running.
>>>>>>
>>>>>> Cheers,
>>>>>> Marty
>>>>>> _______________________________________________
>>>>>> Radiant mailing list
>>>>>> Post:   Radiant@radiantcms.org
>>>>>> Search: http://radiantcms.org/mailing-list/search/
>>>>>> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant
>>>>>
>>>>> _______________________________________________
>>>>> Radiant mailing list
>>>>> Post:   Radiant@radiantcms.org
>>>>> Search: http://radiantcms.org/mailing-list/search/
>>>>> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant
>>>>>
>>>> _______________________________________________
>>>> Radiant mailing list
>>>> Post:   Radiant@radiantcms.org
>>>> Search: http://radiantcms.org/mailing-list/search/
>>>> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant
>>>
>>> _______________________________________________
>>> Radiant mailing list
>>> Post:   Radiant@radiantcms.org
>>> Search: http://radiantcms.org/mailing-list/search/
>>> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant
>>>
>>
>> _______________________________________________
>> Radiant mailing list
>> Post:   Radiant@radiantcms.org
>> Search: http://radiantcms.org/mailing-list/search/
>> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant
>
> _______________________________________________
> Radiant mailing list
> Post:   Radiant@radiantcms.org
> Search: http://radiantcms.org/mailing-list/search/
> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant
>
_______________________________________________
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