Thinking myself in circles . . .

OK, I’m beginning to see fairly clearly how ModX can be used to pull data from any source (file, database) through the use of TVs and then to format that data through the use of various widgets and CSS and then save and display it as an XHTML page. My question is this: how to take this one step further and save the data back into a database so that then that data can be run through another cycle which aggregates (and re-displays in a different format) the data expressed on the XHTML pages. Basically what I’m asking is that if TVs+Widgets (Display Controls) act as the "R" and "D" in CRUD how might you all suggest we interface between the created XHTML ModX built page and a database that stores a pre-populated dropdown form to accomplish the "C"? Does the Form Processor snippet accomplish this or move us in this direction?

Quote from: neutrino at Apr 06, 2006, 09:34 PM

OK, I’m beginning to see fairly clearly how ModX can be used to pull data from any source (file, database) through the use of TVs and then to format that data through the use of various widgets and CSS and then save and display it as an XHTML page. My question is this: how to take this one step further and save the data back into a database so that then that data can be run through another cycle which aggregates (and re-displays in a different format) the data expressed on the XHTML pages. Basically what I’m asking is that if TVs+Widgets (Display Controls) act as the "R" and "D" in CRUD how might you all suggest we interface between the created XHTML ModX built page and a database that stores a pre-populated dropdown form to accomplish the "C"? Does the Form Processor snippet accomplish this or move us in this direction?

Just for those that don’t know...CRUD stands for Create, Read, Update, Delete, the standard operations performed on a database row. Anyway...

Currently I believe the answer is no neutrino, though several of the form processing components posted in our repository do handle some of the CRUD operations, or at least assist with the tasks in some way, I do not believe any of them work directly as widgets. However, upcoming changes for the 1.0 roadmap (to be revealed very soon) will address CRUD operations (and much more) in some very cool ways. I hesistate to discuss this in detail at this time, since some of the details are still being worked out in the last phases of design and implementation of the new 1.0 MODx core framework and API’s, but we are definitely moving in the direction you are thinking about.

In the meantime, I recommend exploring the various form processors available now. I cannot recall all of them at the moment, but I authored a PHP helper class to use in snippets and such, called MakeForm. It handles creating custom forms via simple PHP array definitions and using chunks as templates for various form element types, and it includes helpers for handling all that CRUD, but there are some other approaches available as well...I encourage you to search the repository and find the approach that suits your needs best.

Quote from: OpenGeek at Apr 06, 2006, 10:18 PM

Just for those that don’t know...CRUD stands for Create, Read, Update, Delete, the standard operations performed on a database row. Anyway...

And there I was thinking "display"--what a dork. I really do have one of those split right/left minds that won’t stay working on one side or the other for very long. And then top that off with being trained as an assemblage artist/conceptualist and look out

. . . we are definitely moving in the direction you are thinking about.

That’s all I need to know. Think of my question then as a gentle breeze aimed at the perpetual flame that is the great potential of ModX.

In the meantime, I recommend exploring the various form processors available now.

That I’ll do. Thanks a lot, Jason, for such a quick response. When I’m not poking on Modx to figure out what it does I’m in awe of what happens after I poke. It’s all really very refreshing.