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

Travis Vachon travis at osafoundation.org
Wed Nov 29 15:32:41 PST 2006


It looks like dojo.io.cookie.deleteCookie isn't deleting our cookies  
for some reason, while the cookie code we've been using does. This  
seems like as good a reason as any to keep our cookie code for now! I  
still think making this dojo.require-able would be a good idea. In  
the long run, we should probably figure out why this isn't working  
and talk to the dojo folks about it.

-Travis


On Nov 29, 2006, at 1:26 PM, Travis Vachon wrote:

> 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
>
> _______________________________________________
> 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/df2bf118/attachment-0001.htm


More information about the cosmo-dev mailing list