This is not Allegro related, but maybe someone can help me anyway.

I have some data in a database and I need to display it in a web page. I'm using .NET. What are my options? There's an existing solution that does it ASP style - that is it reads data from the database and writes HTML as output. What other options are there? One way I can think of is reading the data into XML and then using XSL transformations to make the final HTML. Is this the way to go or are there other methods? Those built-in ASP.NET components (like DataGrid) are supposedly out of the question because both data and the desired presentation are too complex.

Going the XSL route seems to be an unnecessarily roundabout way for no appreciable benefit. I don't know ASP, but if it's anything like how it's done in PHP, it's probably what I would do unless there were some special conditions that required some more complex representation. In short, I favor the KISS approach. Perhaps if you reveal more details we can help more?

(Side note: Thanks to masking, I managed to cook together a neat map tool in just a day. Thanks, miran!)

I don't know how it's done in PHP but in ASP you have plain HTML mixed with VB code which generates the dynamic parts of HTML. The existing application is written in ASP.NET which uses a different model (separate html from code) but the guy who wrote it decided to do it by generating the HTML tables on the fly in the code-behind code. So basically the code looks like this (pseudocode):

string out = "<table>"
for each record in recordset
   out = out + "<tr><td>"
   out = out + some data
   out = out + "</td></tr>"
end for
out = out + "</table>"
write out to the page

This of course looks extremely ugly and I'd rather not do it myself. Yes the XML way is less straightforward, but it seems to me a lot more organized. What I'm asking is whether it's worth the trouble or not. The thing is I have to make quite a good number of these tables.

Woohoo. Hopefully one day I'll pick it up again and also finish the dialog designer tool.

In PHP, I'd do something like:

<?php
echo "<table>"
while ($row = mysql_fetch_assoc($sqlresult)) {
  echo "<tr>";
  foreach($row as $val)
    echo "<td>$val</td>";
  echo "</tr>";
}
echo "</table>";
?>

Pretty much what you gave in pseudocode.
This is pretty reusable, no matter what your query, but the XSL route might still be better for more complex projects.

For strictly tabular data, use a DataGrid. If it truly isn't capable, and you need to convince me of this, then use a Repeater control.

I like to code in my url strings, like so:
http://mywebsite.com/myPage?command=SELECT&fromTable=USERS&ORDER%20BY=ASYNC%20DATE

The formating is done through CSS

Ugh, that's not feasible in many situations, not related to this situation, and a flat-out Bad Idea.

http://mywebsite.com/myPage?command=SELECT&fromTable=USERS&ORDER%20BY=ASYNC%20DATE%3B%20DROP%20TABLE%20users

Its obviously better then all of the alternatives.

It has nothing to do with anything mentioned in this thread. He already has the data, he needs to render it to HTML. Exposing SQL injection doesn't make his presentation better.

But if you make a mistake in your SQL query its easier to fix!

Yeah, because any site visitor can do it for you

That's a BAD BAD idea dustin! I'm a web designer myself and I've never seen such a thing, for obvious reasons!

The only case you would do that is when the data will be presented in many formats: HTML, PDF, XLS, CSV. If that's not the case, you don't really need to go that way; a direct query and a for loop will be enough.

That's so a security risk! Yves would be delighted to test his 133t h4x0r skillz.

I've done a little bit of both ASP and ASP.NET and you'll need to write the HTML yourself.

In ASP.NET, there are webpage controls where it'll create a table/form/animation, or whatever, using functions (like an application). I don't know if that exists in ASP though.

Wow. That's very close to exactly what I need! I'll give cookies later.

I had a feeling it would be, it's a pretty common task

I'd rather use a DB wrapper myself, like Pear::DB or MDB2. Also, DDustin, why in the world would you want to do that, and how does it make it any easier to fix your SQL?

Again, that has nothing to do with his problem.

But why not let your visitors design your site? Thats the open source model isn't it

I just wanted to say thanks again.

I would like to report this to the EFW police! That is a blantant disregard for this weeks rules, three times in a row.

I've done HTML creation in ASP and PHP and don't mind so much. Simple tables are relatively simple to generate. I don't know how complex your project is, but I'd say it's doable with simple generation code. Unfortunately, I have yet to do ASP.NET so I don't know how to use it to generate these things. Here's a simple example I just made up using ASP:

Note:   gobjProduct is an ADODB.Recordset containing Products...
        <% and %> are ASP opening and closing tags...

...etc.

    <table>
        <tr>
            <th>Product Name</th>
            <th>Product Price</th>
        </tr>
    <%Do Until gobjProduct.EOF%>
        <tr>
            <td>
                <%=Response.HTMLEncode(gobjProduct("Name"))%>
            </td>
            <td>
                <%=Response.HTMLEncode(FormatCurrency(gobjProduct("Price"), 2))%>
            </td>
        </tr>
    <%Loop%>
    </table>

etc...

Note that VBScript, the actual language used in this ASP example, is very Null sensitive. It pretty much requires you to check for Null before passing any value into a function. I can only hope that ASP.NET fixes this issue. I don't think it's an issue in PHP though.

Assuming you make these GET variables "safe" before embedding them in SQL it should still be okay. It's just odd to present the user with back-end terminology. It might be better if command was action (new | update | delete) and you use an id to keep track of which record. Make sure the logged in user has rights to do these things before allowing them to be done, etc... ORDER%20BY becomes order and fromTable should simply be from.