module.exports

[dvv]

Hi!

The subj stopped to work with recent node. Please, consider pulling the fix

--Vladimir

[akidee]

1) In the future, please keep the whitespace as it is. Makes it easier for me to scan through changes. Thanks 2) There is no "date" in JSON Schema. I will think about it. The problem is, that is no "bare data" like the native types. 3) readonly: I don't know how this can be validated. The only way is to do it with (async?) adapters. You don't know if you validate an initial or an updated instance. This is only possible in the context of a new validation param, something like "isUpdate: true" I need to have code that is applicable in all cases. Conclusion for now: add module to exports, no date (too concrete), readonly only in a new context of functionality. This is a date schema I have written in coffee script yesterday:

id: 'Date'
type: 'object'
adapters: (instance) -> if !(instance instanceof Date) then new Date(instance) else instance

This will work properly.

[dvv]

Sorry for delay.

1) it's my editor. I can't control it. BTW, it deleted pending whitespaces, which I consider a good. I have tried to respect other spacings and will be. 2) I know JSON missed date. It's just my hack, we could adopt that 3) readonly: mostly just for markup, to denote the field is supposed to be immutable. I know how to validate it -- validator should rip the field from the data and silence the error due to field is thus missing. Very useful for access control application, which I'm developing. 4) why 'default' can't be a function? What prevents us? Of course this could be a getter, but in coffeescript there's no means to write getters

Wonder what is the net result?

Best regards, --Vladimir

[akidee]

1) I always try to adopt the author's code style. And I am very interested in keeping my own code in my style ;) 2) Of course, you can add it that way for yourself. 3) If you add a separate schema only for updating, then you do not need "readonly" ... how can you see if a value has changed or if it's the initial value? 4) The standard. Functions are only allowed, if it's an extension of the standard.

I am going to test module.exports next. My experience is that setting exports does not work.

[dvv]

I see. 2) do you use dates in your data? Let's discuss what are options 3) you don't need to check if the value changes. just rip the fields and don't complain on field is missing. Plus, form renderers could honor readonly to display disabled fields 4) I can live w/o 'default' function

How about bullet-proof module.exports = exports = ...?

[akidee]

2) I use dates, and I will do it how I demonstrated in my example. It is interesting to use an adapter to try to create Dates from both (milli)seconds and timestamps, whatever is given. 3) Show me an exmaple, please.

Today I have updated to node v0.2.3 - and it still requires me to set module.exports, of course you can assign it to exports.

[dvv]

I meant node 0.3.0-pre, from the trunk. Couldn't you confirm it's still working with module.exports, so I could blame on my broken setup.

TIA, --Vladimir

[dvv]

I finally found and fixed the error causing module.exports to be ingored. My setup was wrong.

2) couldn't you gist a simple schema for an entity with an ID and a Date-typed property? 3) this is how I render a JSON schema: http://github.com/dvv/schema2form/blob/master/index.js . Having readonly attribute even for markup purpose would allow to render some inputs disabled, w/o any guesswork. Of course I can abuse, say, description attribute to contain a mess which can be decrypted at client to a set of meaningful attributes (consider, description: "JSON-here-to-be-parsed-at-client-side-to-form-nonstandard-schema-options") but this all leads to nothing.

TIA, --Vladimir