PHP to run GGL.o
Hi everyone,
I'm finally making some progress on the transition to DocBook - so now it's time to think about how to structure the content of GetGNULinux.org. The trick is to build each GGL page based on a core series of DocBook files.
Each page on GGL is structured as pictured in the file attached. There are six bits of information to put together.
1. HTML code header
Declaration, page title, link to CSS files, etc. Normally this should be generated by the program exporting DocBook into XHTML.
2. Translation "tabs" (flags top right of page)
This is by far the trickiest. Ideally the flags should not be integrated into the DocBook file.
We must pick up the code corresponding the the page displayed (say, the About page), so that the links to all translations are displayed. The tabs are the same on each translation of a given page. This could be done with a database.
Then we must "filter" the code, so that the tab for the current language is "highlighted" by adding an HTML tag.
3. Header picture (the pic with blue background)
Easy. Just find and display a "headerpic.php" file common to all the site
4. Menu
Find and display a "menu.php" file common to all the site;
"Filter" the content so that the current section is "highlighted" by adding an HTML tag.
5. Page content
Generated by the program exporting DocBook to XHMTL
5. Footer
Find and display a "footer.php" file common to all the site.
I have no idea how to pick up the correct translation flags for each page, dynamically. I don't know how to do the "filtering" either. So any hint/suggestion would be welcome.
Currently my idea of a given page would look like
<head>
stuff generated from DocBook file
</head>
Get_a_header_php_file that does:
{
Get_the_translation_tabs for the given page
Find language of given page and highlight tab
get headerpic.php
get menu.php
Find section the current page belongs to and highlight it
}
Content of page, generated from DocBook
get_a_footer.php file
I have little experience in this, does this sound sensible?
Thanks
Olivier.
| Attachment | Size |
|---|---|
| rect2160.png | 37.2 KB |
Hi!
I honestly don't think we need PHP: We should only use PHP and databases to handle dynamic data, since they both would slow down our websites.
1. HTML code header
Declaration, page title, link to CSS files, etc. Normally this should be generated by the program exporting DocBook into XHTML.
Ok.
2. Translation "tabs" (flags top right of page)
This is by far the trickiest. Ideally the flags should not be integrated into the DocBook file.
We must pick up the code corresponding the the page displayed (say, the About page), so that the links to all translations are displayed. The tabs are the same on each translation of a given page. This could be done with a database.
Then we must "filter" the code, so that the tab for the current language is "highlighted" by adding an HTML tag.
We can/should make that in XML, which means extending DocBook.
3. Header picture (the pic with blue background)
Easy. Just find and display a "headerpic.php" file common to all the site
It's easy, but the image is not something generated dynamically.
4. Menu
Find and display a "menu.php" file common to all the site;
"Filter" the content so that the current section is "highlighted" by adding an HTML tag.
I guess we can do that easily within the XSTL stylesheet, without PHP, but I don't know how to do so.
5. Page content
Generated by the program exporting DocBook to XHMTL
Ok.
5. Footer
Find and display a "footer.php" file common to all the site.
It isn't dynamic content.
I have no idea how to pick up the correct translation flags for each page, dynamically. I don't know how to do the "filtering" either. So any hint/suggestion would be welcome.
In PHP, you might assign an identifier to each file, then make a script to display the contents of every page.
Currently my idea of a given page would look like
<head>stuff generated from DocBook file
</head>
Get_a_header_php_file that does:
{
Get_the_translation_tabs for the given page
Find language of given page and highlight tab
get headerpic.php
get menu.php
Find section the current page belongs to and highlight it
}
Content of page, generated from DocBook
get_a_footer.php file
The structure is alright, but I insist we should not use PHP.
DocBook:
+ Is easy to manage (edit, translate, transform into other formats).
+ is static, so the websites will run as fast as they are at this moment.
- is harder to setup.
PHP, on the contrary:
- Is hard to manage (edit, translate, transform into other formats).
- is dynamic, so the websites would run slower.
+ is easier to setup.
Indeed we can do what you suggest using PHP and it would be the easiest and quickest solution, in the short-term. However, I think this is not something urgent, so I think we should do the transition to DocBook only, even if it requires much more time than using PHP from the beginning... This would be the best solution in the long-term.
Cheers!
Hi Gustavo!
I understand that it's possible to handle it all through DocBook, but I think we have to use PHP in this case.
The objective is to separate content from presentation, right? So we (including and especially translators) can edit the text without worrying about the rest.
When you think of it, the menu, footer and translation flags are not part of the interesting content of the page. It's something that wouldn't be part of a PDF version for example.
More to the point, these elements shouldn't be part of the DocBook file because it helps tremendously to manage them dynamically. Ex:
+ To change the footer: modify only one file
+ To add a translation: no need to modify strictly every page of every website carefully (this is getting really tiresome with 5 languages now... 120+ pages)
+ Keep all of the clutter (repetitive stuff: header picture, menu) out of the way for translators
As for the speed of the websites, maybe we can do some caching. There must be a way to do this quickly. Maybe this summer I can get a company (I've got one in mind specifically but it's still a secret ;-)) to provide very fast hosting for us, as a form of (not link-based) sponsorship.
So in short, I'm looking at DocBook for content, and PHP for management - so we can all spend less time editing.
Olivier.
Hi, Olivier!
When you think of it, the menu, footer and translation flags are not part of the interesting content of the page. It's something that wouldn't be part of a PDF version for example.
DocBook was especially created with these situations in mind. This would be very easily handle with DocBook.
However, when we distribute GGL in PDF, we might want to put a link to the lastest online version of each section in the PDF. We might also want to use the same navigation bar, but with links poiting to sections inside the PDF. We might also want to reuse the translation flags in the PDF. If we change our minds at any moment, DocBook would be our super-hero, while PHP would a pain in you know where.
More to the point, these elements shouldn't be part of the DocBook file because it helps tremendously to manage them dynamically. Ex:
+ To change the footer: modify only one file
+ To add a translation: no need to modify strictly every page of every website carefully (this is getting really tiresome with 5 languages now... 120+ pages)
+ Keep all of the clutter (repetitive stuff: header picture, menu) out of the way for translators
If you want to modify the footer, add a translation of GGL or avoid redundant code in DocBook, it's a piece of cake: You only have to modify a single file, too. Better yet, unlike PHP, translators won't have to deal with programming languages (they might introduce security flaws if they do something wrong).
As for the speed of the websites, maybe we can do some caching.
Yes, that would help a lot.
There must be a way to do this quickly. Maybe this summer I can get a company (I've got one in mind specifically but it's still a secret ;-)) to provide very fast hosting for us, as a form of (not link-based) sponsorship.
Great! This summer would be great, as I'd have more time for the migration. Perhaps a VPS hosting is best suitable for us in the middle-term.
Cheers!
While I barely know anything about docbook and only enough about PHP to do small modifications on as-needed basis I know that there are some scripts which convert the given page immediately into PDF so when someone clicks on your PDF link they get to download the PDF version of the web page they are viewing, therefore fully up to date.
This would save you the trouble of having to manually update your PDFs.
There are some such scripts here. Some of them are proprietary but there are a few free solutions which could work, like PDFHack, TCPDF, HTML_ToPDF and pdfTag.
Hi, Libervisco!
Thanks for the links.
The problem about those scripts is that one have to run them once for every web page and in the end, we'll only have independent PDFs. If we wanted to get a single PDF, we'd have to put getgnulinux.org in a single web page.
Cheers!
OK I see what you mean Gustavo. When I'll be able to generate all of a page through DocBook I'll be back on this to see how we can make it work.
Alright! I'll be learning the basic of XSLT, the technology we must use to get the most out of DocBook (or any XML-based language).
Cheers!