Say we're going to build a large media site using episerver solution, all the content in the site are dynamic and frequently updated, Expressen.se for example. And, Any visiter can register and write articles, but the article should be approved by some sort of administrator before they are published. Case like this, do we use the Episerver database for storing all the content, user or administrator info, or, using a separate database?
First if, we use a separate database, is it possible to keep the episerver caching function? as it's one of the greatest features.
Second if, yeah, using same database, but the content is frequently changed, and it's not actually the episerver editor who's going to put the articles, it's the end user, and a whole site user/adminsitrator registration,rights system will be envolved which apparent, have to have their own interface than the episerver editor/admine mode. Therefore, is it a good idea to use the same database? or adding new tables in it? what about future update? will it mess the whole thing up? The biggest point here is to keep the episerver cache function.
I hope any1 could give me some suggestions or links that I can read, this project is quite different then the early ones I did and apparently, I'm no expert at all, hope the good ppl here could give me some good advice (:
I suggest you use EPiServer for storing the user generated articles as well. It's very common to have simplified edit functions for users who don't have access to edit mode and to create the pages in code-behind.
For moderating/approval you also have excellent functions for EPiServer pages because you don't have to publish them. You can have publish access rights for moderators/editors only. Then connect an approval workflow to automate this process and simplify for the moderators.
If you want to you can build the moderating functions into the pagetypes, and display them only if the logged in user has publish access rights for example. That way you can have moderators browsing the site and they can edit/remove/unpublish content etc. very easily.
The possibilities are endless. The only reasons I can see to store the pages in a separate database or table is if you use another product (like EPiServer Community, which by the sounds of it, would probably be a good feature for your site), or if you use the data from another application with specific needs. For examle if you need to do queries in the database and these queries require some article data to be in their own columns (i.e. not using properties to store the data).
Alright, that's very helpful, thx a lot! here are a few follow up questions, hope u still got the patience to answer (:
You can create whatever groups you like. Then, when users register at your site, you can add them to any groups you like. Then you can set access rights in the page tree any way you like. So it's simply very flexible :) When rendering content and working in code-behind you can also choose to apply access rights or not, depending on what you need to do.
Yes, you probably have to create your own forms for letting the users input the content which will be on the pages. You can however, use the Property webcontrols to let the user input data by setting the EditMode aspnet property to true (not the whole story, but it should get you started, also search the forums for more info on this).
When you create a page, even if you do it programmatically, you always set the page type first. This defines what properties will be available for you to fill. Then you can fill them with data from anywhre, for example from a textbox which you let the user fill (be sure to consider injection attacks etc.) Refer to this blog post for an example.