[Scummvm-devel] [RFC] ScummVM website re-write

[vEX]

Hi,

It's nice to see so much support for a re-write. I'll try to address the 
comments/questions you have so far.

Max Horn wrote:
> However, it *does* work well, and so a switch has to be considered 
> carefully, and tested beforehand.

Like always, all code should be tested, and tested _well_. Even if I have tested 
that everything seems to work that's not enough. Before a switch it would have 
to be tested by you to find any bugs or quirks.

> Also, I really prefer to keep everything "text-only", i.e. no database 
> usage. This way, the complete website is stored in subversion, which 
> makes it trivial to backup/restore/replicate it at any time. Luckily, 
> [vEX] work seems to be consistent with this.

Yes, a database for the content published on the ScummVM website would be 
overkill. And I don't like to add a database dependency unless it's really needed.

> Another thing to ponder is whether one could use some more "off the 
> shelf" components. Like an existing CMS, or at least e.g. a gallery 
> software, etc.. Pro: Saves us coding, gives us powerful features for 
> free: Like being able to add & edit news items via a webbrowser.
> Con: Most of these require DBs, which I would prefer to avoid, or at 
> least the advantage would have to far outweigh the advantage of not 
> using a DB (see above).
>
> However, we could still use some stuff. The proposal already involves 
> smarty. We could use some other 3rd party tools. E.g. for the 
> screenshots, we could use SPGM <http://spgm.sourceforge.net/>.

You don't have to worry about the part about me having to write less code. And I 
have written CMS stuff before. Personally I prefer to write all parts from 
scratch so I have full controll over what they do. But if you feel that using 
"off-the-shelf" compontent I can do that as well.

I have already been thinking about the administration a bit actually. My first 
thought was to simply have a form where you could enter text and it would 
generate the XML for you (both as plain text in the browser and as a 
downloadable file). It would still mean that you have to manually upload the file.

I could write an administration page that does't need to use a database, but the 
  username/password stuff would need to be saved to a file (non-plain text of 
course). However, great care would have to be taken to make sure that the file 
_never_ gets added SVN or somehow published for anyone to see. Full access to 
the source and the hashed password is not good. Or I could use SQLite [1][2], 
but that would require that support for it has been compiled in with PHP.

[1] http://sqlite.org/
[2] http://se2.php.net/manual/en/book.sqlite.php

> Another thing I mentioned: I'd like to retain the existing URLs, at 
> least for the most important pages (screenshots, downloads, faq, 
> compatibility, ...). For backwards compatibility, but I also prefer 
> human readable (and meorizable!) URLs in any case. That shouldn't be an 
> issue, though.

I never realized this would be such a strong point. Thankfully it is something 
that is easy to acheive. Either use mod_rewrite, fake files, or re-direct pages. 
The first two would transparently transfer the user who wouldn't know that the 
URL has changed. The latter one would display a message stating it has changed, 
link to the new URL and automatically transfer within a given period of 
inactivity. Each method has their pros/cons.

> One more idea: It might be nice to be able to provide a localized 
> website one day, i.e. with german/french/... pages. Nothing to worry 
> about right now, but it would not hurt to at least keep that in mind... 
> for the very distant future... ;)

Well, PHP do have support for gettext, though I never used it. And I'm not sure 
if it can interact with Smarty directly. But on the other hand, all text would 
need to be translated so the HTML templates should probably just contain 
something like {$text_introduction}. And PHP/gettext would decide what string to 
put into that variable.


>> Pros:
[...]
> 
> To me, most of the above "Pros" are "only" nice boni, but not enough to 
> warrant a switch. But enabling CSS usage, and making it easier to extend 
> the codebase, might buy me ;).

Well, that was just some short list, nothing really ment to persuade you to take 
the bait so to say. It was kind of a summary of what's been done.

> Caching is certainly nice from a theoretical POV, but in reality, we 
> never had any speed issues with the site. As long as it doesn't 
> complicate the code, fine by me, but no need to jump through hoops to 
> get it.
> 

I think a rewrite from the table based design to CSS/divs would make it render 
faster, but that's pretty much the only speed up I think could be gained.

[...]
> 
> An alternative approach would be to just add a select subset of HTML to 
> the DTD, no? Or even import that HTML DTD... BBCode might be easy to 
> use, but HTML is so, too....

