Hi All,
A search of this forum has turned up nothing on how to make customizations to the document editing screen. Or maybe I’m framing the problem incorrectly. Either way, I’m hoping someone can shed some light on the topic.
Basically I want to create a grid (javascript) and associate it with a document so that when I edit that document I’m presented with the grid to make changes to the related records for that document. For example, in an ecommerce site the document would be the product and the related records would be the styles of each product (and associated inventory levels, prices, etc). The related records would be stored in a custom table with the document id as the foreign key. I guess what I want is an AJAX grid control template variable.
I’m using 0.9.6.3. Right now I’m using a multiline text field to store each record pipe-delimited per line, using snippet code to pull the data back out for display in the document. This works for me, but it’s not as elegant as I’d like and it makes programatic updates more difficult.
Has anyone done this or otherwise solved the problem before? Using child documents for each related record is not what I have in mind for this job.
Thanks
Since there was no response, let me pose the question in a different way:
Is there a preferred way to insert custom markup into the document editing screen?
-
☆ A M B ☆
- 24,524 Posts
-
☆ A M B ☆
- 24,524 Posts
I see, I suppose. I don’t really see why TVs wouldn’t serve your underlying purpose of storing and displaying custom data about a document since that’s exactly what they are for, but if you are determined to use something else altogether, then I’d have to say that the way the editing forms are built there’s no way to add to them - unless you take the route of ManagerManager, which uses extensive javascript to manipulate the form in the browser.
You could use a plugin to add another form under the main form section, using the OnDocFormRender event, then use something like ManagerManager to put it in another tab.
Another route would be to create a module that would server the purpose, but that would be another section of the Manager altogether. I presume you want this to be part of the normal document editing page.
TV’s aren’t ideal for my situation. I have created an e-commerce site out of my ModX install and I am using one document for each product. Each product, in turn, has several variants (e.g. Oak, Elm, Walnut, etc.) which have different attributes all their own.
For example, if I sold bookshelves, I would have a document for a certain style of bookshelf. Within that document I want to store 6 variants of the same bookshelf. Each variant would have a different sub-sku, finish, price adjustment, description, availability, etc.
Currently, I am using one giant text field to hold all of this, such as:
SKU-123|Walnut|+20|Walnut Veneer|In Stock
SKU-124|Elm|+100|Solid Elm|In Stock
SKU-125|White|0|White Lacquer|Backordered
Then I parse this out using a snippet when the document is presented.
For various reasons, I would like to have this data stored in a database table, rather than flat text. That is why I am wanting to put a way to edit a database table right in the document tree.
I can’t think of a better way to use template variables than what I’m already doing, but that’s just not getting the job done for me.
Thanks for your suggestions, I’ll keep plugging away at the problem.
As I mentioned in my first post, I could certainly create each "variant" as a child document, then use Ditto to display everything, but that leads to the point where an e-commerce site with a modest 100 products and an average of 6 variants per product has 600 child documents to maintain. That seems like a maintenance nightmare to me, considering I’ll be scaling to 1000 products before year-end.
-
☆ A M B ☆
- 24,524 Posts
Ah, I see now. Yes, this has always been a problem with using documents as a catalog. I think ultimately it’s why every effort to make ecommerce modules has eventually slowed and floundered. It’s just not quite the right tool for the job in too many cases.
In this case, then, why not an inventory module as you have described, then using documents to display all the variants of a given product with snippets that query the database generating the dropdowns, checkboxes and / or radio buttons for ordering? Don’t really attach your inventory to documents at all, except for catalog display.
Interesting idea there, I’ll look into that.
Thanks for your responses.
What about making the variants child documents under bookshelves?
Then they’d have separate TVs for SKU, wood, No_in_stock, surface, and backordered. Most of those could have the choices on radio buttons for quick entry.
You’d need a custom snippet to display them, but it sounds like you’re doing that already.
Personally, I’d probably use a third-party shopping cart like FoxyCart.