[Cosmo-dev] Re: [Design] Design] [Cosmo] Login-related workflows update

[Matthew Eernisse]

Inline ...

Bobby Rullo wrote:
> Don't think that this is necessary, frankly. I dont see how it has 
> anything to do with the server-side, and unless it really does make 
> things easier from a coding perspective to have subclasses, than I can't 
> think of a good reason to do it. I could be convinced otherwise though.

By server-side I meant if people are using a server-side language that 
makes the distinction between Date vs. DateTime, they can serialize to 
JSON and hook it up to the backend, knowing it works the same way on the 
front- and back-end. They don't have to make special allowances or do 
any jiggery-pokery with flags. If people want to keep things all 
JavaScripty, they can just stick to the DateTime, and things work the 
way they're used to.

I'm not really religious about it, but it seems like a nicety that some 
people would find very useful, and doesn't get in anybody else's way.

> Since I'm doing a bunch of date work myself as well, I think a good plan 
> would be:
> 
>     a) let me finish my timezone stuff
>     b) I'll hook the timezones stuff into our existing date object.
>     c) I'll make it work in the UI
>     d) You can package it up dojo-style
>     e) Add your special sauce
>     f) go through the UI and make it use the new and improved 
> cosmo.date.CosmoDate or Xdate or Date or whatever.

Me likes.

> Also, if we're doing this, can we once and for all make things that are 
> better as instance methods instance methods? I'm thinking of "clone" and 
> anything else that require an instance.
> 
> It will be especially annoying to have to do a 
> "cosmo.date.XDate.clone(date)" rather than "date.clone()"

Excellent idea. Let's see if there are other candidates we might have in 
addition to 'clone.'

> One other important thing: it is very important that you allow our Date 
> objects still instantiatable via no-arg constructors which are lite-weight - 
> i.e. they don't do anything "expensive" in the constructors, or doing 
> property settings.  The reason for this restriction is because we create 
> objects from JSON data by using a no-arg constructor and copying 
> properties from the JSON hash to the object. 

That's a good bit of data to have. I'll keep it in mind when I add the 
special sauce.


Matthew