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

Wed Nov 29 16:00:10 PST 2006

Are we even using log.js anymore? I would think it might not be 
necessary anymore, if y'all are using dojo.debug.

I'll put it on my list to Dojo-ize the popup library.

By making it requireable, are you talking about just requiring the 
library as-is, or are you talking about a real conversion?

I would really like us to consider seriously taking this opportunity to 
do real conversions -- e.g., to cosmo.util.cookie, rather than just 
papering over the differences with a dojo.require/provide.

Leaving the unconverted libraries as normal script includes would remind 
us which code we've already tended to, and which still needs to be 
properly namespaced and packaged.

Matthew

Travis Vachon wrote:
> 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 
>>>>> <mailto:mde at osafoundation.org>>
>>>>> *Date: *November 28, 2006 8:46:31 PM PST
>>>>> *To: *Travis Vachon <travis at osafoundation.org 
>>>>> <mailto: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 
>>>> <mailto:cosmo-dev at lists.osafoundation.org>
>>>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>>>
>>> _______________________________________________
>>> cosmo-dev mailing list
>>> cosmo-dev at lists.osafoundation.org 
>>> <mailto:cosmo-dev at lists.osafoundation.org>
>>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>>
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org 
>> <mailto: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