I need to run some thoughts by someone. Unfortunately I’m the only Rhythmyx developer here at my company.
I’m developing a new content type called Publications. It’ll have some basic fields (title, description, keywords, link to purchase the publication). We are also working on the importer that will import the content from an XML feed from another website (not hosted in Rhythmyx).
Some of our publications are free downloads, some are hard copies only which users must purchase and then some are free download or purchase hard copy.
For the publications that are available for purchase and free download, I need to figure out how to attach the PDF download to the item. My question here is should I simply add a File field to the Publications content type to allow an upload? OR is there some way of linking a File content item to the publication content item and have the template generate the link? Maybe something through a slot or child table? If I use a slot, should be fairly straight forward except now I have create a new slot just for this. Child table, could I just enter a content ID# into the child table and somehow have to assemble the link to the file.
I think the File field option is the most desirable, if for no other reason than it makes for a better user experience because you can complete creation of the content item in step (with the exception of the slightly weird validation logic/behavior of File fields and how it makes you re-upload if there are validation errors). Depending on how your location schemes are set up, you might have to create an additional location scheme or change an existing location scheme to publish and link the attached file, which might be a bit of a pain.
If your authors are used to using the Active Assembly Table editor, I think doing it as a slot is fine too. Of course, they have to upload the PDF file first, then the Publication content item, them link them via the table editor, which is a less ideal experience, but it doesn’t require any configuration changes on the Percussion end, so it would make your life easier.
I would avoid the child table thing altogether. Mainly because the extensions that Pecussion comes with allow you to work single binary files that are part of content type (e.g. img1, img2 in Fast Forward), but they don’t work with data in child tables. Also, depending on how the child table is used, creating a location scheme to publish and assemble items linked in this way seems like it would be difficult, if not not impossible.
I would actually recommend a slot as in the future, you may want to have more than one file / publication associated with the content item (think formats that may be available to the publication to download such as pdf, epub, doc). By adding a file field within the content item, you are restricting the users to just upload one file (or however many file fields you add).
We have a “Resource” content type that used to have a file field (for a pdf version of the resource). A couple years later we had to modify this to be a slot as the users wanted more than one version of the resource available. Yes, with the slots, the user needs to be trained to upload the file first, but that is no different then uploading say images…
Of course, you could do a hybrid solution where you have both the file field and the slot…but that is your call… We chose not to go down that path for consistency’s sake…
Thank you Duane and thank you Jitendra for your comments and recommendations. After giving this some thought, I totally agree about the child table and that’s not the way to go. Jitendra you make a really good point about future formats we may want to offer, so I think I will probably use the slots. The advantage is we already have a file content type for uploading these documents, and a large number of the documents already exist on our website using that content type so we don’t have to convert them.
Again thanks for your comments, I really appreciate the help on this.