Custom Databases and Forms

Hi,

I'm converting an old Coldfusion site into MODx. Task is to have a fairly complex form for website visitors to book meeting rooms. Database already exists of past and active bookings. About 30 columns of name, address, numbers, dates/times. Needing date calendar, time selections, radios, checkboxes etc.

So, visitor needs usual Form handling stuff (FormIt and FormItFastPack?). Then Submit which loads booking into the database. And then Admins need to be able to read, update and delete bookings. Probably through a front end interface so they don't need to see MODx but not too worried about the Admin side being within MODx.

Initial plan is to follow this.

http://bobsguides.com/custom-db-tables.html with FormIt and maybe FormItFastPack to help make the Forms easier (there will be 3 similar but not identical forms/tables).

Rummaging around I found the following:
FormIt - FormitFastPack, FormSave, mxFormBuilder, migxFormbuilder, FormIt2DB, EventsX

So now I'm not so sure. I suspect EventsX and MxCalendar (which I've used before) are only for Admin use and have limited fields plus shoe-horning my current data into the correct formats would probably be too painful.

Perhaps - FormIt2db + db2FormIt can help in some way (no documentation to speak of).

Any hints. Is the Bob Guide still current?
Some of the above Packages have negligible documentation which isn't helping.
Revo 2.2.10.

Cheers

Stuart

for working with custom-tables inside modx, you can do it this way:


1. give all your tables for your package a unique prefix, lets say 'mybookings_'
2. make sure all your tables have a primary-key-field with the name 'id' - this works best together with xpdo
3. Instal MIGX
4. go to the MIGX-CMP to the tab package-manager.
5. put into the field packageName: 'mybookings' - or something what you would like to be the name of your package
6. click 'Create Package'
7. set the listbox to 'use custom prefix' and put into custom-prefix: 'mybookings_'
8. Do 'write schema' - this will write a xpdo-schema of all tables with the prefix 'mybookings_' - this is a good start
9. you may have issues later with your custom-prefix, so I would rename the table to your default modx-table-prefix + a custom identifier like 'modx_mybookings_'
10. Add 'mybookings_' before the tableNames without 'modx_' in your generated xpdo-schema
11. Run 'Parse Schema'

If I haven't a mistake in that order, you should have now a allready working basic xpdo-package.

Now you can use:

formit and the formit2db - hook to post a form to your table from frontend.

You can create a Custom-Manager-Page for administrating with MIGXdb.
For frontend-administrating there is MIGXangular in the works, what I've allready in use for a customer - Booking/Reservation - system. But this isn't ready for the publics.
So I think Customizing the manager with permissions and using a Custom-Manager-page should work good for the admins.

For building the custom frontend-listings you can use migxLoopCollection or for very customized stuff like calendar-views or something you can use bloX, or send just some json to the client and let some angular-scripts create the booking-view.

just some ideas.

Thanks Bruno, Lots of the forum posts on the subject were started 3+ years ago. Hopefully, the above is the state of the art approach today. Such a shame that complicated Packages like Formit2db have little in the way of useful documentation. http://rtfm.modx.com/extras/revo/formit2db - a few minutes work by the developer would save thousands of hours by the many users.

Bruno,

Spotted this. http://rtfm.modx.com/extras/revo/migxdb
Having installed MIGX it appears to be heavily focused on Database stuff. Have the two Packages merged? I think they have. So will look at the rtfm pages for both.

Also, on http://rtfm.modx.com/extras/revo/migx the Step2. I can see MIGX in the Components menu. So I think this Step has been automated. So Step 2 1. to 19. are not required?

this project started with a TV, called MIGX (Multi Items Grid - TV)
which is a Template-variable, where you can add multiple items into one TV-value, stored as a json-string.
The form-window can use inputTV-types for its fields.

MIGXdb came later for doing db-stuff, the same way as it does for the MIGX - TV.
So the MIGXdb - part is the part, which may be of interest for you.

Quote from: parthian at Dec 20, 2013, 10:28 AM

Also, on http://rtfm.modx.com/extras/revo/migx the Step2. I can see MIGX in the Components menu. So I think this Step has been automated. So Step 2 1. to 19. are not required?

step 2 1. to 15. is not longer required.

16. to 19. does create the configuration-table and is still required.

Hi Bruno,

Don't think the process worked. Got confused with Step 10 in your list above.
10. Add 'mybookings_' before the tableNames without 'modx_' in your generated xpdo-schema

Not sure where the generated xpdo-schema is. Had a good hunt around core folder. Couldn't find a file where I would need to add mybookings_ to anything.

Also, when I left MIGx component and returned there is no way to retrieve my Package. Looked under the Tab MIGx. Expected to be able to see something in the table with ID/Name columns. It was empty. Also Add Items results in this (redacted)


Fatal error: Call to a member function get() on a non-object in /home/.../webapps/.../core/components/migx/elements/tv/input/migx.class.php on line 104


Not sure that the 'Success' popups I was seeing actually meant anything. I'll leave it to tomorrow.

And to summarise your posts above I think MIGX is the Package but you can look at MIGX or MIGXDb in rtfm for specific instructions depending upon the task in hand?

AFAIK, this is still OK: http://bobsguides.com/custom-db-tables.html

It's an easy way to make your table xPDO-friendly if you only have one table with no related objects.

Bob, Bruno et al,

Sadly had to give up on the MIGX-CMP process. I did manage to get somewhere but not convinced the Package code was generated properly. Went through Bob's Guide instead.

Very straightforward even though it looks scary. But I got myself in a right pickle when testing. Table reads/uploads appeared to only work some of the time. After an hour of puzzling realised the snippet calls needed to be uncached.

Bob, could the snippet calls be changed to [[!ShowQuotes]] etc. Would have saved me an hour. Obvious in hindsight.

Then went on to the Formit2db approach.

http://rtfm.modx.com/extras/revo/formit2db
Hhhmmm. not much of a f'ing manual to read. Still there is a forum post linked.
https://forums.modx.com/thread/?thread=32560

Which being really old has a problem. packageName should be packagename. Note the warning - Some parameter names have been changed to lowercase and some have been added. 2 minutes would put a working example in the manual...

And also found what I think is an occasional bug. Error message - "Failed to create object of type:"

Seems the classname can go missing. I got a little bit confused over autoPackage. Not sure what this is for. Frustratingly I got formit2db working when I forced the code within the autoPackage true block to run (the bit that gets the classname). But after other changes couldn't replicate it. Decided to hunt down the classname.
Looked in - /core/components/quotes/schema/quotes.mysql.schema.xml and this provides the classname - <object class="Quotation"

So, changed my formit call by adding this - &classname=`Quotation` and all good. I can now update the Quotation table using Formit, formit2db and XPDO stuff. Without the abortive attempt at MIGX-CMP (a bridge too far for a noob perhaps?), the caching issue, the packageName problem and the odd classname problem I would have got to this stage in an hour or two. Pretty good. Hope the hints above help someone else, and maybe inspire some changes to docs.

Now to try FormItFastPack. Before attempting my 30 plus column form...

Stuart

PS
The classname issue appears to have happened to someone else, they used some older code and it worked. No idea.
https://forums.modx.com/thread/82251/formit2db-error