On Tuesday 13 May 2003 04:55, Feng Xie wrote:
> Hi ! Jim
>
> Right now I am working on the glossary part of the static pages generation.
> Since I am not quite familiar with Java scripts, I have to look up things
> to undertand the concerning codes.
>
> Actually, I am testing my codes on the lab server, which is open to the
> web. This way, you can view the result anytime I make some changes. I don't
> why the server sent you a email, I didn't do that. If you get it next time,
> just ignore it.
>
> Best regards!
>
> Wayne
Hi Wayne!
For the most part, you should be able to take the code 1:1 from the existing
script. I don't yet see a need to include all of the Javascript in the pages
itself. It is only used for the popups and **if** someone wanted to have the
tutorial without a web server, then they have to do it without the popup.
What happens is that the code finds a word marked as a glossary entry. It
takes replaces it with the necessary code to call the java script popup, plus
make it a real link.
So this:
<glossary>UNIX</glossary>
gets turned into this:
<A class="glossary" HREF="/cgi-bin/display.pl?9998&15&474&0&3" TARGET=GLOSSARY
onMouseOver="return overlib('An operating system originally developed at Bell
Laboratories.', CAPTION, 'UNIX', FGCOLOR, '#F6E2B4',BGCOLOR, '#BDAA7B',
CAPCOLOR, 'WHITE', STATUS, 'Click me for more details');" onMouseOut="nd();"
target=NEW >UNIX</A>
The glossary term in this example is "UNIX". The existing code takes that word
and looks in the glossary.data file for the defitions and creates the
HREF-code. The java script code is from the overlib package which is a
library of "mouseover" functions. The definition for the term "UNIX" is "'An
operating system originally developed at Bell Laboratories", as you can see
in this example.
What I am trying to do is not necessarily create system by which you are
completely independent of the web server. Instead, I want to have a lot of
the information pre-processed before we put in on the internet. Each time a
glossary item is found the item needs to be parsed. Although the entire
glossary is in memory, the processing can be done in advance to save time.
Also keep in mind that we are working on a command and file glossary. That is,
there will be many other things on each page that need to be converted. Then
there will a number of things with different formating that we need to
convert. For example, the HTML source will contain tags like
<CommandExample>
. . . something here . . .
</CommandExample>
<ScreenOutput>
. . . something here . . .
</ScreenOutput>
which will both have special formatting. I don't want the writers to have to
deal with complex HTML, CSS, or whatever when they are writing. Instead, they
use very simple tags that the perl code converts. First, this is much easier
for the writers and second we don't need to change each page should we decide
on some other formatting, later on.
The next step is to store all of the Knowledge Units within the appropriate
page. Therefore, all of the pages will need to be processed at least once to
create the database and links. With all of this, there is a lot going on with
each page, so it makes sense to process so of it in advance. Some things like
the menus or the "Did You Know" entries should still be dynamic.
One of the biggest problems I am having is the perl code to take the XML data
source and create the database files. Several people have volunteered and
then several weeks later say they no longer have the time. It is already very
close to being done. Most of what is left is to store the data in arrays (I
can read the XML files with no problem) and then write the arrays out to the
files. I wrote all that myself and keep putting it off in the hopes that
someone will finish it for me. Any takers?
What I think we should do now in terms of the static code for the glossary is
define the actual mechanism of how the page is displayed. I think the best
thing is to a have a new window pop up. The link is something like
/cgi-bin/display_glossary.pl?word_to_define
where the display_glossary.pl simply creates the framework for the page and
inserts the contents of an already created glossary page. Something similar
would also be done for the command glossary and file glossary. The set of
glossary files could be in a seperate directory what the display_glossary.pl
knows about and knows what file to load based on "word_to_define".
Is this making sense?
I guess that's about it for now. I would appreaciate any comments so that we
can make sure that we are heading in the right direction.
Regards,
Jim
--
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info
|