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

Travis Vachon travis at osafoundation.org
Wed Nov 29 13:26:29 PST 2006 

Just a couple other nits along these lines:

With these changes implemented, we have three other JS includes in  
login.jsp:

<script type="text/javascript" src="${staticBaseUrl}/js/cosmo/util/ 
cookie.js"></script>
<script type="text/javascript" src="${staticBaseUrl}/js/cosmo/util/ 
log.js"></script>
<script type="text/javascript" src="${staticBaseUrl}/js/cosmo/util/ 
popup.js"></script>

- It looks like dojo.io.cookie provides the same functionality as  
cookie.js, any reason not to phase this out?
- Can we dojo-ize log.js and popup.js? I'd feel comfortable tackling  
log.js, but will probably punt popup.js to someone else or later, as  
it looks a little more complex.

-Travis

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

> 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/ 
> uiconf.js"></script>
> <script type="text/javascript" src="${staticBaseUrl}/js/cosmo/ui/ 
> styler.js"></script>
> <script type="text/javascript" src="${staticBaseUrl}/js/cosmo/ui/ 
> globalcss.js"></script>
>
>    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 thoughts?
>
> Thanks!
>
> -Travis
>
> 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
>
> _______________________________________________
> 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/1437dfd8/attachment-0001.html

More information about the cosmo-dev mailing list