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

[Matthew Eernisse]

Glad you're getting the ball rolling on this stuff, man. Thanks.

Feedback inline, below.

Travis Vachon wrote:
> 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?)

The ui.conf.js file is a little tricky, since it's supposed to be a set 
of constants for app-wide configuration. I'd rather figure out a 
comprehensive way to deal with that issue than simply Dojo-izing the 
file and moving on.

As for global.css.js, how about something like:

cosmo.ui.style.generateDynamicStyle

Then when placed in the proper place in the file it will be a little 
more obvious about what it's doing there. Comments are good too, see 
below. :)

Then we can go about the process of packaging up the Styler that actual 
represents the stylesheet as cosmo.ui.style.Styler (since it's an 
instantiatable obj).

>    - 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 

If you're talking about packaging them up as proper Dojo modules, then 
absolutely -- at least the two CSS-related files.

>    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.

Agreed. The only thing I'd like to add is that I'd like us to use 
JSP-style commenting for that, so the comments stay in the source code, 
and don't land in the stuff the user gets in the browser.

> 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?

Right, I'd like do avoid Dojo-izing the global config stuff in 
ui.conf.js -- I figured there might be issues with doing dojo.require on 
it since it pulls source down with XHR and evals it.

I would much rather start talking about a better way to implement a 
similar set of app-wide constants the UI code can use. This seems to be 
to be different from the environment variables, but maybe not enough to 
warrant needing something outside that.

Especially with static values like this, I'm a big fan just accessing 
properties rather than having to call a method to get each different 
value (unless it's just a generic method like 'getItem').

I'd also really like them to appear as obvious constants in the code. 
Since IE-compatible JS can't use actual constants, the convention is 
usually just to uppercase the name, so something like:

cosmo.config.HOUR_DIV_HEIGHT (or env, whatever)

A big priority for me is *not* just to paper over the non-Dojo stuff. I 
want to do a thorough conversion of each library rather than putting it 
off for 'someday.'

Thanks again for starting the discussion of this stuff.


Matthew