Well, aside from the webcomic in my signature.
Well, aside from the webcomic in my signature.
I never used it except to play around with it a bit and think, "That's nice. I wonder if I'll ever have any real reason to use it?" ;)
But then, I hate XML: JSON all the way! :cool:
I just got pissed off at a hacked MySQL server, which is why I redid the webcomic. Maybe it's time to change it back--or just go with straight HTML.
Maybe Mongo or Solr?
Never heard of either of those.
Unknown to me..Thanks
PS: Oh, and don't forget SQLite for a RDBMS that does not require you install/use a separate, stand-alone database server.
XML Transforms -- in most all their uses -- much like XML as a database format is just a bloated wreck and disastrously bad idea. Human legible formats like XML are GREAT for data interchange BETWEEN database formats, but absolutely dreadfully inefficient when it comes to actual data procession.
... and no matter what the die-hard "XML for everything" nutters claim, XML exists to be a human legible format, NOT a machine readable one. I don't know where the blue blazes they got the idea that using plain english words in a markup style format is 'machine readable', but it shows that they don't know enough about 'machines' to be opening their traps on the subject. Are the integers and floats stored in bitpacked formats? Are the strings stored as RLL or null-terminated? No? THEN IT'S NOT MACHINE READABLE! (literally my right hand swings up ready to deliver a pimp slap every time a XML nutjob opens their yap on this subject).
Much like the now defunct XHTML 1.1/newer, XSLT was a bad idea put together by people who don't know enough about computers to be making 'standards' for them -- though admittedly I say the same thing about a LOT of recent technologies. They're all grossly inefficient, needlessly complicated, and actually make MORE work than older simpler formats... which is why I put JSON in the same category as XML for most data throughput...
But again, I'm the creepy bastard who's still using ASCII control codes or CSV for data transmission. Don't know why we need all the goofy complex crap like JSON and XML when we have perfectly good character codes for start of heading, start of text, end of text, end of medium, file separator, group separatior, record separator, unit separator... That thanks to every major character encoding being backwards compatible to ASCII7 work JUST FINE to this day.
Hell, the only time you should need to be passing field names is if you don't know the field names -- something that shouldn't be happening in the first place.
Oh, and mySQL got hacked? Lemme guess, still using mysql_ functions with no sanitation? .. and don't go completely back to flat HTML, just use PHP to glue parts together and leverage the filesystem, no SQL needed.
I'm increasingly starting to think that when it comes to databases, we're overusing them now for things where it's a total waste of code and time. Users, massive organized posts? Fine, makes sense... Static content on a site? Not so much.
my website take a second to show its text? Naaaaaaaaaaaaah, opening half a dozen XML files can't be the reason. 'Tis balderdash, bunkum, and billigswoggle. :D
*Checks out Coach Random webpage, realizes that the link is YEARS out of date. Whoops.*
But then again, I'm the same guy that had THIS for a root element start tag:
The XML prolog putting IE into quirks can't be helping much either :D
NOT that FF doesn't have a quirks mode too, despite what a lot of dev's claim:
Or the endless ID on everything and oddball use of numbered headings...
Oddball use of numbered headings?
*Owns up to using the ID attribute a lot.*
Oh, and when you say "static content on a site"--What if it's a HUGE webpage? (It's built from PHP+MySQL)
Oh, and before you make mention of it, class names such as 'class="DigoToggle DigoWingsBat DigoWingsButterfly DigoWingsClassic DigoWingsTricolour DigoWingsZZType Furre1GenSelectTriggering FurreAction ZZOtherAnystuff "' ARE required for this page to work.
Did you REALLY mean to say on this page:
That "The Strips", "Random Stuff" and "History" are subsections of "August 29, 2001 - April 23, 2004"? I kinda doubt it.
It might be more efficient to put that into simple arrays in a static include, than waste the overhead of a database on something that is not queried for anything more than "SELECT *"
... unless you're actually doing something more than what I'm seeing.
... but then 325k of markup for 134k of plaintext is usually a pretty good indication there's something awry with the markup; like endless pointless classes and ID's for nothing.
the online game Furcadia is updated and adds more lines. I suppose I could recreate the page from PHP+MySQL and reupload a flat HTML page every time Furcadia updates.
The IDs used with the checkbox inputs identify each criteria (and there's a hierarchy, thus the cumulative ID names. For example:
"DigoWingsButterfly" DigoWingsButterfly mean it's a Digo (a purchasable extra), DigoWingsButterfly means that this particular digo is of the Wing variety, and the whole thing means that they're butterfly wings.
Oh, and the commands 'class="DigoToggle DigoWingsBat DigoWingsButterfly DigoWingsClassic DigoWingsTricolour DigoWingsZZType Furre1GenSelectTriggering FurreAction ZZOtherAnystuff ' is used for?
- (0:274) When a furre turns on any wings,
- (0:374) When a furre turns off any wings,
Gotta catch 'em all.
Well, I suppose I could have gone with an AXIS or HEADERS attribute on a table header or table cell, but the end result would have been just as lengthy.
I invite you to poke around the page, see how the page works, and let me know how you would have done it. At least the people it was meant for (that being people working with DragonSpeak) liked it.
Oh, and one other thing.
First, would be the 'accessible' way, which would mean multiple page-loads and most of what you are doing being handled server-side, not client side. Frankly, I'd never build a single page that size in the first place; waste of bandwidth if the end user doesn't visit all the options. NORMALLY this would be what I'd advocate as a page SHOULD be made to work -- without scripting -- LONG before you EVER think about adding JS to a page.
That said, you've built an application, not a website -- and there is a difference.
That difference leads to my second approach; since none of your elements on the page are the least bit useful when scripting is disabled, I'd have generated 99%+ of your markup... from the script. Quite literally between your <body> and </body> If I was writing that page, the content would probably have looked like this:
EVERYTHING else on that page generated from the script. It would be far, FAR less code, and properly gracefully degrade. It would also mean you could store hooks to the generated elements (preferably built with DOM methods) in objects and arrays so you don't need any of those classes. That would speed up the page's responsiveness since you wouldn't have any getElementByxxx in there either.Code:
The Cross-Referenced Catalogue Of DragonSpeak Lines
Oh, and that 'view' popup has to be the most annoying thing ever. I'd try to find some alternative to that. Maybe at least modernize/center it with a lightbox type effect since it's current behavior results in buggy/broken/hard to use scrolling.
Really though a LOT of the data in there I'd be loading via AJAX; there's no point in sending client-side data they aren't actually viewing.