Hi, could someone please point me in the right direction. I'd like to have our content editors to be able to add/modify/delete entries, each with multiple fields. For example, a content editor might want to add a hotel, which has a name, address, and telephone number. The content editor might also want to delete the hotel, or change one of those fields.
I'm pretty comfortable with .NET programming, etc. and now have some very basic experience with Umbraco including having migrated part of a .NET site into Umbraco.
Yes, I've added properties and editable fields. It seems as though there is a slight weakness with this, unless I'm doing something wrong. Say I create tab/property/field in, say the Hotels Document Type - let's call it "HotelName" - and it's a Richtext editor field. That field is now available to add to any template in the site, not just a Hotel template.
Also, it looks as though with Rich's solution above, there would be a fixed number of hotels. I'd like a content editor to be able to have 0-n (zero to n) hotels. That is, the content editor should be able to add and delete hotels.
Admittedly I'm a newbie w.r.t. Umbraco so I could be missing something with both of these topics.
Seems like maybe you want your hotel listings to have the behavior of journal listings. You may want to display and sort them differently from a news feed, but each would have its own page, like a news article. And you'd have to work out how you want them to be navigated and browsed.
If each hotel's info is too complex for a single page, you could use a little javascript (like tabber) to divide the information into tabs on each page.
But if they were generated using the journal model, there could be infinite numbers controlled by the editor, all based on a fixed document type with predictable fields. And if a new field were needed in the future (such as hovercraft parking), you could make it available to all hotels by changing the document type.
As for those fields being available on all pages, you want to be sure you are adding these properties to the hotel listings document type, and that there are no other pages using this document type. Also you want to be sure there are no child document types that you wish to not inherit properties. So be sure you take property inheritance into account.
For the first issue, it's a hard requirement that they all stay on the same page. It turns out that it's acceptable for the content editors to edit relatively raw text or HTML, so they can deal with adding/deleting/editing hotels with (most likely) a Richtext field.
As for the second issue, page fields, I've tried a bunch of permutations. I created two new parallel root document types ("newdoctype" and "newdoctype2") with no child document types. I added a page field property "newprop" to "newdoctype". When I open any template (i.e. a template that is not inherited from the "newdoctype"), and press the button "Insert umbraco page field", a dialog pops up. That dialog has a "Choose field" dropdown. In that dropdown, I always see "newprop", no matter which template I am in. I therefore conclude that 1) I'm still doing something wrong 2) there is a bug in Umbraco or 3) this is the way Umbraco works.
So it sounds like you're looking at making a data listing that your editors can populate. And you probably want to be able to sort it by several of the fields... so you'd make macros to dynamically sort the hotel data. (By rating, by City, State or zip code, by Hotel name, etc.)
In my opionion, you'll have fewer headaches if you pre-style the data that editors will be entering as much as possible, having them them enter simple data in a text field. You'd be amazed at the errors novice coders can introduce, including pasting in text from Word Docs (eek!). Only give them leeway where they need it, and offer them CSS styles that are appropriate for the content they'll be entering.
Alternately, if you like hacking you could use the Starter Kit newsfeed or weblog and adapt it to suit your purposes. (in case you like working that way and want to see how macros work - I did that once before)
As for the templates, my understanding is that property names may show up in the selection list, but they'll only display on the editor's entry page if they're actually added to the document type. Did you test that on your pages (not just the templates, but the actual content)? I had assumed the reason this is possible is so that the developer can work in any order he/she likes. I think the basic Umbraco TV 'Templates Overview' video by Pier Hansen addresses this at 6 minutes, 25 seconds.
Good luck with this project. I think Umbraco will give you great flexibility in setting it up your way.
Indeed the property names don't display on the actual pages.
Re: Contour, etc., it would be hard to convince management to spend money on add-ons, not that they're not worth it :^) ... I think if we go the pre-styled route, I'd wind up writing some user controls wrapped in macros. I definitely agree that a content editor could mess up a page but for now, the requirement is simply to let them edit their own html.
You wrote: ..."When I open any template (i.e. a template that is not inherited from the "newdoctype"), and press the button "Insert umbraco page field", a dialog pops up. That dialog has a "Choose field" dropdown. In that dropdown, I always see "newprop", no matter which template I am in. I therefore conclude that 1) I'm still doing something wrong 2) there is a bug in Umbraco or 3) this is the way Umbraco works."
I believe the answer to this is #3. I was a little surprised when I first encountered this too, but it makes sense to me now and I'm fine with it, since the template doesn't have knowledge of which doc type you might want to use it with---the relationship is the other way around, i.e., it is the doctype that is aware of the templates. You just need to make sure you pick the fields that you are expecting to actualy have present.
Furthermore, I hope you'll give Rich Green's answer another look, which is exactly what I would suggest as well. He is proposing two new document types, note the plural: Hotels doctype vs. Hotel doctype. (I would probably give these aliases hotelsPage vs. hotelItem.) Although you are creating two "levels" of actual documents, you only need a template on the Hotels Page. (The individual Hotel items, as you mentioned, would not need their own template.)
This gives you the flexibility to add and remove fields from the individual hotel items as you see fit. Like Diane, I too would not recommend a big wysiwyg for such a situation.
OK, I tried this approach and I think I have a mental disconnect. It seems as though the content editor cannot add or delete individual hotels without having access to the "Settings" page, which could be dangerous.
You (the developer) will want to setup two document types in the Settings section. Once those are created and have the desired field ("properties") setup on them, your content editors will be able to create as many hotels as they would like in the Content section. (They should not need to modify the document types in the Settings section in order to add new content nodes)
I created a Document Type called "Hotel", alias "hotelItem". I gave this two properties, "HotelName" and "HotelAddress" which are Richtext editors. I also allowed it to have a "Hotels" template.
I allowed "Hotel" to be a child nodetype of "Hotels".
I created another Document Type called "Hotels", alias "hotelsPage". I was not able to add "Hotel" or its alias as a property, it does not show up in the "Type" dropdown list.
Even though this already seemed like it wouldn't work, I created the Template called "Hotels". I then created a "Hotels" page under Content, and if does not have any editable fields.
I think you probably will not want the "hotelItem" to have a template of its own, if you were not expecting these to be on their own pages/have their own URLs.
Instead, you would want your "hotelsPage" to use a "Hotels Page" template. Be sure to set the "strucutre" tab of your hotelsPage doctype to allow child "hotelItem" nodes.
The trick in the Content section, is to first create a single Hotels page node (of doctype "hotelsPage"), and then under that node (as child nodes), you create as many hotelItem nodes as you would like. Keep in mind that every node in your content section does not necessarily have to correspond to their own pages. By using these "hotelItem" nodes in this fashion, you are using them more for just data storage and not, for example, as individual pages. (So adding a new hotel is the same as adding a new hotelItem node. Once your "hotelsPage" node is built, you likely won't be editing it further.)
Your "Hotels Page" template will want to loop through all of the hotelsPage node's child hotelItem nodes, and display information about these. There are a few great examples of doing similar things like this in the Umbraco TV section of this site. If you don't have a subscription (recommended) there may be a few free ones to get you started. The one that comes to mind for me is a nice one on "creating an FAQ page" which uses this same strategy.
Hey Funka!, that did the trick, thanks! The part that I was missing is that the content editor, rather than I, would create a new specific hotel node under the Hotels node. That seems acceptable so far, and seems like a cleaner solution than using a package. The "Embedded Content" package had a few shortcomings anyways, regarding usability, though it seems like a cool concept.
The XSLT that I'm using at least to prove that it works (will need some work on the asthetics, including getting rid of the pesky <p> tags) is as follows:
Help creating a repeatable set of fields...
Hi, could someone please point me in the right direction. I'd like to have our content editors to be able to add/modify/delete entries, each with multiple fields. For example, a content editor might want to add a hotel, which has a name, address, and telephone number. The content editor might also want to delete the hotel, or change one of those fields.
I'm pretty comfortable with .NET programming, etc. and now have some very basic experience with Umbraco including having migrated part of a .NET site into Umbraco.
I think I'm just missing something very basic.
TIA,
Paul
Hi Paul,
You could just have a hotel as a doc type, something like this :
Home
--- Hotels
---- Hotel 1
---- Hotel 2
---- Hotel 3
Each editor could add / edit / delete hotels as they need to.
Unless I'm missing something?
Rich
Hi Rich,
Once I create the "Hotel" doc type, then what's next? Do I create a "Hotel" template?
How would I add a "Hotel" to the "Hotels" page or content area?
TIA again,
Paul
Create a 'Hotels' Doc Type which is allowed under 'Home'.
Then create a 'Hotel' doc type which is allowed under 'Hotels'
Rich
To be clear:
Home (Home DocType)
---- Hotels (Hotels DocType)
------------- Hotel 1 (Hotel Doc Type)
------------- Hotel 2 (Hotel Doc Type)
------------- Hotel 3 (Hotel Doc Type)
------------- Hotel 4 (Hotel Doc Type)
This makes your hotels individual, sortable and you can have as many Doc Type properties on a hotel as you need.
Rich
Hi Paul,
Do you know about adding properties to the Document Type in order to make fields that the editors can fill in?
Once you create the page with that Document Type, the fields are available to the editor.
Good Luck!
Yes, I've added properties and editable fields. It seems as though there is a slight weakness with this, unless I'm doing something wrong. Say I create tab/property/field in, say the Hotels Document Type - let's call it "HotelName" - and it's a Richtext editor field. That field is now available to add to any template in the site, not just a Hotel template.
Also, it looks as though with Rich's solution above, there would be a fixed number of hotels. I'd like a content editor to be able to have 0-n (zero to n) hotels. That is, the content editor should be able to add and delete hotels.
Admittedly I'm a newbie w.r.t. Umbraco so I could be missing something with both of these topics.
Thanks,
-- Paul
Seems like maybe you want your hotel listings to have the behavior of journal listings. You may want to display and sort them differently from a news feed, but each would have its own page, like a news article. And you'd have to work out how you want them to be navigated and browsed.
If each hotel's info is too complex for a single page, you could use a little javascript (like tabber) to divide the information into tabs on each page.
But if they were generated using the journal model, there could be infinite numbers controlled by the editor, all based on a fixed document type with predictable fields. And if a new field were needed in the future (such as hovercraft parking), you could make it available to all hotels by changing the document type.
As for those fields being available on all pages, you want to be sure you are adding these properties to the hotel listings document type, and that there are no other pages using this document type. Also you want to be sure there are no child document types that you wish to not inherit properties. So be sure you take property inheritance into account.
I hope this helps.
Hi again Diane,
For the first issue, it's a hard requirement that they all stay on the same page. It turns out that it's acceptable for the content editors to edit relatively raw text or HTML, so they can deal with adding/deleting/editing hotels with (most likely) a Richtext field.
As for the second issue, page fields, I've tried a bunch of permutations. I created two new parallel root document types ("newdoctype" and "newdoctype2") with no child document types. I added a page field property "newprop" to "newdoctype". When I open any template (i.e. a template that is not inherited from the "newdoctype"), and press the button "Insert umbraco page field", a dialog pops up. That dialog has a "Choose field" dropdown. In that dropdown, I always see "newprop", no matter which template I am in. I therefore conclude that 1) I'm still doing something wrong 2) there is a bug in Umbraco or 3) this is the way Umbraco works.
Thanks and regards,
Paul
Hi Paul,
So it sounds like you're looking at making a data listing that your editors can populate. And you probably want to be able to sort it by several of the fields... so you'd make macros to dynamically sort the hotel data. (By rating, by City, State or zip code, by Hotel name, etc.)
If you want to separate your data entry from the back-end, you might want to look into using Contour as one option:
http://our.umbraco.org/projects/umbraco-pro/contour
In my opionion, you'll have fewer headaches if you pre-style the data that editors will be entering as much as possible, having them them enter simple data in a text field. You'd be amazed at the errors novice coders can introduce, including pasting in text from Word Docs (eek!). Only give them leeway where they need it, and offer them CSS styles that are appropriate for the content they'll be entering.
Alternately, if you like hacking you could use the Starter Kit newsfeed or weblog and adapt it to suit your purposes. (in case you like working that way and want to see how macros work - I did that once before)
As for the templates, my understanding is that property names may show up in the selection list, but they'll only display on the editor's entry page if they're actually added to the document type. Did you test that on your pages (not just the templates, but the actual content)? I had assumed the reason this is possible is so that the developer can work in any order he/she likes. I think the basic Umbraco TV 'Templates Overview' video by Pier Hansen addresses this at 6 minutes, 25 seconds.
Good luck with this project. I think Umbraco will give you great flexibility in setting it up your way.
Hi Diane,
Indeed the property names don't display on the actual pages.
Re: Contour, etc., it would be hard to convince management to spend money on add-ons, not that they're not worth it :^) ... I think if we go the pre-styled route, I'd wind up writing some user controls wrapped in macros. I definitely agree that a content editor could mess up a page but for now, the requirement is simply to let them edit their own html.
Regards,
Paul
Paul,
You wrote: ..."When I open any template (i.e. a template that is not inherited from the "newdoctype"), and press the button "Insert umbraco page field", a dialog pops up. That dialog has a "Choose field" dropdown. In that dropdown, I always see "newprop", no matter which template I am in. I therefore conclude that 1) I'm still doing something wrong 2) there is a bug in Umbraco or 3) this is the way Umbraco works."
I believe the answer to this is #3. I was a little surprised when I first encountered this too, but it makes sense to me now and I'm fine with it, since the template doesn't have knowledge of which doc type you might want to use it with---the relationship is the other way around, i.e., it is the doctype that is aware of the templates. You just need to make sure you pick the fields that you are expecting to actualy have present.
Furthermore, I hope you'll give Rich Green's answer another look, which is exactly what I would suggest as well. He is proposing two new document types, note the plural: Hotels doctype vs. Hotel doctype. (I would probably give these aliases hotelsPage vs. hotelItem.) Although you are creating two "levels" of actual documents, you only need a template on the Hotels Page. (The individual Hotel items, as you mentioned, would not need their own template.)
This gives you the flexibility to add and remove fields from the individual hotel items as you see fit. Like Diane, I too would not recommend a big wysiwyg for such a situation.
Best of luck!
OK, I tried this approach and I think I have a mental disconnect. It seems as though the content editor cannot add or delete individual hotels without having access to the "Settings" page, which could be dangerous.
You (the developer) will want to setup two document types in the Settings section. Once those are created and have the desired field ("properties") setup on them, your content editors will be able to create as many hotels as they would like in the Content section. (They should not need to modify the document types in the Settings section in order to add new content nodes)
Hi again.
I created a Document Type called "Hotel", alias "hotelItem". I gave this two properties, "HotelName" and "HotelAddress" which are Richtext editors. I also allowed it to have a "Hotels" template.
I allowed "Hotel" to be a child nodetype of "Hotels".
I created another Document Type called "Hotels", alias "hotelsPage". I was not able to add "Hotel" or its alias as a property, it does not show up in the "Type" dropdown list.
Even though this already seemed like it wouldn't work, I created the Template called "Hotels". I then created a "Hotels" page under Content, and if does not have any editable fields.
-- Paul
I think you probably will not want the "hotelItem" to have a template of its own, if you were not expecting these to be on their own pages/have their own URLs.
Instead, you would want your "hotelsPage" to use a "Hotels Page" template. Be sure to set the "strucutre" tab of your hotelsPage doctype to allow child "hotelItem" nodes.
The trick in the Content section, is to first create a single Hotels page node (of doctype "hotelsPage"), and then under that node (as child nodes), you create as many hotelItem nodes as you would like. Keep in mind that every node in your content section does not necessarily have to correspond to their own pages. By using these "hotelItem" nodes in this fashion, you are using them more for just data storage and not, for example, as individual pages. (So adding a new hotel is the same as adding a new hotelItem node. Once your "hotelsPage" node is built, you likely won't be editing it further.)
Your "Hotels Page" template will want to loop through all of the hotelsPage node's child hotelItem nodes, and display information about these. There are a few great examples of doing similar things like this in the Umbraco TV section of this site. If you don't have a subscription (recommended) there may be a few free ones to get you started. The one that comes to mind for me is a nice one on "creating an FAQ page" which uses this same strategy.
Good luck!
Hey Funka!, that did the trick, thanks! The part that I was missing is that the content editor, rather than I, would create a new specific hotel node under the Hotels node. That seems acceptable so far, and seems like a cleaner solution than using a package. The "Embedded Content" package had a few shortcomings anyways, regarding usability, though it seems like a cool concept.
The XSLT that I'm using at least to prove that it works (will need some work on the asthetics, including getting rid of the pesky <p> tags) is as follows:
<xsl:template match="/">
<xsl:for-each select="$currentPage/*[@isDoc]">
<li>
<xsl:value-of select="hotelName" disable-output-escaping="yes"/>
<xsl:value-of select="hotelAddress" disable-output-escaping="yes"/>
</li>
</xsl:for-each>
</xsl:template>
Now it's on to figuring out staging and deployment, etc.
Thanks again.
Regards -- Paul
is working on a reply...