Your assumption regarding storing the data is correct (just add them as extended properties). Depending on how large a project you want to make this, the complex part is how to display the fields you will be accepting. To minimize the scope of the project, I would recommend making "static" content types (that's what we call the structured data are content types, such as document types, discussion types, etc). By static, I mean having a "Virtual Applicance" content type, or a "Code Sample" content type.
From the top of my head (so this may be a bit off), you will need to start with overwriting the default communityAction . If the name of your community matches what you want to do, run your code showing the pages with the new fields and tabs added, otherwise, run the default communityAction class.
This can definitely be done as a plugin, but isn't of the "hello world" variety Please post online as you have specific questions (hopefully they will help others as well).
Regarding plugin documentation, I recommend these:
(check out the UI Integration points and the Clearspace Plugin Development Guide in particular)
Hope this helps!
Is not the basis of a product based solution already available on the People - Profile Configuration? Fields can be added with a good range of predefined data types.
Having this metadata would also impact other areas such as searching, so deeper integration would be required. See also Typing Documents & Discussion.
I suspect that the ideal solution would be a combination of some additional enabling product level architecture enhancements, re-use of the profile configuration, and extensibility of plug-ins for the data types and rendering.
I 'm very interested in this area. It will help tremendously with developing support requests applications where structured capture and filtering on things like version numbers and operating environments is required.
We are wanting to do something similar (add custom fields to the document type). My one concern with extended attributes is that they require a join for the list view. If this is to be a high volume site should I be concerned about using an extended attribute? Lets say I want to extend Document to have 3 new properties
description(string), asset_id(int), workflow_state(PENDING, APPROVED, REJECTED)
I'd like to show these attributes on the front page of high traffic site along with the comments, ratings, author. It would love to see an example of how to do this taking performance into consideration. Is there supported way to inherit from a base type with fixed db attribute so that search queries are more optimized?
Could you provide an example of a plugin that creates allows a user to pick a document TYPE. This type could just ahve extra attribute "STATUS" on the create from and display form.
That example would save me much time and that seems like a pretty general first modification to CS documents.
I'm also new to clearspacex and am currently going through all the documentation to see how things link together and am trying to do a similar thing - basically want to have a content type extending document that has additional fields (say dropdowns or text or whatever) that persist and are searchable and everything. So a few things - I see that doccreateaction calls document.save() on publish/save draft so I was curious to see what happens in the save() method but I cannot find what class(es) implement the Document interface (not in the javadoc) so I can't see the implementation. Also,what table(s) should be modified to accomodate custom data fields - I see there's a jivedoctypeprop and jivedocumentprop and a bunch of jivefield tables but am unsure as to which require changing - this could also be because my local install is just using the default database (not an external db) for development and I've been unable to figure out how to view the data - how do I view the data in the default db? Thanks for any info.
Okay well I see that you can just add/retrieve new data fields to documents with get/setProperties methods so no manual db manipulation is necessary thanks to jivedocumentprop table which is nice (esp. compared to other cms'es i've used) - still need to see how to make the new fields/properties searchable - but I was looking at document.ftl since the default view won't obviously show these custom fields and I see the document (including the styling and everything) is just rendered through $ and that's it. Can someone tell me where this variable/object gets put into memory or assigned - I tried looking through the files but could not find where this content object is getting instantiated - doc-create.ftl was easier to modify/extend to get the custom fields to show since the document's components are more broken up. Thanks.