The one area we have a problem is when an event contains nested hCard/
geo/addr data as its location and we want to parse that out. Initially
I tried modifying the HCalendar class to set
one :location => HCard
but that fails if the location is a simple string.
I've thought of a few possible approaches, including:
* parse out hcards separately and either hope they match up or use
hpricot and selectors to make sure its only hcards from within the
specific event
* add an extra class such as HCalendarWithNesting and try parsing
with both to see which picks up useful data.
But I wanted to see if anyone had any other ideas, or pointers as I
don't yet know the internals of mofo very well?
Where the specs allow for multiple ways of representing data, it would
be really good to be able to get at the various options through a
single interface.
thanks. James.
> The one area we have a problem is when an event contains nested hCard/
> geo/addr data as its location and we want to parse that out. Initially
> I tried modifying the HCalendar class to set
>
> one :location => HCard
>
> but that fails if the location is a simple string.
What if we do:
one :location => [ String, Adr, HCard ]
The idea here being mofo would try to find a String, then an Adr, then
an HCard when it comes across .location.
If this is what you're looking for, I'll add it in.
--
Chris Wanstrath
http://errtheblog.com
Yeah, that looks like it's exactly what I need.
Would it be better to go in the other order though? Looking for
progressively less structured data?
thanks. James.
> Would it be better to go in the other order though? Looking for
> progressively less structured data?
Good point. I'll try and hack this in tonight. If you're feeling
adventerous, feel free to add a spec (and a fixture) so I can just hit
up the implementation based on a failing test case. Either way, this
has been asked for before so it needs to be done. Will let you know.
> I have a simple spec and a couple of extra fixtures. I'm attaching
> them in a tarball. Let me know if you'd like them submitted any other
> way.
Cool. There are a few issues with this, but I've begun work. Most
importantly: your event_addr.html fixture is wrong, I believe. The
adr and geo inside of the location class should correspond to the
hCard, but you took out the 'vcard' class and the dude's name. This
is confusing, it's understandable, but I think this 'location' example
is an hCard example as opposed to a true Adr example. Got any more
Adr examples laying around? That'd help.
I have been committing to svn://rubyforge.org/var/svn/mofo/trunk
tonight, some changes. I added the Adr and Geo microformats and added
them to hCard.
Should hopefully have the [ HCard, Adr, Geo, String ] stuff done soon.
Of the three specs you've submitted, I've got one passing. It's a
start!
Thanks.
Maybe I should have named that one differently? What I wanted to show
with that was an hCalendar entry with just an 'addr' and not a full
vcard. From the uf wiki:
"A named LOCATION (potentially with an address and/or geo) in
iCalendar may be represented by a nested hCard in hCalendar.
Similarly, an address LOCATION may be represented by an adr, and a
geo (latitude and longitude) LOCATION may be represented by a geo."
For adr on its own there's one example on the main wiki page:
<div class="adr">
<div class="street-address">665 3rd St.</div>
<div class="extended-address">Suite 207</div>
<span class="locality">San Francisco</span>,
<span class="region">CA</span>
<span class="postal-code">94107</span>
<div class="country-name">U.S.A.</div>
</div>
But it seems the expectation is that adr will almost always be used
within another microformat, and there aren't any other examples given.
> I have been committing to svn://rubyforge.org/var/svn/mofo/trunk
> tonight, some changes. I added the Adr and Geo microformats and
> added them to hCard.
>
> Should hopefully have the [ HCard, Adr, Geo, String ] stuff done
> soon. Of the three specs you've submitted, I've got one passing.
> It's a start!
Great!
Thanks.
James.
--
James Stewart
Web Developer
Work: http://jystewart.net/process/
Play: http://james.anthropiccollective.org/
> "A named LOCATION (potentially with an address and/or geo) in
> iCalendar may be represented by a nested hCard in hCalendar.
> Similarly, an address LOCATION may be represented by an adr, and a
> geo (latitude and longitude) LOCATION may be represented by a geo."
The fixture you submitted has an adr AND a geo. The wiki seems to
imply that while iCal can have both, an hCal can only have one or the
other. I am feeling a bit fuzzy on this so will check some more stuff
out to see what the answer is.
Can an hCalendar have a location and a geo and an adr? Questions.
> For adr on its own there's one example on the main wiki page:
Thanks.
Revisiting that paragraph I'd lean towards your interpretation, that
it's one or the other.
How's the coding to support this going?
James.
> Revisiting that paragraph I'd lean towards your interpretation, that
> it's one or the other.
>
> How's the coding to support this going?
It's checked into trunk. I think we're looking at a 0.2 release
sometime next week.
If you wanna play:
$ svn co svn://rubyforge.org/var/svn/mofo/trunk
Here's the new hCalendar format:
http://require.errtheblog.com/mofo/browser/trunk/lib/mofo/hcalendar.rb
My next push for mofo will be adding documentation to the code (need
to document the API for writing custom parsers like xoxo and xfn) and
working on the site, mofo.rubyforge.org.