Feature Request: Choose data source

This might be a huge issue. Ditto is an awesome MODx aggregator with filters, templates, rows. It would be great to have an option to choose the data source or have a function that retrieves the data source and sends it to Ditto- being an xml file, another table.

I guess the loopDbChunk could do this, but it doesnt have near the formatting/templating options as Ditto.

Example 1- Data Source comes from DabbleDB database via CURL.

Example format:


This might even be the wrong section for this. Ditto is great at querying MODx documents and templating the results. I guess I’m looking for a unified way to (1)query an external resource and (2)template the results. The first step would be allowing Ditto to be given the results from another snippet.

Chuck

I see what you mean. However, every data resource is (or can be) inherently different in its structure.

Load a CSV file? Parse XML? Query database(s)? Parse an .ini file? Of course, all of these can be queried, parsed, paginated, formatted and displayed. Ditto was built to use MODx-documents as source data, not such a big variety of formats.

I’m afraid if you extend Ditto that much, it will become simply too big. The parameter list will most likely be quadrupled, and efficiency might be affected too.

Yeah, I think you’re really right. So I’m going to play around with this idea and see if I can make it a decent snippet.

I think it’d be mainly for templating now. And get it’s data handed to it from another snippet. So I’m trying to think of basic parameters for it:
- noResults
- tplAlt
- tplFirst
- tplLast

I would have to decide how to handle the pagination.

For the data source snippet, what would be some functions needed to retrieve info?
- CSV
- CURL
- DB

Then it could pass this as an Array or serialized Array.

I’m really brainstorming here.

As I understand it, Smarty is going to be packaged with MODx 0.9.7, so if you want to get ahead of the curve you might want to direct your templating energies in that direction.

Ditto 4 will most likely support this feature in some form per http://mirror3.cvsdude.com/trac/ditto/codebase/ticket/22. However, it is still some time away as Ditto 3 still needs to be ported to 0.9.7.

Here is my idea:
Abstract all interaction between the MODx document object and Ditto making the Ditto core strictly for presentation and filtering. Then extenders would retrieve the data and pass it on to the Ditto core. Thus, all functions currently in Ditto that relate to handling MODx elements would be in their own extender. Then, anyone could write an extender or use an example one to pull in data from another source or even combine multiple sources.

Now that is a very well-thought out plan. Seems good. I guess that’s a few years off eh?

Is there anything that can be done now to help with that?

Chuck

There is a slim chance it could occur simultaneously with the porting to 0.9.7 if enough of the MODx interaction code needs to be rewritten. Otherwise it is some time away (could be a month, could be a year...). If you can find or write a "migrating your snippets to MODx 0.9.7" guide I’d be immensely grateful.

Well I cant promise anything, but I’ll see if I can work with BobRay since he’s been working more with it (BobRay, you there? PM me?).

Mark, Are you skipping Ditto 3 straight into a Ditto 4? A few posts up you mentioned a Ditto 4 so was wondering.

I’m actually going to be building something like this (unless I missed it and somebody’s already beat me to it) for a site that’s launching next week. Clearly with only a week it’s not going to be a Ditto replacement, but it should be able to handle multidimensional arrays with nested templates and such. That’s kind of what we’re talking about right?

My current thoughts are, roughly, using the following sort of multidimensional array as an example:
- name_first
- name_last
- transaction_details
- - transaction_detail
- - - name
- - - description
- - - price
- - - options
- - transaction_detail
- - - name
- - - description
- - - price
- - - options
- addresses
- - address
- - - street
- - - city
etc.

- Templates and placeholders would effectively all be dynamic. So in your main chunk you’d have placeholders for all the top level nodes. Nodes that have children would then get their own templates assigned, and it’d go all the way down the "tree". So you could call [+addresses+], then you define a chunk for those children that could handle [+street+], [+city+], etc. Much like Wayfinder’s nesting of templates, but done dynamically.

You’d obviously need to know the structure that you’re dealing with, but I think it’d be pretty powerful. Is this what you’re talking about, Chuck? Or are you thinking of a more "flat" data structure?

In any case, we’re in the process of building this on a crazy stupid timeframe, so if anybody has any ideas please let me know. (And if I just hijacked this thread... scold me and I’ll make a new topic.) My hope is that Ditto would be able to do this eventually, but I know it’s not going to happen in the next 5 days

Bret,

So we’re both talking about the FoxyCart data feed eh? That sounds pretty similar to what I’m thinking. Ditto has 2 really powerful features- templating and retrieving modx docs. So it’d be great to use the templating apart from the modx retrieval.

So it seems like you’ve got a great idea there. The multi-dimensional aspect is better than I had thought. Shoot me an email or PM if you want. My first thoughts are:
- Use doze’s idea to retrieve chunk from either file or database chunk (http://modxcms.com/forums/index.php/topic,5344.msg41096.html#msg41096). Be quicker for testing.
- have a base name/id for the call (ie myData) and have it loop through to automatically look for the chunk levels with $i equals (ie myData_1 for first dimension, myData_2 for second, etc). But maybe chunk parameter names would be easier there.