Topic: XML/HTML Implementation Question. (Page 1 of 1) $Pages that link to <a href="https://ozoneasylum.com/backlink?for=10720" title="Pages that link to Topic: XML/HTML Implementation Question. (Page 1 of 1)" rel="nofollow" >Topic: XML/HTML Implementation Question. <span class="small">(Page 1 of 1)</span>\$

jiblet Paranoid (IV) Inmate From: Minneapolis, MN, USA Insane since: May 2000	posted 04-22-2002 18:03 Okay, so as some of you may remember, I'm working on a customized CMS for my sites here at the University of Minnesota. While most of the information will remain in HTML/PHP form, the meta information that the system itself uses will be in XML. This is my first foray into XML, and I am very concerned with doing things the 'right' way. I still am not sure whether technologies like XPath or SOAP will be necessary, but I want to stick with established methodologies wherever they fit. The data I store in XML format will not be any content, but strictly configuration information for the CMS. My question to you XML gurus is this: Is it appropriate to embed XML information in the <HEAD> of an HTML document? Or should it be in a separate file? It would be simpler (and more portable) to keep each pages individual meta information in the header, but that strikes me as not being a well-formed XML document (particularly since the HTML files in question aren't even XHTML). -jiblet
InI Paranoid (IV) Mad Scientist From: Somewhere over the rainbow Insane since: Mar 2001	posted 04-23-2002 17:17 The poster has demanded we remove all his contributions, less he takes legal action. We have done so. Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future. Don't follow his example - seek real life help first.
Emperor Maniac (V) Mad Scientist with Finglongers From: Cell 53, East Wing Insane since: Jul 2001	posted 04-24-2002 17:42 jiblet: You might want to explain what you are planning in more detail - InI is right and I would probably only use XML in this context for transferring data into or out of my site (using PHP to grab it, slice it and store it or to write it for export). Emps
jiblet Paranoid (IV) Inmate From: Minneapolis, MN, USA Insane since: May 2000	posted 04-24-2002 19:10 Yeah, see, I understand the general purpose of XML for abstracting data for use in multiple applications. In fact, I am working on an RSS channel for the schools MetaDot portal. In this context the tutorials are very helpful and XML itself is quite intuitive. To start from the beginning. My content management system is not so much about publishing information from alternate sources or providing information in a re-useable manner. Rather it is about easing site production and maintenance. In a nutshell, I am trying to automate the aspects of production that have plagued me in the past 2 years developing and maintaining a 300-page site single-handedly. Because there's no telling how the next site I have to build will be structured, a regular content management system doesn't offer the flexibility to be much use to me. My system will server three basic purposes: A nested two-dimensional templating system that allows any page to easily be viewed in text-only/printable/browser-specific modes as well as unique templates for each site. Althought the majority of templating information can be gleaned from the directory structure, exceptions will need to be made on a per-site basis (eg. which pages of a site should be included in the navbar, or which sites even HAVE a navbar). This meta-information will need to be stored somewhere. Re-useable modules which generate standardly formatted output using an individual site's specific data. So, for example, there may be an "Business Hours" module that appears on our various retail sites. It's the same INCLUDE file for every site, but it uses site-specific data to generate the appropriate hours listings for the current date (there may be 20 different schedules for a business unit at a University throughout the year). Although my implementation will generally involve a database, I feel like the data should also be stored in human-readable format and not dependent on the entire system (in case someone wanted to check the data out of context). It will also be easier to migrate the system to different databases and/or languages. Automated Site Maintenance, such as checking for unique META and TITLE tags for each page, performing translations of standard html elements that are easily produced by hand into obtuse presentation-related bug fixes (eg. <h1> -> <div class="header1"> ), notifying the web manager of necessary updates, etc. There are many more aspects to the site maintenance portion, but the point is it will require meta-data such as expiration dates for pages, and various flags related to what transformations should be performed in what contexts, etc. Again the database will exist, but the basis of the information should be stored in XML for easy accessibility. That is probably way more than you want to know about such a proprietary system in such early stages of development, but that is the basis of my question. Is it better to store snippets of XML in each page's <HEAD> or is it best to have, say, one 'data.xml' file in each site's directory that stores not only the overall site's data, but also contains a hierarchy representing each page in the site to contain page-specific information. -jiblet
Emperor Maniac (V) Mad Scientist with Finglongers From: Cell 53, East Wing Insane since: Jul 2001	posted 04-24-2002 20:35 jiblet: I've not tried it but I would be concerned that dropping XML into the head might cause things like NS4.x problems. I'd see what the others say but I'd go with storing an XML file in the directory. I would also caution against getting rid of <H1> in favour of a <DIV> based solution. I would also say that I suspect most of what you want could be achieved through a PHP/MySQL solution. I use a simple script which chops up the URL and delivers content (TITLE tags, navigation, etc.) according to the section, page you are on and a more complex globally included file could, with some work, do what you want. However, you've given this considerably more thought than I have and you've probably been through solutions like this and found that the XML way is the best way. All very interesting by the way I hope you'll keep us updated on your progress. Emps
jiblet Paranoid (IV) Inmate From: Minneapolis, MN, USA Insane since: May 2000	posted 04-25-2002 00:11 The more I think about it, the more I am convinced that a single XML file per directory is the way to go. Actually, you are right, XML does not any functionality over what could be done with PHP/MySQL. In fact, the XML will be parsed and dumped into a database. The reason I want XML is because I want to be able to view all the site-specific data at a glance and have the flexibility to modify it without creating complex queries and mucking around in PHPmyAdmin (because the normalized DB will have all kinds of foreign keys, even with MyAdmin queries will still need to be crafted to identify which entries in which tables pertain to which directories). Also, the concept of being able to FTP the entire site, meta-information and all without losing anything is attractive. As I get further into the project, however, I may discover that the complexities of syncing up from XML are more trouble than they're worth and move everything into MySQL. As for your warning about doing away with <h1> tags, have no fear, that transformation will only occur for specific graphical browsers that the site supports. Unknown user-agents will get a more vanilla page that is guaranteed to display correctly (if not beautifully) in any browser. It's really just an alternative using negative margins and loading 3 stylesheets which I never felt quite right about. Anyway, you can be sure i'll keep you updated on this. The framework of the templating/module/transformation system will all be released as open source once I get it to a generally useful form. -jiblet
InI Paranoid (IV) Mad Scientist From: Somewhere over the rainbow Insane since: Mar 2001	posted 04-25-2002 08:44 The poster has demanded we remove all his contributions, less he takes legal action. We have done so. Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future. Don't follow his example - seek real life help first.
jiblet Paranoid (IV) Inmate From: Minneapolis, MN, USA Insane since: May 2000	posted 04-25-2002 18:19 Yeah. I guess it remains to be seen whether XML really adds enough value to my application to be worth dealing with the extra implementation time (although thanks to XML parsers it shouldn't be all that much trouble). At any rate, it will be good experience to develop my own XML application so I can better understand design decisions in XML apps that I may use in the future (like RSS). -jiblet

Topic: XML/HTML Implementation Question. (Page 1 of 1) $Pages that link to <a href="https://ozoneasylum.com/backlink?for=10720" title="Pages that link to Topic: XML/HTML Implementation Question. (Page 1 of 1)" rel="nofollow" >Topic: XML/HTML Implementation Question. <span class="small">(Page 1 of 1)</span>\$

jiblet
Paranoid (IV) Inmate

From: Minneapolis, MN, USA
Insane since: May 2000

posted 04-22-2002 18:03

Okay, so as some of you may remember, I'm working on a customized CMS for my sites here at the University of Minnesota. While most of the information will remain in HTML/PHP form, the meta information that the system itself uses will be in XML.

This is my first foray into XML, and I am very concerned with doing things the 'right' way. I still am not sure whether technologies like XPath or SOAP will be necessary, but I want to stick with established methodologies wherever they fit. The data I store in XML format will not be any content, but strictly configuration information for the CMS. My question to you XML gurus is this:

Is it appropriate to embed XML information in the <HEAD> of an HTML document? Or should it be in a separate file? It would be simpler (and more portable) to keep each pages individual meta information in the header, but that strikes me as not being a well-formed XML document (particularly since the HTML files in question aren't even XHTML).

-jiblet

InI
Paranoid (IV) Mad Scientist

From: Somewhere over the rainbow
Insane since: Mar 2001

posted 04-23-2002 17:17

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Emperor
Maniac (V) Mad Scientist with Finglongers

From: Cell 53, East Wing
Insane since: Jul 2001

posted 04-24-2002 17:42

jiblet: You might want to explain what you are planning in more detail - InI is right and I would probably only use XML in this context for transferring data into or out of my site (using PHP to grab it, slice it and store it or to write it for export).

Emps

jiblet
Paranoid (IV) Inmate

From: Minneapolis, MN, USA
Insane since: May 2000

posted 04-24-2002 19:10

Yeah, see, I understand the general purpose of XML for abstracting data for use in multiple applications. In fact, I am working on an RSS channel for the schools MetaDot portal. In this context the tutorials are very helpful and XML itself is quite intuitive.

To start from the beginning. My content management system is not so much about publishing information from alternate sources or providing information in a re-useable manner. Rather it is about easing site production and maintenance. In a nutshell, I am trying to automate the aspects of production that have plagued me in the past 2 years developing and maintaining a 300-page site single-handedly. Because there's no telling how the next site I have to build will be structured, a regular content management system doesn't offer the flexibility to be much use to me.

My system will server three basic purposes:

A nested two-dimensional templating system that allows any page to easily be viewed in text-only/printable/browser-specific modes as well as unique templates for each site. Althought the majority of templating information can be gleaned from the directory structure, exceptions will need to be made on a per-site basis (eg. which pages of a site should be included in the navbar, or which sites even HAVE a navbar). This meta-information will need to be stored somewhere.
Re-useable modules which generate standardly formatted output using an individual site's specific data. So, for example, there may be an "Business Hours" module that appears on our various retail sites. It's the same INCLUDE file for every site, but it uses site-specific data to generate the appropriate hours listings for the current date (there may be 20 different schedules for a business unit at a University throughout the year). Although my implementation will generally involve a database, I feel like the data should also be stored in human-readable format and not dependent on the entire system (in case someone wanted to check the data out of context). It will also be easier to migrate the system to different databases and/or languages.
Automated Site Maintenance, such as checking for unique META and TITLE tags for each page, performing translations of standard html elements that are easily produced by hand into obtuse presentation-related bug fixes (eg. <h1> -> <div class="header1"> ), notifying the web manager of necessary updates, etc. There are many more aspects to the site maintenance portion, but the point is it will require meta-data such as expiration dates for pages, and various flags related to what transformations should be performed in what contexts, etc. Again the database will exist, but the basis of the information should be stored in XML for easy accessibility.

That is probably way more than you want to know about such a proprietary system in such early stages of development, but that is the basis of my question. Is it better to store snippets of XML in each page's <HEAD> or is it best to have, say, one 'data.xml' file in each site's directory that stores not only the overall site's data, but also contains a hierarchy representing each page in the site to contain page-specific information.

-jiblet

Emperor
Maniac (V) Mad Scientist with Finglongers

From: Cell 53, East Wing
Insane since: Jul 2001

posted 04-24-2002 20:35

jiblet: I've not tried it but I would be concerned that dropping XML into the head might cause things like NS4.x problems. I'd see what the others say but I'd go with storing an XML file in the directory.

I would also caution against getting rid of <H1> in favour of a <DIV> based solution.

I would also say that I suspect most of what you want could be achieved through a PHP/MySQL solution. I use a simple script which chops up the URL and delivers content (TITLE tags, navigation, etc.) according to the section, page you are on and a more complex globally included file could, with some work, do what you want. However, you've given this considerably more thought than I have and you've probably been through solutions like this and found that the XML way is the best way.

All very interesting by the way I hope you'll keep us updated on your progress.

Emps

jiblet
Paranoid (IV) Inmate

From: Minneapolis, MN, USA
Insane since: May 2000

posted 04-25-2002 00:11

The more I think about it, the more I am convinced that a single XML file per directory is the way to go.

Actually, you are right, XML does not any functionality over what could be done with PHP/MySQL. In fact, the XML will be parsed and dumped into a database. The reason I want XML is because I want to be able to view all the site-specific data at a glance and have the flexibility to modify it without creating complex queries and mucking around in PHPmyAdmin (because the normalized DB will have all kinds of foreign keys, even with MyAdmin queries will still need to be crafted to identify which entries in which tables pertain to which directories). Also, the concept of being able to FTP the entire site, meta-information and all without losing anything is attractive. As I get further into the project, however, I may discover that the complexities of syncing up from XML are more trouble than they're worth and move everything into MySQL.

As for your warning about doing away with <h1> tags, have no fear, that transformation will only occur for specific graphical browsers that the site supports. Unknown user-agents will get a more vanilla page that is guaranteed to display correctly (if not beautifully) in any browser. It's really just an alternative using negative margins and loading 3 stylesheets which I never felt quite right about.

Anyway, you can be sure i'll keep you updated on this. The framework of the templating/module/transformation system will all be released as open source once I get it to a generally useful form.

-jiblet

InI
Paranoid (IV) Mad Scientist

From: Somewhere over the rainbow
Insane since: Mar 2001

posted 04-25-2002 08:44

jiblet
Paranoid (IV) Inmate

From: Minneapolis, MN, USA
Insane since: May 2000

posted 04-25-2002 18:19

Yeah. I guess it remains to be seen whether XML really adds enough value to my application to be worth dealing with the extra implementation time (although thanks to XML parsers it shouldn't be all that much trouble).

At any rate, it will be good experience to develop my own XML application so I can better understand design decisions in XML apps that I may use in the future (like RSS).

-jiblet

Post Reply

Your User Name:
Your Password:
Login Options:	Remember Me On This Computer

Your Text: Insert Slimies » Insert UBB Code » Close Last Tag \| All Tags UBB Help	Loading...
Options:	Show Signature Enable Slimies Enable Linkwords

Topic: XML/HTML Implementation Question. (Page 1 of 1)

Insert Slimies »

Insert UBB Code »