since I saw Dave going in to the titanium/mobile app session, I thought I’d check out this.
“world adult kickball association”? and that’s the site he works on. kickball.com, 60k visitors/day.
going to be high level. [would like the front lights to be low so I can actually see his slides] – not going to talk about what to do once it’s in drupal, or about geodata, or about twitter or facebook connect, or about D6 or D8.
two options: migration – moving the data from whatever into Drupal, which is a habit in the Drupal community – or reading & leaving the data where it is.
do you have access to the database? if not, then more likely to be *reading* vs migrating.
is the data a moving target? if often changing, leave it outside. otherwise can add a lot of overhead.
quantity of data?
is the data “drupally”?
[and I start to appreciate where Dave’s at, even if he’s not always great at explaining how he got to that POV.]
migrating: two “and a half” options –
1) Feeds module. Lots of formats, UI-driven. (o look, it’s Dave Reid.) Altho I’ll admit that I still find the Feeds module somewhat baffling. Someday…. Huh: Feeds Tamper. Cleaning up data, breaking apart fields, etc. Feeds Image Grabber, downloads & attaches images in data pulled by Feeds. Feeds Readability Parser, tries to work out the title of the page and the content, stripping ads & navigation, etc. Lots more parsers!
2) Migrate! “there are a lot of times when you need a sledgehammer” – slide with link to denver presentation “migrate workflow” – has lots of options. (oh, is that the one I used to use to grab spreadsheets of stuff? (branches, mortgage staff, business members, etc)) Migrate Extras, covers a lot of major modules.
deciding: non-sql data, you’ll probably prefer Feeds. more complex the data, more likely to want Migrate. [no, wait, I was using Node Import, which I loved to pieces, and for which there will not be a D7 version. it was so SIMPLE.]
[also: HUNGRY. Should have had breakfast.]
If you’re thinking about custom code, just extend Migrate instead.
Exposing data to Views.
(which makes me think Forena is just an insane idea altogether.)
Views API is well documented.
hook_views_api — array with the version.
some weird stuff if you’re trying to read D6 data on a D7 site.
hook_views_data
“you’re not going to have a good time”
set up the database info in settings.php
defining the node table programmatically, so it doesn’t flip out about it not being a nodes table? ok, I think I hit the point where I don’t actually know enough. but damn this is just so much more DRUPAL. the only question is how to get this to a UI that admin computing doesn’t freak out about. all that code is about getting around namespace collisions when having one drupal get data from another drupal.
create in the UI or in code? I still don’t really understand what he’s actually doing.
It would be interesting to write a Banner Views module. He does talk about if you have non-Drupal external data, then you’ll need to write external code…which I guess is where Forena comes in.
discussion about getting users from external sources, which is something I don’t need to worry about, since we have that CAS module. also: not my problem.