lucono/xtypejs

Elegant, highly efficient data validation for JavaScript.

xtypejs's Issues

default to descriptive names tab on xtype.js.org

as someone who doesn't know too much about your library, but am interested, i believe it would be nice to see the 'descriptive names' tab by default in the code examples. don't worry this won't make me think the library is too verbose or inefficient, it will just help me understand your nice examples a bit faster :).

Break out non-core functionality into optional add-on modules

Extract the following functionality which will be needed only by a subset of library users, into separate, optional, add-on modules:

• Custom types functionality - All the xtypejs built-in types will still be part of the core library.
• The util API methods (xtype.util.*) - These can be very useful when needed, but likely only needed by a few users.
• The bundled compact name scheme.

Extracting these into separate optional add-ons will reduce the size of the main library while still allowing the various extracted add-ons to be used when required, to re-introduce the various functionality only for library users who need them.

As much as possible, this change should maintain backward compatibility.

Add not, any, all, some, none interface variants of xtype.is

Thanks for the 0.6 modularity update!

I think it would be helpful to have an isNot method for readability. Instead of something like this:

!xtype.is(data, 'obj')

I'd like to be able to write xtype.isNot(data, 'obj')

Also, xtype.not.is() throws an error (but I don't like that form anyway).

Support for arbitrary custom-validated types

Add support for arbitrary custom-validated types, based on the discussion started in issue #1. Should include ability to define and register custom types, with arbitrary custom validation logic.

Introduce additional name schemes

The default name scheme is very readable and easily understood, but is verbose to type. On the other hand, the compact name scheme is short and easy to type but is not easily understandable to someone reading it in code without prior knowledge of the scheme's name convention.

For instance, default name scheme example:

xtype.which(value, 'multi_char_string, positive_integer, single_prop_object, number, nothing');

And compact name scheme equivalent:

xtype.which(value, 'str2+ int+ obj1 num nil');

It would be valuable to have available with the library, an additional set of alternative name schemes, which should be intuitive, have broad appeal, and provide a reasonable and practical balance of readability and conciseness falling somewhere between the two current default and compact name schemes.

Checking values with compact representation does not work

I can't make xtype work when I compare values with the compact representation.

If I do this (from the docs):

switch (xtype.which(req.params.testid, 'str2+ int+ nil')) {
    case 'str2+':
        res.send('str2+');
        break;
    case 'int+':
        res.send('int+');
        break;
    case 'nil':
        res.send('nil');
        break;
    default:
        res.send('type not recognized');
        break;
}

This always sends type not recognized.

Maybe I have to set xtype to use the compact representation by default? I can't find how I do this, if that is the case.

Thanks

How to validate Enums

We have a bunch of code that looks like the 'before' in your examples.
However we also need to validate enums, ensuring that the value is one of a list of strings or objects.
I am pretty sure I checked all the docs and didn't find this, any chance of getting some isEnum type functionality that basically does arr1 && indexOf type checks?