Custom Document

Hi, I am new to modx, and really like its simplicity and well integrated features. great work.

I am looking to see if I can create a custom Document and store the custom data in a seperate mysql table. Is xPDO the answer?

An scenario would be:

1. I have a custom Document - "Product Specification"
2. I have a custom mysql table which has these fields: product id, product name, dimension, weight, color.
3. I have a "New Product Specification" button in modx, next to "New Document" and "New Weblink"
4. When I click on "New Product Specification", it will give me a form to add a new product specification.
5. In addition to the default modx Document fields, and instead of the general Document content and TVs, I will have a section of custom form with the custom fields - product id, product name, dimension, weight, color.
6. Data entered into the custom fields will be stored in a custom mysql table "tblProductSpecification".
7. I can manage the "Product Spefication" object just as any other Document in modx, including setting access permissions, using templates, etc.

Is anyone working on something similar?
Would be great if there’s any example on how to work this out. appreciate any thoughts.

Thank you.

ft

In 0.9.6 and before, you could use xPDO to manage this extra data associated with the documents, but the management of that data would likely require TV’s that could take the input in the manager interface (or quickedit) and would then set and save the extra data via manager plugins. However, all permissions would still be at the Document and TV level; you would have to write custom code to apply these permissions to your custom table data directly.

However, xPDO may be overkill, depending on your full requirements; you should be able to accomplish the storage of this extra data simply as TV fields attached to a document. It would not have the benefit of dedicated tables representing your custom data (they would be stored with all TV data), but it would allow full control over the permissions in the MODx context without (m)any custom scripts having to be developed.

In 0.9.7, which is currently in development (alpha-stage) and should see a beta release early this summer, you could actually define a new resource class (resource is the new name for documents and other objects represented in the site tree, all extend the core modResource class; i.e. documents are represented by the modDocument class, just as web links are represented by an extension of modResource titled modWebLink, etc.) to help manage this custom data.

Does this indicate that a custom database table could be considered a resource within 0.9.7 ?

Is it still the case that 0.9.7 beta will be released at the same time as 0.9.6 final, as indicated in other posts?

Cheers,

Steve

Thanks opengreek. I really look forward to the flexibility in the new resource class in 0.9.7. The ability to use custom tables would be great since the data in the custom tables could be updated/access/backup by other applications as well. TVs makes it difficult to manage the data using other applications.

for testing purpose, is 0.9.7 alpha available for download as of now? I downloaded the trunk version a week ago, and it’s still 0.9.6.

Thanks.

ft

I use TV’s as input fields from external databases on several sites. A quick snippet or @EVAL is all it takes to have data pulled from an external table related to the document in a TV, and a plugin takes care of the extra steps to edit/save it on the back-end.

Defining classes that extend the core resource class does not mean you won’t have to store data in the main resource table (site_content), but it will make it very easy to encapsulate that logic in one place so that you can manage additional related data in an external table easily, and allow complete customization of the requests and responses associated with it.

A public 0.9.7-beta branch will be made available publicly as soon as possible following 0.9.6 final. The trunk will remain 0.9.6 for a few weeks following 0.9.6 release.

Quote from: OpenGeek at May 12, 2007, 10:12 AM

I use TV’s as input fields from external databases on several sites. A quick snippet or @EVAL is all it takes to have data pulled from an external table related to the document in a TV, and a plugin takes care of the extra steps to edit/save it on the back-end.

Could you explain how this works Jason?

Quote from: ProWebscape at May 12, 2007, 02:06 PM

Could you explain how this works Jason?

I’d love to know this also - does it simply mean that a TV contains an @EVAL statement that makes a call to an external DB?

I can see the benefit to this approach from the perspective of administering the external DB - indeed this is why I’d love to have tighter integration of external DBs in Modx - but wouldnt this cripple Modx’s performance if it loaded a multiple TVs?

Cheers,

Steve

Quote from: DangerMouse1981 at May 18, 2007, 05:51 AM

I’d love to know this also - does it simply mean that a TV contains an @EVAL statement that makes a call to an external DB?

You wouldn’t even need to use @EVAL, Selecting other databases is as simple as using @SELECT followed by any manner of SQL statements. (see @Bindings)
Quote from: DangerMouse1981 at May 18, 2007, 05:51 AM

but wouldnt this cripple Modx’s performance if it loaded a multiple TVs?

There is definitely extra overhead from querying multiple databases, but the good news is that once the TV is loaded and cached, the database won’t have to be queried again.

I guess my question is: How can the values of the external databases be saved?