Geek Answers Handbook

Embedding html code in stored procedures

We seem to have several developers who think that creating stored procedures that spit out HTML or Javascript code is legal. In my opinion, this is the ultimate abuse of the partitioning model. Does something like this do people often see people do?

+4
source share
9 answers

Yucko. There are several problems:

  • It is impossible to “remove” the application - go to a completely new presentation, for example, Flex, desktop forms, etc.
  • You prohibit graphic designers or user interface experts from working in an environment that is productive for them.
  • If you mix HTML storage (some in templates, some in db, some in application code), it’s absolutely terrible to track user interface problems.
  • No DOM Authentication / IDE Layout
  • You cannot view or prototype without running db.
+4
source

if this is done randomly, it is probably a violation of the separation of problems by the principle of layering

on the other hand, sprocs explicitly written to generate html from a database can in some cases be very legitimate and efficient, especially. for highly dynamic soft-coded websites, i.e. when part of the website structure is encoded in a database or where the database itself contains HTML fragments ...

+3
source

Awfully wrong! Just my opinion.

+2
source

Indicate no-no. In addition to all the previous problems, such as security, low adhesion and stratification, what happens when your company wants to syndicate content, serve it on mobile devices (wap, etc.), use it in text messages or print, etc.

+1
source

I don’t think the problem is the separation of problems, since sprocs simply do not have enough tools to do this correctly.

In addition, anyone who encounters this code will have trouble figuring out it, and it will be very difficult to control the source code, integrate and unit test.

The only exception is if your database actually stores Javascript or HTML that has been edited elsewhere, for example, as part of a CMS.

+1
source

I survived a job in a store where the entire application emitted all the HTML, fortunately using links to external CSS / JS.

At the time the project started, Oracle did not have support for a separate web application server - everything went through PL / SQL.

Sometimes you just have to use what you got.

Having said that, I do not believe that there is any excuse for creating level-level artifacts from stored procedures in any of modern databases or application architectures.

+1
source

This is a classic newbie mistake.

If you need to put a mark in the SP output, you should at least use your standardized encoding and then apply it to HTML / Javascript.

for instance

"<javascriptpopup>[outputuotputoutput]</javascriptpopup>"

or

 "<prettyfont>[outputuotputoutput]</prettyfont>"
0
source

Self-evident violation of the principle of "low connection, high cohesion."

I can’t imagine how they would suggest applying CSS formatting to such a beast.

0
source

Yes, I saw that many do, unfortunately. You are right though: this is sneaky.

Typically, layer separation problems arise when mixing two adjacent layers — you get business logic at the database level or presentation logic at the business level. But this completely skips the layer, placing the target with instructions on the user side, where it belongs from! Bound to be unshakable horror.

If villains are not convinced of such pleas for sanity, you can catch them for security reasons. Database-level functionality in stored procedures is unlikely to know how to avoid text for output in HTML or JS-string-literal, which leads to very likely script-injection hacks that lead to XSS attacks. For example, if the user calls himself "Brian von <script> steal (document.cookie) </script>" and which is roughly combined into the result of the HTML procedure of the stored procedure ...

0
source

More articles:


All Articles