In case HTML changes the spec one day, again
-
Continuing the discussion from In case HTML changes the spec one day...:
public const string HtmlRowTagIdAttribute = "id";
public const string HtmlRowTagClassAttribute = "class";
public const string HtmlRowTagStyleAttribute = "stlye";public static class HtmlHelper { public static string GetBeginTag(string tag, Dictionary<string, string> attributes) { using (var sr = new StringWriter()) { sr.Write(@"<{0} ", tag); if (attributes != null) foreach (var attribute in attributes) sr.Write(@"{0}=""{1}"" ", attribute.Key, HttpUtility.HtmlEncode(attribute.Value)); sr.Write(@">"); return sr.ToString(); } } public static string GetEndTag(string tag) { return string.Format(@"</{0}>", tag); } public static string GetTag(string value, string tag, Dictionary<string, string> attributes, bool encodeValue = true) { return string.Format("{0}{1}{2}", GetBeginTag(tag, attributes), encodeValue ? GetEncodedValue(value) : value, GetEndTag(tag)); } public static string GetEncodedValue(string value) { return HttpUtility.HtmlEncode(value); } public class Tag { public const string Html = "html"; public const string Body = "body"; public const string Meta = "meta"; public const string Head = "head"; public const string Style = "style"; public const string Table = "table"; public const string Tr = "tr"; public const string Td = "td"; } public class Attribute { public const string Class = "class"; public const string Style = "style"; } }
While I can get behind
GetBeginTag
, since it does the string building stuff, and maybeGetEndTag
andGetTag
make the code a bit cleaner, the rest is just... urk.
-
Booo, they spelled "style" correctly.
-
```
public const string HtmlRowTagIdAttribute = "id";
public const string HtmlRowTagClassAttribute = "class";
public const string HtmlRowTagStyleAttribute = "stlye";Fuck me. That's literally the worst thing ever. **EDIT:** If I met the person who wrote this code I would literally punch them in the face and tell them to stop programming.
-
I'm still waiting for something like this, but with each string localized, to pop up here. Somebody must have done that.
Filed under: Only tested under en_US!
-
To be the devil's advocate, in C# land this allows you to easily answer questions like "where am I using
td
tag?"
Also, if a need arises, you can extend these simple consts into properties that might allow you to, for example, push out uppercase or lowercase tags or some shit like that.That said, I'd still go with just strings unless I had a REALLY good reason otherwise.
-
push out uppercase or lowercase tags or some shit like that.
"where am I using td tag?"
And that would be useful because...?
-
-
-
You really want that shit on a higher level though. Have a table object, an image object, etc... by the time you're serializing to HTML there's no reason not to hardcode.
-
Huh.
The best thing about this code is that it's actually used to generate an
.xls
file... well, TIL Excel will open a HTML file containing a<table>
and even parse it correctly (albeit with a "wrong format" warning).
-
And that would be useful because...?
The only reason I can think of is using the constant in several places in the code, so there's only one string instance. However, IIRC, the C# compiler finds all occurrences of string literals, and de-dupes them automatically, which renders the whole exercise pointless.So, yeah, it's not useful at all.
-
I've heard that for a long time our 'excel export' was a CSV file with an
.xls
extension. Excel would open this correctly and without warnings.
-
To be the devil's advocate, in C# land this allows you to easily answer questions like "where am I using td tag?"
Why would you ever care about the TD tag specifically? (I could see asking, "where am I using tables?"
-
The only situation I can think of is using JS to live-update totals for an invoice (or a similar task). But then, if you're doing that, you should be using CSS classes in the form fields themselves, and iterating over them, not rooting through a multitude of
<td>
s.
-
public const string HtmlRowTagIdAttribute = "id";
public const string HtmlRowTagClassAttribute = "class";
public const string HtmlRowTagStyleAttribute = "stlye";This is literally the worst. What are they even thinking? Constants are supposed to be in all-caps.
-
-
The only situation I can think of is using JS to live-update totals for an invoice (or a similar task).
But but but... but the search is in the C# code. He even says "in C# land" in his sentence.
-
But but but... but the search is in the C# code. He even says "in C# land" in his sentence.
Well, yes; doesn't change my point that looping through the<td>
s in stupid.
-
And that would be useful because...?
Why would you ever care about the TD tag specifically? (I could see asking, "where am I using tables?"
Just an example. The point is, there's advantage to having things properly typed instead of strings.
You really want that shit on a higher level though. Have a table object, an image object, etc... by the time you're serializing to HTML there's no reason not to hardcode.
Fair enough. I guess it depends on how fancy you want to get.
C:\codez> grep ""td"" *.cs?
//total distance var td = distance * count;
Oops.
-
@tar said:
C:\codez> grep ""td"" *.cs?
//total distance var td = distance * count;
Oops.
Nuh-uh. What do you think the
\"
and\"
are for?(Tested on Windows, COMPLAINS!)
-
Fair enough. I guess it depends on how fancy you want to get.
There's cases where it's useful. An advantage of building objects first is that you can add components to containers before they are fully populated.
Hardcoding entirely has its place as well. Softcoding tag names is absurd.
-
Just an example. The point is, there's advantage to having things properly typed instead of strings.
Right; but C# has a XML/XHTML builder in its standard library which is already properly typed, so there's still no reason to do this asshattery.
-
IIRC, there are in fact two such APIs; one in
System.Xml
, the other inSystem.Xml.Linq
(orSystem.Linq.Xml
; I forget which way round it is).
-
I've heard that for a long time our 'excel export' was a CSV file with an
.xls
extension. Excel would open this correctly and without warnings.Are you sure? For
.csv
files that are indeed comma separated, Excel doesn't recognizes the columns, because it expects semicolon separated values.
-
That depends on your locale (specifically, decimal separator). Of course there are apps which won't realize that and will happily shit over your data with commas in both roles (*cough* fuck you NVidia Profiler*cough*)
-
TIL Excel will open a HTML file containing a <table> and even parse it correctly (albeit with a "wrong format" warning).
I support systems that do "excel exports" using this and older versions didn't give the wrong format warning. When the customer upgraded to a version that did there were some unfun meeting trying to explain why they were now getting the warnings and what it would take to fix.
-
Quite possibly semicolons. I've only got it from hearsay - it wasn't a 'real' excel sheet. May well have been @locallunatic's table tags too.
-
Oh wow, so Excel is "smart" enough to know that in Hungarian, comma is a decimal separator, so if I find a CSV anywhere on the internet, it surely can't be comma separated :)
-
IIRC there's some place in excel where you can fiddle with the parameters for the
.csv
import
-
AFAIK, that's only on import. On open you're stuck with the defaults.
-
probably, it's been years since i used excel to do any csv related work
-
-
It ain't too bad if you control the .csv, and spitting out .csv is probably the easiest way to quickly get an Excel sheet from a script or so. If you don't, well, better start praying...
-
.csv is probably the easiest way to quickly get an Excel sheet from a script or so.
I like scripting languages that can write .xls(x) directly.
-
-
easiest way to quickly get an Excel
Modern Excel tends to import HTML rather well ... dump it as a basic HTML table structure and it should import fine.