Embedding Html Code In Stored Procedures

We seem to have a few developers here who think creating stored procedures that spit out HTML or Javascript code is a legitimate thing to do. In my mind this is the ultimate abuse

Solution 1:

Yucko. There are a few issues:

• Can't 'skin' the app - move to a totally new presentation like Flex, desktop forms, etc.
• You prevent graphic designers or UI experts from working in an environment that's productive for them.
• If you mix your HTML storage (some in templates, some in the db, some in app code), it's absolutely awful to track down UI issues.
• No IDE DOM/layout validation
• You can't preview or prototype without running the db.

Solution 2:

if this is done haphazardly it is probably a violation of the separation of concerns principle of layering

on the other hand, sprocs expressely written to generate html from database info can in some cases be very legit and efficient, esp. for highly dynamic soft-coded web sites, i.e. where part of the web site structure is encoded in the database, or where the database itself contains HTML fragments...

Solution 3:

Horribly wrong! Just my opinion though.

Solution 4:

Utlimate no-no. Aside from all the previous concerns like security, low coupling and layering, what happens when your company wants to syndicate the content, serve it to mobile devices (wap, etc.), use it in text based emails or print, etc.

Solution 5:

I don't think the problem is separation of concerns so much as sprocs just lack the tools to do this right.

Also anyone else coming across this code is going to have problems figuring it out, and it's going to be very hard to source-control, integrate and unit test.

The only exception would be if your database actually stores Javascript or HTML that's edited elsewhere, as part of a CMS for instance.