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/
_______________________________________________
xul-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xul-talk
