[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