Re: [SrcML] XHTML-ViewPlugin

[Frank R. <fra...@un...>]

On Fri, Nov 18, 2005 at 01:12:46AM +0100, Icaro wrote:
> You could have a language independnt generator but a language specific 
> color property file for each language.

We definitely plan on having the generator as language independent as
possible (through the possibility of using de.srcml.language as a
way to query anything necessary about the supported target languages).

> the property file could be a simple set of couple "keyword"<->"color"
> 
> e.g. for java :
> class = #BBFFFF,italic (a color code)
> public = #66FFAA,bold,Courier
> ...
> 
> e.g. for python
> class = #66FFAA,bold
> def = #FFFFFF,bold,arial
> self = #3345AA,,Courier
> ...
> 
> moreover you could assign a color to word that are not reserved but have 
> special convention (like 'self' in python or String in java etc.)

As you already pointed out below CSS is a good way too and CSS has two
major advantage over a property file as you described it:

1) a CSS coloration can be exchanged without the need of having to rerun
the generation of the XHTML file, whereas a property file would only be
available at generation time.

2) CSS is already available. No need for us to implement anything beyond
the very colors we want to see. A property file like you suggest would
take additional coding effort (not a lot of it, but still avoidable).

Also CSS can be customized very aggressively when taking attributes into
account. So if we blow up our generated XHTML enough we can just about
color everything in whatever color we want. Here's an example:

span.modifier { color:red; }
span.modifier[name=public] { color:blue; }
span.modifier[name=private] { color:grey; }

> these are only extemporaneous ideas, I don't know in deep the 
> architecture of srcML and probably they would be not applicable at all.
> So, excuseme for the stupidities that I have written :-)
> 
> PS: is srcML in some way related to this: 
> http://www.sdml.info/projects/srcml/       (SDML: srcML)

Note that our project goes by the name SrcML (with a capital S). Both
project names simply originate from the obvious name "source code markup
language" with "markup language" generally being abbreviated as ML (as
in XML, HTML and various other lesser-known markup languages). As we
didn't want to choose a name not including that it's about source code
and a markup language we just went for the obvious.

But other than the basic idea of an XML represenation of source code
there is not much SrcML and srcML have in common. The resulting XML
files are fundamentally different (mostly due to the srcML project
insisting on a 1:1 relation between the source code file and the XML
file, whereas SrcML only cares about the semantics). Also the srcML
project has a C++ parser only while we have a Java parser only (with
both projects being able to support more parser but lacking the
developers to write them ;) The supporting API and Platforms are unique
to SrcML too, as srcML only consists of a parser afaik.

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

Then anyone who leaves behind him a written manual, and likewise anyone who
receives it, in the belief that such writing will be clear and certain,
must be exceedingly simple-minded. (Plato)