repeated content input type idea

Feb 12, 2014 at 4:30 PM
At the moment if I have to add like a listing of items ( lets say a feature list for an item ) I use a string type and then let content editor add each of these feature divied by a pipe { feature1|feature2|feature3 )

In the template I then go through each of them and display it. would be great if this part could be made more easily with a special input type.

I have a poc in the making by hacking in some js i will show when that is done
Feb 13, 2014 at 8:12 PM
This very much sounds like the discussion we were having, https://sexycontent.codeplex.com/discussions/528454.

I decided to use an XML document rather than a delimited list because it is much more versatile in what it can represent.

In thinking, why hasn't this been done several things come to mind. First, a single content item with a variable number of fields lends itself to a multiple table database design. Looking at the current fields available in 2Sexy Content Types, it appears that everything can currently be stored in a single database table and adding multiple fields could change this. The more tables it needs to contact, the slower it goes.

A natural follow up thought is, well if I can save my data in a XML document to simulate this, when I click save, why couldn't 2SexyContent do something similar and concatenate these multiple fields into a single field represented by an XML document? It seems to me that this would not work because the XML elements are now stored with the data. A search on this field would be treating the XML as searchable content. Unless DNN has some built in mechanism to ignore markup in searches, this could be an issue. One possible way around this is to map things into 2 fields. One field would contain the data in XML format so it could be extracted and used in the object, the other field would be the searchable data. Any fields that should not be searchable do not get put into the second field. This method would require some data processing to transform the XML.

Thinking about one-off use cases, a solution is easy to think of. Where it gets more complicated is "How does this work for every generalized case without slowing things down?". I am guessing that there are a bunch of other issues to think out as well. Good luck with your POC.
Feb 13, 2014 at 9:06 PM
Can I see a sample of your xml solution, interested to see how you solved it
Feb 13, 2014 at 10:34 PM
Edited Feb 13, 2014 at 11:19 PM
Sure. So I decided that I would need an XML structure that looked something like this:
<root>
  <sections>
    <section>
      <title></title>
      <book>
        <productCode></productCode>
        <marketingText></marketingText>
      </book>
    </section>
  </sections>
  <bannerAds>
    <ad type="full">
      <banner imgSrc="" href=""/>
    </ad>
    <ad type="half">
      <banner imgSrc="" href=""/>
      <banner imgSrc="" href=""/>
    </ad>
  </bannerAds>
</root>
There can be multiple <section> nodes and multiple <ad> nodes.
I save this in 2SexyContent as a simple text field.

In the Razor template I load the XML into an XMLDocument that I can use to easily extract the data using this function.
@functions
{
    private XmlDocument loadSectionsXml(string xmlString)
    {
        XmlDocument doc = new XmlDocument();
        try
        {
            doc.LoadXml(xmlString);
        }
        catch
        {
            doc = null;
        }
        return doc;
    }
}
Then I call my function to create the document and I can extract nodes and data from it doing what I want:
XmlDocument doc = loadSectionsXml(Content.XmlField);  //Convert text to XmlDocument
@if (doc != null)
{
    foreach (XmlNode sectionNode in doc.GetElementsByTagName("section"))
    {
        @*DO STUFF TO CREATE THE HTML FOR THE SECTION HERE*@
    }
}
It's not a perfect solution. For one, it doesn't address the issue of searchable data. I don't need to search this data so it wasn't a concern this time.

Hope that helps.
Coordinator
Feb 14, 2014 at 6:39 AM
I understand your solution - it just becomes impossible for a "secretary" to edit.

One thing I don't understand: why try to put it all into one field and one entity? I mean in a "table" kind of way, you would describe the books in one system, and the banners in another. Why force this all into one? Alternatives would be
  1. Create separate banner-entities, refer to this product
  2. Create a separate banner management, refer to pages (Hyperlink to Page:54) which would be more versatile anyhow
  3. Create a banner-field (for only the banners) and use a CSV-kind of syntax (structurally same, but easier to edit)
Feb 14, 2014 at 4:34 PM
This is actually edited by our marketing department. So it's not a secretary doing this in my case, but they aren't web designers or people who are really considered "technical". I do give them training on how to use the system. Even if it's just a web form, there is training involved. It is certainly not as intuitive to the average user as a web interface.

As far as the usability of the process. Data originates in spreadsheets and is copied into the xml fields. Copying and pasting into a web form or the xml fields don't differ too much after the user has been trained.

The reason I didn't use multiple entities for each "ad" or each "section" is the content management aspect of things. When I asked how many section areas were needed I needed to create a field for each, they said put in 40 sections and each section might have up to 20 books and can have multiple data elements per book. This would make for quite an ugly input form if I dedicated a field for each possible element. If each section is a separate entity there becomes a lot of problems with the content management.

The problems I run into are that there are many of these pages created per month, I don't know the exact number but somewhere between 7 and 30. If there were 10 in one month that each had 5 sections, my section entity table would have 500 entries in it after one month. Thinking about adding years of data with that model seems like it would create a difficult to manage system. If there were going to be X number of static pages that just needed content altered, I could see this working out. A growing data set introduces the data management complications.

I think about deleting. What if the page has 40 sections and they need to delete it? I believe this would involve sorting through the table and finding each section and then do 40 individual deletes (which likely involves multiple clicks for each delete). I can imagine the painful moans that I would have to endure over the cubicle wall.

I would like to avoid the xml, so I am not looking for a reason to keep it. I am really trying to simplify the process for the user. These are the real life problems I need to tackle. If I am missing something and these problems can be avoided or aren't problems at all, I want to learn, and make sure I do this the right way.

Thanks for looking at this.