Re: [Lcd4linux-devel] manpage for lcd4linux

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

Hi Xavier,

I'm glad you didn't misunderstand my previous email.

>>>>- 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
> 
> ASP is a ***** with VB inside. I would better code my own web server
>  than using it.
LOL. I guess I disagree with your view on VB (since I make a living 
writing code in VB, at least when the job calls for something written in 
VB - just try to write some simple DTS scripts for SQL server with 
anything else, and you'll know what I mean).

> plain CGI is becoming outdated and harder than PHP. PHP is embedded
> within html, so it's easy to deploy.
I don't know how easy to deploy PHP is (since I've never used it), but I 
can't say that CGI scripts in perl are very hard to deploy (or even 
write) - that's another thing I do for my day-job, and I find writing 
and deploying perl CGI stuff rather straight forward. I also don't think 
that CGI is "outdated" - it surely isn't as "hip" as JSP or PHP, but 
then, I don't care much for hipness, when it comes to getting a job done 
(as you may have guessed, I don't work in marketing...).

But I guess that's pretty much beside the point of the discussion at 
hand here.

>>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)?
> 
> In fact, I propose to code a sort of 'content managing system', and then
> integrate docbook-generated docs. The advantage is for the maintainance
> (news, new pages, ...).
In that case, I fully agree with you.

>>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.
> 
> I'm not really sure to understand you. Is PHP-Website an online-editing
> CMS ?
I'm not sure what "online-editing CMS" would imply. With php-website, 
one can change the content by filling out HTML forms (which in turn get 
saved in a MySQL database, from which the actual pages are created) - if 
that's "online-editing", then yes, it is.

As I said, PHP-Website has some learning curve, but it's a nice tool to 
enable a large group of people to keep a page up to date.

> I don't think PHP produces a lot of lag. Maybe SF servers are
>   overloaded sometimes by bad-coded php pages ;) But this aspect can't
>  be a stopper.
Surely not.

>>>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.
> 
> You're not clear at this. But My vision is to use PHP to 'assist' page
>  writing : for 'normal' pages (not news or things like this), php is to
>  insert headers, menu and things like this, and provide link(), img(),
>  title() functions to avoid caring about which CSS class title use.
Ok - in that case, I misunderstood your previous statement. But wouldn't 
that mean that a change in the way a page looks would require a change 
in the PHP code (since it hides the details about CSS classes and so 
on)? Not that I hope we'd change the way the page looks like too often, 
but having to change code to change the appearance somewhat contradicts 
your point that "PHP generates HTML code, so it isn't heavier than pure 
HTML".

>>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.
> 
> I propose to code the engine (in fact, I'll start from zero instead of
>  re-using the bloated zwe), which will be easy to understand, and then
>  enverybody will be able to upload pages, maintain different sections  
>  ... Menu, pools, some variables will be on mysql tables. I don't want
>  to (and can't) take over the maintainance of the site, just the coding
>  part, and help Jerry and Michael to write the pages.
Ok, that I surely can agree with. But that surely sounds like a CMS. I 
guess the main thing we need to decide then is wether adding the 
(relative) complexity is actually needed - I mean, how many people will 
be updating the page? If Michael will be the only one (long term), it 
would be hard to justify the extra work. If there are several people who 
are willing to pick up the work, it sounds like the way to go.

Martin