[Cosmo-dev] Fwd: dojo.provide in styler

Travis Vachon travis at osafoundation.org
Wed Nov 29 12:05:58 PST 2006

Ah ha, very good call. I hadn't tested this out in other browsers yet  
(and wasn't going to commit without doing that ;) )

It sounds like the inline thing is a Safari wart for which we need to  
provide a kludge. That being the case, it would be nice to document  
that very well in the code, and make it as un-kludgey as possible.

I'd like to propose the following solution:
    - rename global.css.js and ui.conf.js so that they'll play nicely  
with dojo (suggestions on these names?)
    - put the dojo.provide("...") and dojo.require("...") lines in  
styler, globalcss.js, and uiconf.js (or whatever we decide on) if for  
no other reason than the fact that it will make the relationships clear.
    - include

<script type="text/javascript" src="${staticBaseUrl}/js/cosmo/ui/ 
<script type="text/javascript" src="${staticBaseUrl}/js/cosmo/ui/ 
<script type="text/javascript" src="${staticBaseUrl}/js/cosmo/ui/ 

    at the top of any JSPs that will actually need "globalcss" with a  
comment explaining the fact that they are currently working around a  
Safari wart. If we ever figure out a more elegant fix, or this is  
fixed in Safari we could remove them pretty easily.

I have all this implemented in my working copy, and it appears to be  
working. There is a bit of redundancy, but I think this way (with  
comments) will be clearer

One other issue:

Using only dojo.provide and dojo.require to suck in uiconf.js it  
looks like IE doesn't put the variables in the window scope. Firefox  
does do this, and I don't know which is the proper behavior. In any  
case, it seems like these should really be variables of some object  
(even if it's the "cosmo" object, or something like "cosmo.env". Any  



On Nov 29, 2006, at 12:03 PM, Travis Vachon wrote:

> Hi Folks
> What started as a JS question has turned into a discussion that  
> Matthew and I thought should be on the list. If folks interested in  
> how we're using Dojo and the overall organization of our client  
> side UI code could read down, I'm going to post my next e-mail  
> (containing a proposal) as a reply to this.
> -Travis
> Begin forwarded message:
>> From: Matthew Eernisse <mde at osafoundation.org>
>> Date: November 28, 2006 8:46:31 PM PST
>> To: Travis Vachon <travis at osafoundation.org>
>> Subject: Re: dojo.provide in styler
>> Travis,
>> Actually, I just made some changes to the Styler code as a result  
>> beta-testing the new Firebug 1.0. The beta actually has a couple  
>> of bugs that lead me to fix some some in there, woohoo! :)
>> I think doing that stuff with Dojo requires will be problematic  
>> because in Safari all the dynamic CSS is being done with the ugly  
>> document.write hack -- Safari only gives you read-access via DOM  
>> methods to the doc's stylesheets. That's why that script include  
>> sits where it does on the page -- in Safari it gets written out as  
>> an inline style. The code that does the document.write of course  
>> can be defined anywhere -- but it needs to be called, inline, at  
>> that point as the page is loading.
>> The global.css.js file may be the one place we will have to  
>> continue using old-skool script includes -- ui.conf.js is just a  
>> bunch of config settings, so it may not matter for those, as long  
>> as the constants are available to the scripts that need them, when  
>> they need them.
>> The one thing we do need to do with global.css.js though is  
>> rewriting it to use OOP. It's the one place I can think of in the  
>> system I had to hack in in a hurry ("Oh, shit, it doesn't work in  
>> Safari," I believe was the urgency), so it's just out there as a  
>> nasty global function.
>> Very good that you asked instead of just diving in and doing it. :)
>> Matthew
>> Travis Vachon wrote:
>>> Hi Matthew
>>> I'm working on the JS for account activation, and wanted to run a  
>>> change I've made by you before I go any further.
>>> To make styler work with dojo.require, I needed to make  
>>> global.css.js and ui.conf.js work with dojo.require. This meant  
>>> adding the appropriate dojo.provide statement inside of each.
>>> Unfortunately, because of the "." in each of their names, dojo  
>>> gets confused. To fix this, I've renamed them to globalcss.js and  
>>> uiconf.js, and added "dojo.provide("cosmo.ui.globalcss");" and  
>>> "dojo.provide("cosmo.ui.uiconf");" in the appropriate spots.
>>> The nice thing about all of this is that we can remove the inline  
>>> javascript includes from the JSPs and just use "dojo.require 
>>> ("cosmo.ui.globalcss")" in the JS file of any widgets we want to  
>>> respect the global css configuration.
>>> Is there any reason not to go this route? If you think all of  
>>> this is ok, I'll update the necessary JSPs before I commit  
>>> (including pim.jsp).
>>> Let me know what you think!
>>> Thanks,
>>> Travis
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/cosmo-dev/attachments/20061129/aa48d482/attachment-0001.htm

More information about the cosmo-dev mailing list