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