Well the problem is that the XML parser functions I use are non-validated. That 
simple XML parser simple doesn't give a damn about DTDs. But that's the only 
XML-parser provided in vanilla PHP4 to my knowledge. However, in PHP5 there is a 
SimpleXML parser that would work even better. Even though it's non-validating it 
shouldn't have any problems since I could ask for all the contents of any tag.

It would however also mean that there wouldn't be a complete separation of data 
and presentation. That's something you should decide on however, perhaps making 
it completely separated is taking it to an extreme for the ScummVM website?

[...]
 >
> Is this there to support running on PHP4 systems? Does the site fully 
> work with PHP4 then? (Not so important, as SF.net is our primary host, 
> and I do not forsee us moving to a host which does not support PHP5, 
> ever ;).

Well, the info I got from _sev is that SF.net runs PHP4 which is why that file 
exists. I haven't actually tested it on PHP4 yet, and wouldn't do so until 
everything works. If you actually have PHP5 support I would be very happy, then 
I could actually define things as public/protected/private and such (which would 
break PHP4 support).


[...]
> 
> This has mostly historical reasons, I'd say. This code and the system 
> certainly could be improved a lot. Also note: You do not have to be 
> pixel-level compatible here. And one could use a 3rd party gallery tool 
> for some of this, e.g. SPGM <http://spgm.sourceforge.net/>, or something 
> else.

Oh, I didn't aim for pixel-perfect, I already have some small things different 
;-). I could write something up that means you only need to dump the images in a 
directory and it will pick them up. It's just a question about specifiying how 
and where the related information should be stored (in the filename? in a small 
text file?).

> I would be fine with changing the format of the news. In fact, the whole 
> news system could be a lot better. I wouldn't mind switching to a 
> completely different "news" system, either, maybe even one "off the 
> shelf". As long as it can use text files for input... ;).
[...]
 > There are lots of BBCode parsing classes out there; if we really want to
 > use BBcode, one should at least try to use of them. Or just use some
 > existing "news" system, as suggested above.

Well then, tell me what you need, and what you want then. I could code 
something, or look for an existing product that does that. What I can't do is 
guess your needs. It's you who have used the system all this time and know what 
is working good and what is not.


[...]
> Actually, we use faq-inc.xsl (an XSL style sheet) to translate DocBook 
> XML to XHTML. In the same vein, it should be possible to write an XSL 
> file which translates it to any other XML variant you prefer. So I don't 
> see the problem here.

Ah, never used or messed with XSL so that would give me a chance to learn 
something new.

> I am not sure what you mean with "it would pick up all the docbook tags 
> as XML-tags" -- we are using DocBook XML, so those "tags" (actually, the 
> correct term is "elements", to be nitpicky ;-) *are* XML-elements... So 
> again, I don't see the problem?

I was thinking about how I build the "tree" (multidimensionl array) from the XML 
using the simple XML parser in PHP4 discussed above. It makes it difficult to 
mix XML/HTML since it doesn't know anything about DTDs. It just sees the start 
and ending tags and happily perceives it as an XML-element that should be parsed.

[...]
> 
> Actually, I couldn't care less about the precise date format used in the 
> news. In fact, personally, I prefer ISO format anyway (YYYY-MM-DD). 
> Using a plugin just to get this to be compatible with the current code 
> is total overkill ;). Also, using a 3rd party news system might resolve 
> that, too.

For storing dates I'd say using either YYYY-MM-DD or unix timestamps is the best 
if you want to use the PHP date/time modifiying functions. Just having the file 
named with the date (YYYYMMDD.xml) it was posted is actually enough.

[...]
> 
> Then maybe consider doing that? I am pro-OO and pro-MVC; but  overdesign 
> and code bloat can be quite painful, so .... ;)

I think that actually having an object might be more futureproof than having an 
array. You should then be able extend the object and it should work fine without 
many other modifications. Using arrays could potentionally be more difficult 
after a few rounds of changes, it could also be to limiting at some point. I 
should however revise the naming of the objects.


Come to think off it, it would really be nice if I knew what kind of PHP support 
  SF.net has. Not just the PHP version, but also what extensions are enabled and 
what versions. So a small request from me would be to get that information. 
Putting "<?php phpinfo(); ?>" in a file ending in .php and running it would do, 
  it could even be run from a console (assuming SSH-access and CLI-support 
compiled in).



Regards,
Fredrik