Re: [SrcML] XHTML-ViewPlugin

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

On Thu, Nov 17, 2005 at 12:25:23PM +0100, Leif Bladt wrote:
> for testing purpose I implemented a NextElementDone-Event, which is  
> called, after all Listeners and default-methods were called. So I can  
> react on the end of a tag. That's fine so far.

If it works without breaking the unit test for the ViewPlatform feel
free to commit it to CVS too.

> But if I would like to color only the "class"-string in the example,  
> I have no clue where to start with. Can I realise it with the  
> existing structure (e.g. the StringEvent) or do we have to extend the  
> event structure?
> 
> My test class:
> >public class Test {}
> 
> Its SrcML representation:
> ><?xml version="1.0" encoding="UTF-8"?>
> ><unit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
> >language="java" filename="Test.java" author="leif" xsi:noNam
> >espaceSchemaLocation="http://srcml.sourceforge.net/srcml.xsd">
> >
> >  <class name="Test">
> >    <modifiers>
> >      <modifier name="public"/>
> >    </modifiers>
> >    <block/>
> >  </class>
> ></unit>

Ok and of course for everyone to fully understand the problem we have to
add that the XHTML generation should be as language independent as
possible.

Therefore you cannot compare the String to "class" and color it
accordingly, as a new language might use "cls" instead. You also have to
be able to deal with a language which can legally have a class called
"class" (and the coloration needs to reflect that it's the name of the
class and not a keyword).

So what options do we have left?
Let's take a look at the information available at the time of the
generation of the XHTML code:

- we know the string s to print equals "class"
- we know the de.srcml.dom.Class instance it's related to

Now why do we want to color the "class"? Well because it is a keyword in
Java of course. So this is easily solved:
boolean de.srcml.language.Language.isKeyword(String)

What about the name of the class being highlighted differently
(identifier color or something)? Well we have the DOM node for the
class, so we can get the name of this class and compare the output
string to that in order to find out.

Also the coloration can be customized for other keywords depending on
the type of the related DOM node. For example a "public" modifier can be
colored differently than the "class" keyword although both return True
for isKeyword. The distinction can be made based on the DOM node's
class.

So right now I'm not seeing much of a problem here. However if you have
a good idea of how to improve the event mechanism to include this necessary
information just try and explain it. We could subclass the StringEvent
of course, but the question arises as to what subclasses to create. And
I don't know if having too many subclasses again doesn't raise the
complexity of the platform without any real need for that. If you
consider the extreme amount of possibilites to configure the XTHML
colors we seem to get a huge bunch of subclasses as each new color
option should be a subclass then.

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

"A mathematician is a blind man in a dark room looking for a black cat 
which isn't there."                -- Charles Darwin