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

Max Horn max at quendi.de
Tue Jul 8 11:56:01 CEST 2008


Am 02.07.2008 um 20:56 schrieb [vEX]:
>
>

[...]
> [...]
>>
>> 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.

Well, seems we need to stay with PHP4 compatibility, though. Anyway,  
validation is certainly not required. If you need to distinguish  
between the NEWS structure XML, and the "content" XHTML, the easiest  
way is to use XML namespaces. Or just limit the structure of the XML  
enough.


>
>
> 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?


I think that it's fine to use (X)HTML to format news items -- going to  
BBCode does not separate data and presentation, it just adds an extra  
layer. Or why would [b]foo[/b] be more "separated" than <b>foo</b> ? :)


[...]

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

If we are talking about the screenshots here, then I would recommend  
using a small text file (XML or CSV), either one containing all  
images, or one per image. Using filenames is not flexible enough.	

[...]

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

Once again, XHTML is just a variant of XML :). But I assume you mean  
you want to distinguish non-XHTML elements from other elements. Well,  
that's what XML namespaces are for, right? Or does the PHP4 XML not  
support these? In that case, we could just as well specify a list of  
XHTML elements allowed in the NEWS (we'd get such a restriction if we  
used BBCode, too).

IMO, it makes no sense to add the extra layer of BBCode, when we  
already use an XML parser. Why use two parsers for two different but  
similar formats, if you can do it all with one format, and elegantly,  
too ?

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

See <http://www.scummvm.org/test.php>.

Overall I heard no critical comments about your plans. From my point  
of view, we could go ahead with this project. Eugene seems to agree as  
well. He'll mail in a moment, too :)

Cheers,
Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20080708/b504fe28/attachment.html>


More information about the Scummvm-devel mailing list