DabbleDB demo

FeedAPI + Feed Element Mapper == create CCK types on the fly. Those are the proper elements here. Arto's crazy ass brilliant RDF vision could also fit in here.

Saved searches in the Views area feels...wrong. But yes, it needs to live somewhere. A saved search is a powerful thing. In fact, it's a subscription, with notification :P Cron: ouch, ooch, so much pain. How do we integrate something fires on action instead of this cron kludge? Can it be done without a companion "daemon" that sits around and does this stuff in realtime, all the time?

Automatic view creation: yep. Djun has been looking at this for Cocktail, but mainly from an IA perspective. If you create a new content type, you probably want a default view (teaser/table/whatever) that lists all nodes of that content type.

Avi Bryant, one of the DabbleDB founders, presented at OSCMS 2006 / Vancouver. Look also for his video presentation at Railsconf 2007: lots of stuff about the future in there, and how Smalltalk already lives there.

FEM does not currently create content types nor fields. It just does mapping between incoming stuff and existing fields. Thats a key piece, but we are not very close to a solution here.

Saved searches have nothing to do with subscription or notification. They are basically bookmarks. They have some querystrings on the end that describe exposed filter state. Thats all.

I have thought about hsi demo a bit more and I now think that CCK and Views should do what they do and not participate here. What we need is a set of GUI modules that use CCK and Views in the background to do their thing. These modules are very much user interface guidance. One can imagine using these modules and disabling Views UI and not using the field admin pages offerred by CCK.

I concur that the functions of DabbleDB would be absolutely awesome to have as part of the funcitonality of Drupal.

I think the idea of Saved searches as views is great in general, although for cloning functions like those in DabbleDB, maybe there is leaner way for saved searches that can be immediately useable to non-admin users? It's not that I am arguing against saved searches as views. It's just that maybe saved searches could be available to views, but also available to whatever it is that emerges from interested folks' work, that ends up enabling this dabble db clone idea that Moshe has introduced. I could be wrong or misinterpreting here, of course.

I also think that Feed API, and FEM are great in general. But again, they do not seem like they themselves alone will accomplish what DabbleDB does, and I am sure that you are all aware of this, of course. Although, it does seem to me like their functionality could be an integral part of accomplishing it, at least for content that can be imported via some form of XML or RDF data.

Moshe's statements above about

"Can we design a flow whereby node_import module could suggest and then create the needed CCK fields to hold the incoming data?

Can we add a metric ton of flexibility to CCK whereby we can take a field and move it into a new content type (i.e. the demo moves Person into a 1st class object) and move fields (and data) between content types (in the demo, the Company field moves over the new Person 'content type').

Could we get a View created automatically for each content type that has the right exposed filters automatically? And then a UI which progressively shows those exposed filters in the 'query by example' method in the demo?"

...really make sense to me, especially the part about adding flexibility to CCK, and CCK being able to suggest/create fields for importing data. The building blocks seem to be there for those functions to exist in some form. And auto-creation of views, which actually could then go on to accomplish what Moshe talked about with saved searches, so maybe that would work, too.

I think the idea of being able to import csv, tab delimited, RSS/XML/RDF, geodata, and basically anything you can put into a spreadsheet, then making cck fields for each, with options to change field type, and to arrange in different views is really great. A jquery or AJAX based interface could make it really useful, too.

Sam Rose
Social Synergy

In the D6 version we have an API for CCK fields that should make it easier to dynamically create the fields, and we have batching in core, which should make it easier to dynamically populate the data. I guess in theory lots of the building blocks are there.

Would you use data from the import to create new fields or would you try to using existing fields? The first would be easier, there's no good system to tell what fields have what settings to figure out which ones would match. If you create all new fields you could first run some sort of analyze over the data to figure out some basic settings -- integer or decimal, size, etc. -- merge settings imputed from the data with some default settings for that type of data to create a completely defined field, then create the fields with the API, then do the import.

Creating fields with the API is theorically possible, but not tested and not complete. CCK uses the API to create its own fields, so the API works, but we need to work on things like locking module-created fields so they don't get altered by people using the UI.

Using the API, it should be possible to move the fields from one content type to another, too. Again, CCK uses the API to do that now.

The missing piece is actually getting module-generated field code working and tested so we can work out any problems that might be created by having some fields handled by the UI and others that are not.

When I saw that video, I knew at once that it was making spreadsheets look cool, something impossible.

Glom is similar to CCK in many things. Please see screenshots: http://www.glom.org/wiki/index.php?title=Screenshots

If you search for "dabbleDB (smalltalk OR squeak OR seaside)" you will find a lot of hits. So I assume the basic concepts behind smalltalk, squeak and seeside will show, how to build these great functions. You will also find audiofiles with Randal Schwartz. Yes, Randal Schwartz wrote many perl-books, and now he evangelizes squeak http://en.wikipedia.org/wiki/Squeak .

I believe Randal Schwartz, that squeak or smalltalk is a cool language - but I'm not sure if it's the right time to jump on it.

And i think there is no conceptual barrier to transfer the smalltalk approaches to PHP.

What do you think?

Best
Thomas Zahreddin
= partner of http://voicehero.net =