-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
are.na filtering and validation lib #7
Comments
The final Q is – should this be a node module? |
So great. Within the Toolkit, I was thinking modules like this could be loaded once, and then provide a global interface for other tools. As a node module, this model would imply one import, rather than a separate import for each tool. I'm open to other strategies, but I think this will reduce page weight and complexity in the long run. |
One piece of related functionality that's also worth mentioning is a "block fetch" module. Once block data has been validated and the block type determined, it would be quite useful to retrieve specific data from those objects. Examples
Presumably this would be a separate module, unless you're trying to make a swiss army knife. |
single load sounds good to me. each validator should just be plug and play, so each tool can provide it's own custom validation methods if necessary. and yes, i think this is where the tinyAPI parser from mac.are.na would be a good fit |
https://github.com/gavinpatkinson/validate-arena |
ok after building /prototyping this a little i have a thought about how general this can/should/wants to be: rn we have a config as follows. Note the perscripted block attributes.
BUT what we could do instead is:
this way the lib becomes more of a general purpose object validator which is p cool. The other q is: Should each process - ie whitelist, sanitization, validation be separate methods? |
macarena and arentv heavily rely on block type filtering and url validation/sanitization. assuming tools in the toolkit will as well, I'm starting to write a general purpose 'library' to make this less of a headache.
here's an example config:
the pipeline goes something like this. ideally this is lazy and only runs validation / regex etc on items that cannot be easily rejected according to blockType
i propose it is appropriate to append messages about this process to the block itself in the following fashion:
The text was updated successfully, but these errors were encountered: