srcml-discussion

[SrcML] XHTML-ViewPlugin

[Leif B. <lei...@un...>]

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

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>


Greetings
Leif

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

Re: [SrcML] XHTML-ViewPlugin

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

On Thu, Nov 17, 2005 at 11:50:09PM +0100, Leif Bladt wrote:
> Another thing are the new events which are thrown, when one of the  
> "old" events are completed. Should we implement a "Done" event for  
> each of our events? My suggestion is a single DoneEvent which  
> contains the event currently finished, so you can also see which  
> event is finished.

What about extending your NextElementDoneEvent into a more generic
DoneEvent? Shouldn't require that much of a change.
Only problem might be the performance when every single whitespace
results in a whole bunch of events being fired through the whole
machinery. But we can still add some event filtering later if it proves
to be a real problem and only send the events when requested.

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

You can be discouraged by failure, or you can learn from it. So go ahead and 
make mistakes, make all you can. Because, remember that's where you'll find
success - on the far side of failure. (Thomas J Watson Sr)

Re: [SrcML] XHTML-ViewPlugin

[Leif B. <lei...@un...>]

> What about extending your NextElementDoneEvent into a more generic
> DoneEvent? Shouldn't require that much of a change.
Done :) It's in the CVS although the Unittests don't compile (the  
JavaHelper.java doesn't compile anymore).

> Only problem might be the performance when every single whitespace
> results in a whole bunch of events being fired through the whole
> machinery. But we can still add some event filtering later if it  
> proves
> to be a real problem and only send the events when requested.
This is a real problem, so at the moment I will fire DoneEvents only  
after StringEvents are processed. That's acceptable, but also  
noticeable slower.


Greetings
Leif

Re: [SrcML] XHTML-ViewPlugin

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

On Fri, Nov 18, 2005 at 10:21:47AM +0100, Leif Bladt wrote:
> >What about extending your NextElementDoneEvent into a more generic
> >DoneEvent? Shouldn't require that much of a change.
> Done :) It's in the CVS although the Unittests don't compile (the  
> JavaHelper.java doesn't compile anymore).

Ops. I'll fix that when I'm back from uni tonight.

> >Only problem might be the performance when every single whitespace
> >results in a whole bunch of events being fired through the whole
> >machinery. But we can still add some event filtering later if it  
> >proves
> >to be a real problem and only send the events when requested.
> This is a real problem, so at the moment I will fire DoneEvents only  
> after StringEvents are processed. That's acceptable, but also  
> noticeable slower.

What about adding a boolean variable then for the different events
specifying whether they should fire DoneEvents and an accessor method to
set this behavior?

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

This report, by its very length, defends itself
against the risk of being read. (Winston Churchill)

Re: [SrcML] XHTML-ViewPlugin

[Leif B. <lei...@ma...>]

> What about adding a boolean variable then for the different events
> specifying whether they should fire DoneEvents and an accessor  
> method to
> set this behavior?
Nice idea. So this variable could be in ViewEvent itself, with a get-  
and set-method. And the default value for a plugin is set in its  
constructor? In this case, you have to change thee default every time  
you create an event. Could we get this into the view platform, so  
that we could define the behaviours only when we create the view  
platform?


Greetings
Leif

Re: [SrcML] XHTML-ViewPlugin

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

On Fri, Nov 18, 2005 at 11:22:13AM +0100, Leif Bladt wrote:
> >What about adding a boolean variable then for the different events
> >specifying whether they should fire DoneEvents and an accessor  
> >method to
> >set this behavior?
> Nice idea. So this variable could be in ViewEvent itself, with a get-  
> and set-method. And the default value for a plugin is set in its  
> constructor? In this case, you have to change thee default every time  
> you create an event. Could we get this into the view platform, so  
> that we could define the behaviours only when we create the view  
> platform?

Actually I was thinking about having it in the ViewPlatform right from
the start. So that for every platform you create you can customize what
events you want to be handled.

Let me elaborate this a bit further:

These are the event classes currently existing:
NewlineEvent, NextElementEvent, StringEvent, WhitespaceEvent

Let's add corresponding Done-Events:
NewlineDoneEvent, NextElementDoneEvent, StringDoneEvent, WhitespaceDoveEvent

Now create a Set<java.lang.Class> in the ViewPlatform which by default
contains all those event classes. Add methods to add/remove/clear
classes to/from this set. And in View.sendEvent(ViewEvent) perform a
single lookup whether the event's class is in the set. If not the event
is immediately thrown away.
For performance reasons the ViewPlatform can also keep some boolean
variables f.ex. for the generation of the *DoneEvent objects. Those
variables will have to be consistent with the set of course and can be
used to even avoid the instantiation of those events.

How does that sound to you? Anything I'm missing there?

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

Every technology really needs to be shipped with a special manual--
not how to use it but why, when and for what. (Alan Kay)

Re: [SrcML] XHTML-ViewPlugin

[Icaro <ic...@gm...>]

Frank Raiser ha scritto:

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

You could have a language independnt generator but a language specific 
color property file for each language.
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.)

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

the property file may be loaded depending on the kind of source and 
then  for all the token in the source file we search it in the small 
list of significant word. 
(If 'cls' or 'class' is in the list you color it with the specified 
color. )

>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.
>  
>
This is not so simple to accomplish with property files (perhaps storing 
regular expression in the property file...) but they can make simple the 
customization of the result for different purposes:
i.e. you could also allow the specification of different combination of 
color-font for a same language that could be specified as command line 
paramiters.

for example:
dark_java_color.property
light_java_color.property
etc.

Another solution could be the use of CSS in combination with the 
generated HTML.

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)

-- 
Domenico
http://icaro.blogspot.com

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)

Re: [SrcML] XHTML-ViewPlugin

[Icaro <ic...@gm...>]

Frank Raiser ha scritto:

>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:
>
>  
>
Yes, CSS is better! :-)


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

thank you for the clarifications.

Icaro

-- 
http://icaro.blogspot.com