Re: Started

Hello,

> I have started working on luxor again.
> In the cvs now is a new branch which I called test.
> The reason for creating the branch, is that I'm
> thinking of some modifications
> in the design. Having those modifications in an
> other branch, then the main one,
> will avoid braking something.

  Fantastic news. I also plan to put in some cycles
soon. I hope to get the Maven build system switch over
done for real next week.

> There is a problem with the
> luxor.template.XulTemplateResourceLoader which has
> this code:
>            XulManager xul =
> XulManager.getXulManager();
>            in = xul.getResourceAsStream(
> templateName );
> The problem is that the  XulManager.getXulManager()
> returns the first instance
> of XulManager created, but if there are other
> instances as well, which require a
> resource to be loaded, then the loading will
> probably fail.

  Until Beta 7 there was only one XulManager. Starting
with Beta 8 there's a default XulManager, that is, if
you call XulManager.getXulManager() you always get the
same XulManager. I've switched to the new approach
because Sahara - the Luxor Sandbox/Viewer - requires
at least two XulManagers, one for the browser itself
and one for the Luxor app to be viewed.

  I understand the issue that the template loading
currently only works with the default XulManager. If
you have a better solution, please go ahead and try it
out.
  

> Here is an example code which fails with a
> NullPointerException:
>        XulManager xul = XulManager.getXulManager(
> Integer.toString( _lastId++ ) );
>        SimpleChromeLoader loader = new
> SimpleChromeLoader( chromeDir );
>        xul.setResourceLoader( loader );
>        xul.load();
> taken from luxor.runner.AppRunner.
> The NullPointerException is caused because the first
> instance of XulManager has
> no ResourceLoader associated with. So when
> XulTemplateResourceLoader requests
> from the first instance of XulManager an InputStream
> the exception is caused.

  Thanks for the sample source. I guess with need to
safeguard for the special case where the default
XulManager is not setup properly.

> Perhaps the AppRunner shouldn't create a new
> instance of XulManager.

  Well, I don't see why you shouldn't.

> I think though that is good
> to have many XulManager
> instances.

  I think so too. For a "real world" example see the
Sahara example.

> Design Problems:
> The code base is big, so I might have misunderstood
> the design. Be skeptical
> about my comments.

  Thanks for your great comments. Keep it up. The
code, for sure, isn't perfect. Please, take it apart.

> The XulContext seems to be used as a shortcut, as a
> way to avoid typing all the
> interfaces which declares to extend.

  Well, the idea of XulContext is as far as I remember
that you can create your own XulManagers (e.g. you can
replace the exiting one with your own). 

> In other classes, a request for a service goes from
> class to class.
> Here is an example:
> 1:XulManager.load
> 2:XulLoader.load
> 3:TemplateManager.getTemplate
> 4:XulTemplateResourceLoader.getResourceStream
> 5:XulManager.getResourceAsStream
> 6:ChromeResourceLoader.getResourceAsStream
> 
> At least, this way is very confusing. The chain of
> actions goes to 5 different
> classes, and a call to XulManager after having
> called methods from 3 other
> classe ends up to XulManager again.
> 
> I guess there could be simplifications over this
> model.

  If you have any suggestions for simplifications go
ahead and try them out. The idea of a resource loader
lookup chain is that you can easily plug in your own.

  - Gerald


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click