tags:

views:

62

answers:

3

Hi,

We are developing a Online Ordering Website and we are planning to be completely flexible in the sense Layout can be changed, Color, Font , and in a page a component(div) can be added.

In this case whether we need to store all our View Code

for example

<div id="MenuContent">
    <div>
        <h4>
            Your Order</h4>
        <hr />
        <%if (Model != null)
          {  %>
        <table width="100%">
            <thead>
                <tr>
                    <th>
                        Item
                    </th>
                    <th>
                        Quantity
                    </th>
                    <th>
                        Price
                    </th>
                    <th>
                        Remove
                    </th>
                    <th>
                        Total
                    </th>
                </tr>
            </thead>

......

in the database or we can just store the div id and based on that load a view which is avalaible in the file system. Any Pointers is greatly appreciated.

A: 

It really depends on how flexible. If yopu want to simply be able to apply site wide themes then you can create the HTML code with standard class names and construct one or more CSS files that make up your THEME. Then to add a new theme, make a copy of your CSS files and modify.

If on the other hand you want individual users to create there own look then storing this in the database will be more appropriate.

Vincent Ramdhanie
A: 

Please clarify what you're trying to do and what system you're trying to do it on.

In general, you don't want to be saving HTML to a database...

MHarrison
Why do you claim storing HTML in a database unwanted?
Sonny
The reason why I need is to make the UI more flexible. But I need to know the disadvantageous of storing the content in the database.Going Forward we like to store all the views and partial view in the database. But like to no exactly what is the disadvantage of it.
lee
It sounds like you're considering storing pre-generated HTML for each user in a database so they can customize the appearance of certain pages...is that right?This is going to result in an awful lot of entries in your database, and an expensive I/O operation each time any user requests a page.
MHarrison
If the performance is only the constraint I can cache the data right. Any other downfalls of this idea and we are planning to use ASp.NET MVC.
lee
And One more point the html stored are not static they are dynamic too.
lee
Storing dynamic HTML makes even less sense. I think what you want to do is store some sort of metadata about how the user wants to customize their layout. Some attribute like "fontColor = red". I'd suggest using cookies for this, but you could also store that in a database relation between the userID and some table "layoutPrefs". Then have your HTML template system dynamically change the layout when pages are generated. Again though, I don't know enough about what you're trying to do.
MHarrison
A: 

What Lee is trying to do is to actually store what would otherwise be aspx files as content in his database. This can be beneficial if you need maximum flexibility in allowing users (or at least non-developers) to be able to customize the site without code changes. Note also that there is ASP.NET markup in his 'file'. Typically the ASP.NET system will load these files from disk when requested and compile it for the CLR. Once compiled, further requests for the same content will reference the compiled code instead of loading the file again; at least until the file changes again. This brings up several technical hurdles to overcome, such as how to get the system to allow you to override the built-in behavior of looking in the file system for the aspx file and instead retrieve the data yourself from your database. There are discussions online about how this can be done. Then there's the question of how to allow the system to still cache the compiled assemblies and a few others come to mind.

But if these technical hurdles can be solved this seems like a very flexible approach if flexibility is the ultimate goal. As far as storing data in a database, that's what databases do, even if there are an awful lot of entries. DB file I/O can be mitigated by caching the content as any high-performance system would probably already be doing with other content. Aren't there already examples of systems that store all of a system's UI as content? I would think some of the more flexible CMS systems must do this already.

Bill