Skip to main content
Welcome guest. | Register | Login | Post

PHP to run GGL.o

7 replies [Last post]
ariadacapo's picture
Offline
Joined: 2006-07-13

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.

AttachmentSize
rect2160.png37.2 KB
Gustavo's picture
Offline
Joined: 2006-09-11
PHP is not required

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.

ariadacapo wrote:

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.

ariadacapo wrote:

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.

ariadacapo wrote:

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.

ariadacapo wrote:

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.

ariadacapo wrote:

5. Page content
Generated by the program exporting DocBook to XHMTL

Ok.

ariadacapo wrote:

5. Footer
Find and display a "footer.php" file common to all the site.

It isn't dynamic content.

ariadacapo wrote:

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.

ariadacapo wrote:

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!

ariadacapo's picture
Offline
Joined: 2006-07-13
PHP for management

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.

Gustavo's picture
Offline
Joined: 2006-09-11
DocBook can do it all

Hi, Olivier!

ariadacapo wrote:

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.

ariadacapo wrote:

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).

ariadacapo wrote:

As for the speed of the websites, maybe we can do some caching.

Yes, that would help a lot.

ariadacapo wrote:

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!

libervisco's picture
Offline
Joined: 2006-05-04
While I barely know

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.

Gustavo's picture
Offline
Joined: 2006-09-11
Hi, Libervisco! Thanks for

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!

ariadacapo's picture
Offline
Joined: 2006-07-13
OK I see what you mean

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.

Gustavo's picture
Offline
Joined: 2006-09-11
Alright! I'll be learning

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!

Comment viewing options