Create resource schema that represents a Resource

[Marak]

Currently, there is no easy way to enumerate all the possible configuration options of a Resource. We should have a schema that defines what a resource can be.

I recommend building the Resource resource using the resourceful API ( versus pure JSON-Schema ). You can always pull the JSON-Schema back out of resourceful using the Resource.schema field.

The schema for a resource would define the following structure:

• Name of the resource
• Expected CRUD methods
• Unexpected arbitrary remote methods
• Relationships to other resources
• Engine Configuration ( database connection details )
• types of properties allowed
  • the configuration options allowed for property types

The last point is particularly important. For instance, String type has a format option that may be email. Number has maximum and minimum options which expect numerical values. Currently, there is no programatic way to look this information up.

Once we are able to easily reference this information as a schema / resource, resourceful can become "self-hosted" in the sense that we can use resourceful reflection tools ( restful / formful / socketful / commandful ) to create new Resource definitions dynamically.

[Marak]

Got a partial start here: https://gist.github.com/bf21229c7a1d6ae02884

Using the types / options schema data in that gist for another project, will update as I go.

[raix]

Remember auth... It should be part of a ressource definition to define roles for the different actions (cruds)?
A self defining ressource would be nice, would be Nice if the definition could be used ón the client for making a client js api interface. Maybe even localstorage api with sync...

[Marak]

@raix In regards to your comment about the client:

I'm currently working on making the RESTful ( request module ) and socketful ( socket.io ) engines isomorphic.

see:

• https://github.com/flatiron/resourceful/tree/socketful-engine
• https://github.com/flatiron/resourceful/tree/restful-engine

This means seamless client or server communication to an existing https://github.com/flatiron/restful or https://github.com/flatiron/socketful server. i.e, define a resource, get a client and a server

Any help on either of these branches would be appreciated. They are both already mostly working ( with tests ).

[Marak]

@raix - Also, for now, there is director-reflector, which will create JS client API for any Director.router instance, which is what restful uses to generate routing maps.

Cheers!

[raix]

Ok, trying to grasp, so the restful Engine could run ón the client? (maybe the dB connection could default to restful engien if (window)/ ón client)
The thing i like about restful / resourceful / revalidator stack is that it easy to define the data and properties. The thing im lacking is auth (defined pr. Rsource) and client version.

Like to help, but just have to figure out the direction / the goal

Sendt fra min iPad

Den 02/09/2012 kl. 07.02 skrev Marak notifications@github.com:

@raix In regards to your comment about the client:

I'm currently working on making the RESTful ( request module ) and socketful ( socket.io ) engines isomorphic.

see:

https://github.com/flatiron/resourceful/tree/socketful-engine
https://github.com/flatiron/resourceful/tree/restful-engine
This means seamlessly client or server communication to an existing https://github.com/flatiron/restful or https://github.com/flatiron/socketful server. i.e, define a resource, get a client and a server

Any help on either of these branches would be appreciated. They are both already mostly working ( with tests ).

—
Reply to this email directly or view it on GitHub.

[fkhbgm]

Also interested by this and willing to help instead of writing my own logic.
as @raix noticed, the direction is important.
Here is mine:
Shared between browser and nodejs

• description of resources and relations
• validation code (even custom code)
• REST service description
  Server side only:
• storage (db) description
  After reading your comments, I think an abstraction may be possible between REST/Socket/localstorage/dbstorage... even if I think that in serious cases, implementation of each layer (or how the entity is mapped/consumed) will be different.
  For such a service to be usefull, the most important things are: easy and declarative way for 'standard' cases. full possibilities of extensions for the others.
  This can be a backbone for many other value-added modules...

[Marak]

invalid