On Mon, Mar 3, 2008 at 12:09 AM, Paul Lindner <[EMAIL PROTECTED]> wrote:
> On 3/1/08 2:25 PM, "Kevin Brown" <[EMAIL PROTECTED]> wrote:
> [....]
> >> + return {
> >> + /**
> >> + * Override the default properties with a new set of properties.
> >> + *
> >> + * @param {Object} properties The mapping of property names to
> values
> >> + */
> >> + init : function(properties) {
> >> + skinProperties = properties;
> >> + },
> >
> >
> > This seems redundant -- you already have it wired to the normal config
> > registration.
>
> Correct, the config registration handles the default skin properties
> for an entire site. Hi5 allows an individual to choose the skin for
> their profile page, which is passed into this init() method.
>
> Do you want to change the naming of this function? Or should I add
> more documentation to describe it's usage?
>
> Additionally we may want to allow overriding only a subset of
> properties. This is really a shindig implementation detail, we just
> need to decide how the container + syndicator + skins work together.
Assuming a theoretical skining format exists (say, something like igoogle
themes -- http://code.google.com/apis/themes/docs/dev_guide.html), it seems
that a good solution here would be to do the following:
- Pass the reference to the skin file into the iframe (a url would suffice,
but symbolic identifiers for skins available as local resources would be
better from a security standpoint, as Brian Eaton alluded to)
- Extract values from skin file and assign them to the skins API properties,
overriding the defaults.
- Assign this single block of values in the initialization.
I worry a little about having two initialization routines. Right now it's
difficult to wire up any sort of theming beyond per-site global theming
without maintaining some exhaustive proprietary patch, and I'd prefer a
single initialization call.
That said, what you've committed now is probably the best short-term
solution, and when we finally have well defined theme support (possibly in
the form of a spec standard, but I'll leave that discussion for another day)
we can go ahead and rip this out.
Will that require us to tweak the spec? If not I'll look at fixing
> This.
No, makeEnum takes care of this. At runtime all values resolve, but you
don't incur the extra bandwidth of all the declaration up front. Our code
doesn't have to look exactly like the spec apis, it just has to satisfy them
when a gadget is run under them. The spec is (necessarily) very verbose, but
our implementation is free to do whatever we want, as long as the API
conforms. For example, the following are equivalent from the spec's
standpoint, but very different from a performance and maintainability
standpoint:
gadgets.foo = function() {
function bar() {}
function baz()
return {
bar : bar,
baz : baz
};
}();
gadgets.foo = {
bar : function(){},
baz: function() {}
};
(function() {
gadgets.foo = {};
gadgets.foo.bar = function() {};
gadgets.foo.baz = function(){};
}());
All yield a gadgets.foo object with methods bar and baz, and thus satisfy
the "foo" API.
--
~Kevin
