@davidm - Yes, that TurboAdmin does look like phpMyAdmin only with Ajax, and is inappropriate as an editor because it naturally knows nothing of the relations between tables. The only benefit in duplicating that within MODx would be the time saved flipping to our favoured admin app. Admittedly in some cases (eg where access is only via Plesk and you need to log in to that and find your domain and click on your database and then click on webadmin), this is a massive timesaver!
I think en8scl was after something "excel like" and was only pointing out the look and feel of the Data view (which does look nice) - I don’t think he actually wanted a full database editor, he just wanted editors to be able to edit a few tables within MODx.
Yes, as davidm reminds us, the dbAPI lets us build database apps, and the @binding lets us use any table to supply data. This is precisely *why* a generic configurable table editor in the Manager would be so useful. For content, you can have custom "add blog entry" / "add comment" snippets on the frontend if you wish, but most pages will be created and edited using the full, flexible, generic document editor on the backend. For data, we can add custom input and edit facilities to the frontend, but for generic data editing we have nothing. OK, *I’m* perfectly happy using phpMyAdmin, but this is far too raw to let non-techies near.
Sure, the powerful features of dbAPI (and in the future xPDO) let the original poster of this thread build a custom data-editor for his editors to use, but it would still be more desirable to have a generic Database Table Editor.
However, having pointed out this thread during a
discussion on the best way to scale ShopX, an eager coder called humaniweb has decided to try hacking together that specific editor so it can be used alongside MODx. For his purposes (maintaining characteristics of a product such as city of origin), this will be fine.
But there is scope for much more:
Right now,
the ideal Generic Database Table Editor would be a Manager plugin which itself had a "plugin" config file for each table that was to be edited. There is no need for the Table Editor unless you have added a table to MODx, so the requirement for a techie to write a config would not be an issue. Where a common table is being used as part of another MODx extension - say for example an ecommerce extension that worked with an existing osCommerce database - the authors of the extension could make db editor config files available.
The config files would not be dissimilar to a series of TVs - each field could be ascribed a data type and potentially a binding to another table for drop-down selection.
There would be both a grid view of x rows at a time, and a single-entry view.
The editor would *not* enable structural changes.
The difference xPDO makes
Well, primarily the difference is that it enables MODx to move into data management rather than just content management, and delivers on the promise of a framework. This will make a Database Table Editor easier to write, but doesn’t currently fulfil the desire for one - and as OpenGeek recognises, the need is increased. However, there seems a high chance that the focus would be on programming a table editor for xPDO, which could then be integrated with either the MODx manager or a MODx site, as appropriate.
Hmmn. I think OpenGeek will be getting a PM. This looks like exciting times.
MODX Staff
), management interfaces and wizards for creating/editing xPDO objects/tables, generating xPDO classes, and managing objects created with those classes, are absolutely needed for xPDO, and I’d love to have some help making that happen. Anyone interested in getting involved, just let me know...
!!!