Document Actions
Content Types in Plone
Filed Under:
Inigo is expanding, and that also means that we have to start tracking things like employee records, HR forms, claim forms and what not.
Now typical way we would usually go about doing this, is let's define some fields for a table in an RDBMS, write some CRUD (or use a framework) and voila we have a simple form. No problems, I can do this in 5 minutes with Python on Planes and some Snake Oil.
On the other hand, I think that the form is just a content type (text fields), that could have interchangeable workflow, security permissions and will need to interact with other content types and forms, be easily defined in different custom views and have a nice standards compliant UI that an end user can modify any of the above in flexible ways.
Example, if this employee moves to another department, in the physical world, I would hand the form over to another manager, and that manager would then have the same rights I had by physically having the form, but would not have rights for the forms I have in my hand, even though he is also another manager. The forms in his hands, would not be available either for lower level managers in his department. At the same time, the employee should be able to modify their details, but need to submit to the manager for approval. Did the permissions and workflow code for your 5 minute application consider this? Does it do versioning and track history?
Then the HR department also needs access to it, and they want to quickly have the records sorted by specific keywords such as expertise. Sorry client.. that's another feature, I have to code the view for sorted by that now, and also more CRUD to deal with adding expertise now, or any other possible sortable keyword HR could think of. HR also reminded you that the company is an equal opportunity company and they have some disabled people working that need your application to also be accessibility enabled.
On the other hand, if I created this content type in Plone, it will be just another content type (Employee Record) that could be added and managed as either folders or as views (collections), and this content type would then be able to take advantage of all the existing features in Plone such as workflows, role and hierarchy based permissions, keywords and collections (smart folders in Plone 2.5) and the existing tested standards and accessibility compliant UI.
If the client is already on Plone, even easier, no retraining needed and by installing it as a new Product, all the site managers can now simply "Add Product" in their site setup to add the functionality. Look and feel doesn't have to be redone, and it integrates with what they already have.
Keep in mind however that Plone, like Snake Oil isn't the solution that cures all ills. Do consider however, if your need is similar to the situation above.
A brief article will be posted this weekend with examples. Also you can check it out and talk to me at MyGOSSCon. Inigo will be there at booth B5 where you can see Plone as well as the latest Gnome Desktop running on a Pentium I 233Mhz (kind of).
Now typical way we would usually go about doing this, is let's define some fields for a table in an RDBMS, write some CRUD (or use a framework) and voila we have a simple form. No problems, I can do this in 5 minutes with Python on Planes and some Snake Oil.
On the other hand, I think that the form is just a content type (text fields), that could have interchangeable workflow, security permissions and will need to interact with other content types and forms, be easily defined in different custom views and have a nice standards compliant UI that an end user can modify any of the above in flexible ways.
Example, if this employee moves to another department, in the physical world, I would hand the form over to another manager, and that manager would then have the same rights I had by physically having the form, but would not have rights for the forms I have in my hand, even though he is also another manager. The forms in his hands, would not be available either for lower level managers in his department. At the same time, the employee should be able to modify their details, but need to submit to the manager for approval. Did the permissions and workflow code for your 5 minute application consider this? Does it do versioning and track history?
Then the HR department also needs access to it, and they want to quickly have the records sorted by specific keywords such as expertise. Sorry client.. that's another feature, I have to code the view for sorted by that now, and also more CRUD to deal with adding expertise now, or any other possible sortable keyword HR could think of. HR also reminded you that the company is an equal opportunity company and they have some disabled people working that need your application to also be accessibility enabled.
On the other hand, if I created this content type in Plone, it will be just another content type (Employee Record) that could be added and managed as either folders or as views (collections), and this content type would then be able to take advantage of all the existing features in Plone such as workflows, role and hierarchy based permissions, keywords and collections (smart folders in Plone 2.5) and the existing tested standards and accessibility compliant UI.
If the client is already on Plone, even easier, no retraining needed and by installing it as a new Product, all the site managers can now simply "Add Product" in their site setup to add the functionality. Look and feel doesn't have to be redone, and it integrates with what they already have.
Keep in mind however that Plone, like Snake Oil isn't the solution that cures all ills. Do consider however, if your need is similar to the situation above.
A brief article will be posted this weekend with examples. Also you can check it out and talk to me at MyGOSSCon. Inigo will be there at booth B5 where you can see Plone as well as the latest Gnome Desktop running on a Pentium I 233Mhz (kind of).
