Re: [Lcd4linux-devel] manpage for lcd4linux

[Martin H. <ma...@he...>]

Hi Xavier, hi Michael,

Ok, I'll play devel's advocate here. Don't take this personally, I just 
want to offer a second opinion.

>>- what are the benefits? (besides from being 'hip', which doesn't count 
>>for me)
> 
> There are a lot :
> - using databases (for example to keep a table of porting status without
> rewriting HTML page, just modifying the sql table) (another example :
> news on front page).
The same is true for for ASP and plain CGI

> - dynamic generation of pages
The same is true for ASP and CGI

> - easy include system : for zwe, the concept is simple : the new page
the same is true for ASP, CGI and SSI

> includes a php include, has the article in XHTML and call function to
> insert headers, menus, images, code frames, links, ...
Again, plain ASP and CGI can do that as well

> The advantage of this, it for example that you can modify you menu or
> add 'general' links easilly without rewriting all the pages of using
> "deprecated" frames.
That's the nature of dynamically generated content, I guess - m4 can do 
that very well too (for static pages)

> - cool things : display a little box with last version, web-interface
> news system, ...
If you implement those things, I guess you're already implementing some 
kind of "content management system". Nothing bad at all, but probably 
not a feature of PHP itself, but rather one you added with your coding 
(and may I say, content management systems existe with plain CGI too).

All of the above is also true for ASP, and I avoid it like the plague 
(for various reasons). So why should we go for PHP, instead of plain 
HTML, or docbook (and pages generated on demand) or m4 (I run one site 
that's mainly static, which is generated using m4)?

I'd say the one strong point for PHP is that SF offers it on their 
servers (which isn't true for ASP and also SSI, at least I think so).

Don't get me wrong, I don't have anything against PHP per se - but I'm 
always wary if things are mainly done for reasons that sound like they 
came from some feature list written up by some marketing department.

And while we're at it - when it comes to easily editing the pages (by 
several people), why not go with a content management system like 
PHP-Website (which is what leaf.sourceforge.net runs, for example)? It 
has a learning curve, but probably less so than coding directly in PHP. 
And the project leader at LEAF has pretty good connections to the PHP- 
Website crew, so getting help should not be a problem.

>>- what are the drawbacks?
> 
> Just one, it's one more language to learn ! But it's the same base
> syntax as C and Perl, so no high learning price.
> Another drawback was that at the beginning php wasn't supported by all
> hosters, but now it's supported everywhere :)
Well, I would like to add to that the fact that it's somewhat slow (not 
PHP itself, but it surely is slow on most sourceforge servers I've seen)

>> From my side, I have two opinions: basically I don't care wheter the 
>>website is made of HTML, Flash, Java, PHP, Perl, VisualBasic (ok, remove 
>>that one) as long as it looks cool, renders correct, isn't full-bloated, 
>>and is up to date.
> 
> Believe me, PHP generates HTML code, so it isn't heavier than pure
>   HTML. I really dislike flash and JS. The only 'overload' is on the
>  server, but don't worry.
Well, but nobody would ever edit the HTML code generated by PHP, so 
what's your point? I mean, to me, PHP is a means to generate HTML - 
which is fundamentally different from HTML itself. I'm surely not 
proficient in PHP (and I don't plan to be any time soon), and I know 
that one can use inline HTML in PHP (or at least, I recall that being a 
possibiliy), but that surely doesn't equate to HTML itself. Again, I 
don't mean to put PHP down, I'd just like to keep the facts straight.

>>OTOH, if I am to keep it up to date or if I should assist in maintaining 
>>it, it should be bare HTML, 'cause it's the only web language I'm able 
>>to read and write. I don't even know CSS (I've seen it, and I disliked 
>>it, because I did not understand it :-)
> 
> In fact, you write your pages in HTML, but you include a file and call
> PHP functions to help to format (and insert common tags). CSS looks
> strange at first sight, but it can really produce good looking sites.
Well, being a big fan of CSS myself, I'd agree, even though that's 
probably not one of the main reasons to use CSS - to me, the main reason 
is that it enables the developer to separate content and appearance, 
which is always a nice thing. In short, you code your webpage specifying 
what kind of data the tags represent, and the CSS is in charge of 
specifying how that data looks like. Separating data from appearance can 
make maintenance of a web-page much easier (you specify _once_ how 
things should look like, as opposed to with every change).

One nice side-effect of CSS is that (if properly used) the page renders 
well on all standards compliant browsers, without too much experimenting.

>>So, change it to PHP or CSS or both if you think it's good, but PLEASE 
>>do not handover the maintenance to me after a couple of weeks...
> 
> In the better dreams, once I have finished the coding, we could write
> the help pages in docbook and then modify them a bit to include them in
> the site. I've already designed 4 sites with zwe and derivated works,
> but they are all in tuxfamily servers, which are down :/
Which of course would mean that you'd be the sole person in charge of 
keeping the page up to date (at least the "infrastructure" behind it - 
I'm not talking about some "what's new" item that's parsed by PHP 
scripts) - are you aware of that, and willing to commit to that? I mean 
even during holiday seasons, finals season or whatever other time it you 
might have other things on your hands (as we all do from time to time), 
if Michael decides to push out a new release? To me, it's always been a 
bad idea to put the burden of keeping a web-page up to date on the 
shoulders of one single person.

Again, don't get me wrong - I don't have a problem with PHP per se (even 
though I will surely not read up to get up to speed with how it works),

I just wanted to put give a second opinion (and granted, a very negative 
one), based on my experience with other projects, where people have 
promised to take over maintenance of a web-page (the technology itself 
is rather irrelevant, actually) - in all those projects, this concept 
didn't go well in the long term. It's usually a good idea to use the 
skills of several people in the team, rather than rely on one single 
person to do everything that's needed for a certain task.

Hopefully, this won't trigger a flamewar (I guess things like "PHP is 
better/worse than..." tend to do so).

Martin