Re: [xul-announce] xul4j: New jXUL Offspring Upcoming

Hello,

As most of you know, I'm the current lead dev on Jazilla, one of the 
other jXUL spin offs, at the moment, I'm working on using Eclipse SWT, 
SuperWaba and Swing in our XUL engine. We're also working towards 
Mozilla XUL compatibility. Excuse me if you think what I'm saying must 
be in ROT13 - its late night, and I only got the time to start working 
on Jazilla again recently.

Son To makes very good points about jXUL. I agree these are issues with 
its codebase, and I wouldn't start with jXUL if I was going to make an 
XUL engine *right now*.

Heres my commentary on those points and what I'm doing about them:

  > 1) too many cyclic dependency between packages making
> it hard to use a package on its own. This is not
> necessarily a bad thing. For example if package A
> depends on package B and vice versa, it just means
> that package A and package B must be used together.

This is one of the problems in jXUL. While I've ripped out and replaced 
parts (jXUL's CSS was replaced, its ugly), some have been improved 
(JavaScript) and the rest, for now, remains. It isn't too hard to rip 
out the rest though, and where I see the need to replace something, I 
will. Remember jXUL is J2SE 1.3 era code, where almost every app 
required a gazillion add on libs just to work, so they did well to not 
have a lot of external dependencies.

> 2) inappropriate use of inheritance creates brittle
> class hierarchy. All the tag implmentation are
> subclasses of swing components.

This is one thing I'll be battling with. It won't be too hard to make it 
toolkit-neutral, but when I'm done, the only real remenants would be 
jXUL's per-tag child handling and construction(not too bad in my 
opinion, using reflection methods would be better, but AFAIK reflection 
doesn't exactly exist under SuperWaba) and DOM handling (which is slowly 
becoming Mozilla like), add the fact that there are tags in jXUL which 
aren't really in Mozilla XUL (i.e where the Mozilla version of the tag 
has been pratically re-done from scratch and has no resemblance) and 
will end up at /dev/null instead of being refactored.

In reality, I'm almost rewriting the entire thing from scratch, but 
keeping parts of jXUL's basic design in place.

When I was looking at other XUL engines this time two years back, I was 
looking for something simple to extend which had tried to implement 
Mozilla XUL - jXUL was the closest to that. Compatibility with other 
toolkits wasn't on the drawing board.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/