Re: [Gmod-ajax] Embeding jbrowse in a web site

[Mitch S. <mit...@be...>]

On 12/17/2009 01:42 AM, Mariette wrote:
> then I added the div to my page content (still just like it is in the
> index.html page of jbrowse) :
> <div id="GenomeBrowser" style="height: 100%; width: 100%; padding: 0;
> border: 0;"></div>
>
> I can see my page changing but I'm far from having the result I can get
> when using it localy !!
>    

Thanks for including some detail about what you were doing.  However, 
it's tough to know for sure what's going on without being able to see 
it; if it's accessible over the internet then it will be easier for me 
to see what's going on.

My first guess is that it's a CSS thing; did you include this bit of CSS 
from index.html?

<style type="text/css">
       html, body { height: 100%; width: 100%; padding: 0; border: 0; }
</style>

that's what makes the "height: 100%" style work cross-browser.  Also, if 
there are other things on the page (unlike the stock index.html, where 
it's just that one "GenomeBrowser" div that takes up the whole viewport) 
then you might want to specify a different size and placement for that 
div (possibly using units other than percent).  You should be able to 
specify whatever size and placement you want for that element and 
JBrowse should adjust; if not it's a bug and we'll fix it.

> So I was wondering if using it the ?loc and&tracks are important, we
> give to our page some
> arguments and it may be a problem ?
>    

They're important for bookmarking; if that's not necessary in your case 
you can turn it off by leaving out the "bookmark", "location", and 
"tracks" parameters to the Browser constructor.

If you're not using "loc" or "tracks" as url parameters for your 
server-side code, though, I don't think there would be a problem, but it 
probably depends on the details of your server code.  If you are using 
parameters with those names in your server-side code, you could always 
change the parameter names, either on the JBrowse side or on the 
server-code side.

Longer-term, the plan is for JBrowse to stop using URL query parameters 
and use the fragment identifier (the part after the #) instead, which 
should remove the possibility of a conflict with server-side code.

> Also, there was something wrong in the Utils.js file, I had to change
> the following function from :
> function $(element) {
>    ...
> }
>
> to
> function (element) {
>    ...
> }
>
> It may be a problem has well !
> Thanks for giving me some info if I'm doing something wrong or not,
>
>    

Giles is right that there can be conflicts between different pieces of 
javascript code when you combine them, but this ought to be fixable (or 
at least, it should be possible to improve the situation).

In particular, with the $ function, I put that into Util.js to make it 
easier to port away from the prototype js library, but that causes 
problems for anyone actually wanting to use prototype.  Just removing it 
from Util.js the way you did would certainly have broken JBrowse, so 
that may be part of the problem you're seeing.

But it was straightforward to take all the uses of the $ function in 
JBrowse and replace them with the dojo equivalent (dojo.byId), which 
I've done and pushed to the master branch:
http://github.com/jbrowse/jbrowse/commit/ed13ddeb11dd28137c6d3c3022fe38e42efdf6d1

which should address the problem you encountered there.

Longer term, the javascript libraries are getting better at co-existing, 
and JBrowse should also clean up its namespace usage (by moving 
everything into a "jbrowse" object).

Regards,
Mitch