Difference between revisions of "Extension:RecordAdmin"
From Organic Design wiki
(→RecordAdmin 1.0: NS_FORM) |
|||
| Line 8: | Line 8: | ||
For the last couple of years since [{{fullurl:{{FULLPAGENAME}}|oldid=87774}} RecordAdmin 0.0.1] was created in October 2007, we've kept the version numbering to 0.x to indicate it's experimental nature. Now halfway through 2010 we've been using it for our own project management and organisation and made a number of decisions about how version 1.0 should work. Here's a summary of our findings: | For the last couple of years since [{{fullurl:{{FULLPAGENAME}}|oldid=87774}} RecordAdmin 0.0.1] was created in October 2007, we've kept the version numbering to 0.x to indicate it's experimental nature. Now halfway through 2010 we've been using it for our own project management and organisation and made a number of decisions about how version 1.0 should work. Here's a summary of our findings: | ||
| + | # Rather than use a category of templates to determine the record-types, 1.0 uses the items in the chosen RA namespace (default is NS_FORM) | ||
# The record creation and editing should be done from the standard edit view rather than from a special page. This will be far simpler for the user since we could then remove the "properties" or "edit with form" action. | # The record creation and editing should be done from the standard edit view rather than from a special page. This will be far simpler for the user since we could then remove the "properties" or "edit with form" action. | ||
# The special page is hardly ever used for searching since usually records are arrived at via a portal query. Since the special page would no longer be used for editing or creation either, it seems that it would be best for it to be removed from the main extension and made into a separate sub-extension like ''RecordAdminIntegratePerson'' and ''RecordAdminCreateForm''. | # The special page is hardly ever used for searching since usually records are arrived at via a portal query. Since the special page would no longer be used for editing or creation either, it seems that it would be best for it to be removed from the main extension and made into a separate sub-extension like ''RecordAdminIntegratePerson'' and ''RecordAdminCreateForm''. | ||
Revision as of 00:38, 14 June 2010
|
The Record Administration extension forms the heart of our Wiki Organisation system.
To export all the templates used by RecordAdmin, see wiki articles packages
RecordAdmin 1.0
For the last couple of years since RecordAdmin 0.0.1 was created in October 2007, we've kept the version numbering to 0.x to indicate it's experimental nature. Now halfway through 2010 we've been using it for our own project management and organisation and made a number of decisions about how version 1.0 should work. Here's a summary of our findings:
- Rather than use a category of templates to determine the record-types, 1.0 uses the items in the chosen RA namespace (default is NS_FORM)
- The record creation and editing should be done from the standard edit view rather than from a special page. This will be far simpler for the user since we could then remove the "properties" or "edit with form" action.
- The special page is hardly ever used for searching since usually records are arrived at via a portal query. Since the special page would no longer be used for editing or creation either, it seems that it would be best for it to be removed from the main extension and made into a separate sub-extension like RecordAdminIntegratePerson and RecordAdminCreateForm.
- There should be allowed to be any number of records in a page as long as they are all of different types. And in fact as far as edit view goes, it shouldn't even have a problem with multiple of the same type. The records should all be at the beginning of the article and be removed from the standard edit box. We need to ensure that the method we use for this doesn't interfere with FCK or MCE.
