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

Reply via email to