|Still learning XML so I have a basic question|
| 12:04 am on Jan 6, 2009 (gmt 0)|
Although I've done my own websites for almost 15 years I avoided anything new for a period of time. Yes, I hand code and maintain thousands of static pages. Thank you for search and replace. But I just waste too much on it. I eventually went to CSS and now going to some basic XML.
Because I provide data files of my content for download, I don't really want to do duplicate work on them to make a nice looking spreadsheet. So I was thinking I could maybe use XML for my own web work and the files. I keep doing searches and reading on it but still don't know if what I want is possible.
Using Google Maps to point locations, I can load up a XML file and say to only show this category or that category. That works as I want. So if I can do it there...
Is there a way to do this on a normal HTML page? I know this gets into database type stuff that I've avoided learning over the years. But I'd like to just use one file to cover a few areas and then create pages that then references that data and only shows what is asked for. So I don't have to manually do it all. Thanks for any help on this.
| 2:43 pm on Jan 7, 2009 (gmt 0)|
Sounds like you have the zygote of a CMS.
1st option: XSLT
Given a large XML file full of content, you can show or hide sections of it using XSLT transformation, as long as the content blocks are identifiable by ID or attribute. This can be done at the client, or on the server.
2nd option: Parsing
if you have a server-side language available (PHP, C#, Java, ColdFusion, etc) then you can load the XML into a DOM object and deal with it on that level. Load the XML, use XPATH to find the section of content you want to show, and output that to the page.
3rd option: CSS
you can show or hide sections of content using CSS, provided the content is identifiable by ID or class name, using a CSS selector. Not a good idea since the user will download a huge page just to see one small part of it.
4th option: don't use XML
Get to know the database stuff you've avoided learning over the years. Storing and retrieving content using SQL is much easier and much more efficient than using XML files. You can suck your data into SQL, and use it as a single source for output as XML or HTML as required.
With a 15-year pedigree - older than Yahoo (by 1 year) and Netscape (almost) - I'm happy that you're stretching your legs and trying new things. Search-and-replace is a wonderful thing, but modern tools for manipulating data will save you amounts of time measurable in human lifetimes, I kid you not.
| 11:31 pm on Jan 7, 2009 (gmt 0)|
That's what I needed to hear. Frankly I've resisted so long because even when I'm getting 30,000 people a day my static website performs much faster than any XML or Database site that I've been able to find (of similar function). Every time I start going the more modern route, I find stuff that just crawls along. But if I can save myself time and work, I guess I'll sacrifice some site performance.
I have been looking at XSLT and the database issue. I've been able to teach myself most anything when I have something to see how it works. No matter how much reading I do, I think I need to find a working sample of it. If I can get access to a database and the website code pulling it off, I can then figure it out. But so far my searches yield a bunch of crap or junk. I may just have to buy an established website to learn it. If you have any suggestions on that, it would be great. Thanks!
| 5:44 am on Jan 8, 2009 (gmt 0)|
A static site will perform quickly, because it's just a plain disk I/O and instant delivery. But there are techniques for making dynamic sites super-quick, too. If your pages require intense data crunching and rendering, they can be pre-rendered and cached, which makes them just as fast as a static page -- sometimes faster since the cache is held in memory, not on disk.
No need to buy a cadaver site. Thanks to the Open Source revolution, you'll find TONS of sample applications online you can download and dissect - try browsing around Sourceforge, HotScripts, Google Code, and other repositories. And there are plenty of tutorials and blogs around explaining how to do just about everything you can imagine.
| 4:09 pm on Jan 8, 2009 (gmt 0)|
Thanks again httpwebwitch for helping me do something new. I found and used some of your previous posts on this to others as well.
No crunching. Just showing information and doing nothing. I knew that was why it was faster. It's always been hard to change because of not finding another site in the same industry that is as fast as mine. I played with XSLT and XPATH last night and got that working pretty well. Pretty easy stuff. What I don't like is that the main data on the page only shows as the named <div>. Is that the way it always is? I found demos that showed the final product with the data in the html. But even when I took their exact same demo files and did it myself, it still put it in the <div> and looked the same in the browser, not the same as the show file they use for the end. That's why I was wondering if I was missing something obvious or are they manipulating it.
I know I'm probably just paranoid about googlebot and rankings since this site is my life and income for ten years but I would prefer it to create and insert the html code it creates. I know it's there in the browser but not in the code itself with the otherwise similar page framework.
I weeded through a lot of junk and found a few good tutorials and samples. Seems like they always leave out some little detail that I have to solve myself. I spent a couple hours the other day solving a Google maps issue. I found dozens of people with the exact same issue but never found the complete answer. It was always 'here you go' links to their own blogs and incomplete answers that never worked. Drove me crazy. I solved it nearly by a typo accident with a partial line of code that no one ever mentioned. So now I feel like I have to watch for that question so I can just post the real answer to help another.
I can see using XSLT for some areas of the site. I think mySql will still be the best way in the end if I can take the time to do it.
| 12:23 am on Jan 9, 2009 (gmt 0)|
|I spent a couple hours the other day solving a Google maps issue. I found dozens of people with the exact same issue but never found the complete answer. It was always 'here you go' links to their own blogs and incomplete answers that never worked. Drove me crazy. I solved it nearly by a typo accident with a partial line of code that no one ever mentioned. So now I feel like I have to watch for that question so I can just post the real answer to help another. |
why don't you start a well-titled thread about your solution on a WebmasterWorld forum so the next person with that problem can easily find the solution?