I am building a noticeboard for a client; users (members, not backoffice users) log in to their Intranet and can create basic notices which are saved under a specific category node. Both notices and the notice category have their own document types.
I have implemented a solution as follows, but I'm wondering if there's some better way of doing it as it seems a bit hacky:
The notices are created via an Umbraco form, which has a dropdown where the user can select the category. The dropdown is populated from a pre-value datasource that retrieves the set of available notice categories.
The notice document type has a textbox property which the dropdown value is mapped to (I've done it this way because the value from the dropdown that's set on the node seems to be a text string rather than an ID).
All notices are initially saved under a "notices" node, and that's fine - the category nodes are all children of this node.
I'm catching the saving of the notice in the ContentService.Saved event, checking for the correct document type and then using the category value on the node to identify which category node it should be moved to.
I'm doing it this way because it doesn't seem to be possible to retrieve the ID of the node that's just been created from the workflow that creates the node, but I have several issues with it:
1) If somebody changes the name of one of the categories (or adds a new category), the Forms prevalue data source must be updated in order to ensure that the correct value is passed
2) When calling ContentService.Move, there seems to be no way to not re-fire the ContentService_Saved event, which means that the event fires again; the code protects against moving the node again by checking the parent, but it would be better to just not fire the event.
3) If a lot of people are creating notices at the same time then processing the event twice seems a bit wasteful of resources, even if it does exit at the earliest opportunity.
The ideal solution would I suppose be to pass the data to a SurfaceController that could save the node in the right place, but it seems as if I'd have to replicate the existing functionality to do this, just with an adjustment for the way the parent node is identified (unless there's some clever way to do it with XPath that I'm not aware of, e.g. by setting an XPath query in the create node workflow that identifies the correct category node).
Saving a node under another node based on a form field
I am building a noticeboard for a client; users (members, not backoffice users) log in to their Intranet and can create basic notices which are saved under a specific category node. Both notices and the notice category have their own document types.
I have implemented a solution as follows, but I'm wondering if there's some better way of doing it as it seems a bit hacky:
The notices are created via an Umbraco form, which has a dropdown where the user can select the category. The dropdown is populated from a pre-value datasource that retrieves the set of available notice categories.
The notice document type has a textbox property which the dropdown value is mapped to (I've done it this way because the value from the dropdown that's set on the node seems to be a text string rather than an ID).
All notices are initially saved under a "notices" node, and that's fine - the category nodes are all children of this node.
I'm catching the saving of the notice in the ContentService.Saved event, checking for the correct document type and then using the category value on the node to identify which category node it should be moved to.
I'm doing it this way because it doesn't seem to be possible to retrieve the ID of the node that's just been created from the workflow that creates the node, but I have several issues with it:
1) If somebody changes the name of one of the categories (or adds a new category), the Forms prevalue data source must be updated in order to ensure that the correct value is passed
2) When calling ContentService.Move, there seems to be no way to not re-fire the ContentService_Saved event, which means that the event fires again; the code protects against moving the node again by checking the parent, but it would be better to just not fire the event.
3) If a lot of people are creating notices at the same time then processing the event twice seems a bit wasteful of resources, even if it does exit at the earliest opportunity.
The ideal solution would I suppose be to pass the data to a SurfaceController that could save the node in the right place, but it seems as if I'd have to replicate the existing functionality to do this, just with an adjustment for the way the parent node is identified (unless there's some clever way to do it with XPath that I'm not aware of, e.g. by setting an XPath query in the create node workflow that identifies the correct category node).
Any ideas anybody?!
is working on a reply...