Subject: Re: VOLUNTEER REQUEST
From: BWS - Offwhite (brennan@offwhite.net)
Date: Thu Aug 10 2000 - 23:39:46 EDT
[ this is simply an idea up for suggestion ]
I agree that the data should be structured and even stored in a
database. That way we can use templates to display the content. An FAQ
may constist of the following structure.
- psuedo sql
TABLE faqinfo,
id int primary key,
question text,
answer text,
category int,
rank int
Then a nice FAQ could be built dynamically with a script which accesses
the database. If there are only 20 questions in the system, they would
appear on the same page. If it gets to be much longer, it could display
20 per page. And then we can organize questions by category: file server,
print server, installing, and trouble shooting.
Other content could be organized in much the same way. The way I have
built the OnMilwaukee.com site, I allow basic html in the articles
system. If the author wants to bold some text or make a link she can do
that. If she wants to embed a table she can do that too, she just has to
understand html. All I require is that they put a start and ending <P>
tag around all paragraphs.
If the documentation is to be organized into a sort of book-like structure
with chapters and sections, we could then design the database to handle
that. A page would be assigned to a chapter and then a section of that
chapter. I would not go so far as too partition out sub-sections.
Then a doc page would be recorded as...
TABLE docpage
id int primary key,
chapter int,
section int,
title varchar(100),
credits varchar(255), (optional)
page text,
keywords varchar(200)
Then the table contents would be automatically built along with a nice
index with all of the keywords linking to the related sections.
As for fonts and such, I have decided to let style sheets do all of the
work. I define the font and size for the <P> tag and other tags and place
globs of text inside with a font tag... <font class=normal>. That way I
can classify the normal/default font that I wont on the entire site and if
the given browser does not support CSS, that is fine, they simply get the
default browser font. But these days only Lynx and very old browsers
don't do the nice CSS enhancements. The CSS markup is nice, but not
totally necessary.
There are other gobs of data which would also go on this site, like a list
of developers, documentation admins, webmin developers and such and a
database for those names could be created as well.
After all these databases are created a back office could be created with
a web interface to edit all of the data. I do this all of the time and
would be happy to help. I use perl and mysql to do this. I am not sure
how easy it is for PHP to do this same thing, but I find the CGI module in
perl helps me insert content into forms seamlessly.
Then as far as the display goes, it can work in just about any form. It
could be outputted inside a site template for normal display and print
display. The documentation and FAQ can be displayed as multiple pages or
as one very long page so it can be downloaded for home reference. Someone
could also create a script which generates all these pages in static form
based on a template and run that nightly. That way the site is dynamic
and static, easy to mirror.
There are just so many options with a database and a couple creative
scripters.
I would love to be involved in developing this.
Brennan Stehling - web developer and sys admin
projects: www.greasydaemon.com | www.onmilwaukee.com | www.sncalumni.com
On Fri, 11 Aug 2000, John L Grantham wrote:
> At 5:25 pm -0500 10/8/00, BWS - Offwhite wrote:
> >As for PHP, Perl or whatever, it would be great if that could be
> >hidden. I do this site...
> >
> >http://www.onmilwaukee.com/
> >
> >I try my best to hide all scripts. All dynamic content is included via
> >SSI's and made fast with mod_perl, yet the documents all say
> >xyz.html. That way any site which mirrors the main site does not have to
> >worry about it. They can display html documents already, and do not need
> >to worry about setting up .php or .ehtml pages.
> >
> >I could help set this up. I do this kind of work for a living.
>
> Some comments:
>
> The sites I do basically rely on PHP to do dynamic content for the
> main reason of supporting as many browsers directly as possible. This
> means that, instead of using lowest-common-denominator HTML, we can
> use scalable HTML that reacts to the remote client according to its
> HTTP_USER_AGENT and other environment variables.
>
> For example, setting font sizes and families works well this way,
> because we can therefore use CSS in those browsers that support it
> while using other tags (<FONT></FONT> for example) in those that
> don't. This also makes for cleaner HTML for each and every browser,
> without junk that the particular browser doesn't understand.
>
> I know some people will holler that fonts aren't important or that
> they override the settings anyway, but for the vast majority of
> users, font settings can help quite a lot in making the page more
> legible (for example, don't use Times -- other sans-serif fonts are
> more legible on the screen and don't look so broken -- but Times is
> nearly always the default, which is why I always try to set another
> font).
>
> Further, the sites I build are constructed in such a way that the
> central template(s) are separated from the content, allowing the
> content to be reused or regenerated in another format pretty easily.
>
> It would be possible, though, to write a PHP-based HTML parser such
> that the PHP engine reads a normal, plain-vanilla HTML file (i.e.
> nothing but straight <P></P> and <Hn></Hn> tags, perhaps also <B></B>
> and <I></I>) and converts it to the template on-the-fly. Thus one
> could easily mirror the HTML version while keeping a dynamic version
> at the ready. Another option would be to have the content in some
> standard format, like XML or DocBook, and parse that instead.
>
> It also depends on how you intend to mirror the pages. A mirror via
> HTTP requests would work even with PHP-based dynamic content, so long
> as there is a 1:1 relationship between PHP pages and "real" URL pages
> (i.e. don't use query strings and database-controlled content).
>
> The further concern I have about straight HTML is that it's all too
> easy for plain HTML pages to go haywire over time, especially once
> people start trying to edit them using [insert WYSIWYG editor name
> here]. Some people's idea of HTML is radically different from others,
> which results in crappy HTML over time (raising the risk of
> bad-looking or buggy pages later). For example, some people like to
> omit </P>, </TR> or </TD> tags, since they in theory aren't needed,
> but that causes problems with many browsers. Using a standardized
> template solves that by having a unified way of making pages.
>
> Hope that all makes sense,
>
> John
> --
>
> John Grantham | Dipl.-Designer (FH)
> | Homepage http://design.macnews.de/
> | Linux for PPC: http://linuxppc.org/
>
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:31:57 EST