Skip to content

future json structure

Rob Clayburn edited this page May 15, 2013 · 51 revisions

Apps:

[{ app: 'Todo' description: 'My todos', creator: 1, createDate: 'yyyy-mm-dd', lists: [1, 2, 4] }]

Lists

`

[
		{
		id: 1,
		label: 'Outstanding Tasks',
		order: [{element: 1, direction: 'desc', default: true}]
		columns: [{element: 2, label: 'date'}, {element: 1, label: 'cost'}],
		filters: [{element: 3, type: 'field'}, {element: 4, type: 'auto-complete'}],
		groups: [1, 2],
		form: {
				label: 'Test form',
				intro: 'Intro to this form',
				layout: 'template'
			}
	}
]

`

Lists forms, Groups & elements are not in apps - so they can be reused in multiple apps.

`

groups: [
		{
			id: 1,
			creator: 1,
			name: 'tasks',
			label: 'Tasks',
			repeat: false,
			repeats: {min: 0, max: 10}
			elements: [1, 2]
		}
	],
elements: [
		{
			id: 1,
			creator: 1,
			label: 'Task name',
			name 'name',
			plugin : {type: 'field', length: 20, password: false, placeholder: 'Enter a task'},
			tip: 'tip text'
		},
		{
			id: 2,
			creator: 1,
			label: 'Create date',
			name: 'createdate',
			plugin : {type: 'date', length: 10,
			tip: '',
			validations: [{type: 'notempty', msg: 'please enter a create date}]
		},
	]
	

user: [{
	id: 1,
	name: 'Rob',
	email: '[email protected]'
	groups: [1, 2]
}]

groups: [{
	id: 1,
	label: 'Registered',
	adaptors: [{site: 'http://myblog.com', 'type': 'Joomla', equivalent: 3}] // Map view access level of 3 to group id = 1
}]

`

What we'd add:

  • GUI to build the layouts
  • Some form of mapping for host sites to parse in their users info/user groups to the web service

What we're removing:

  • The concept of parent / child elements
  • Option for form to not record to db - everything will

What we're not going to implement to start with :

  • Publishing start/end dates
  • csv/pdf views
  • custom list links
  • element js events
  • column calculations
  • connections
  • schedule
  • packages
  • list joins

Conceptualy what would be different:

  • Every group treated as a join (we wont implement an interface for this yet but it would simplyfy things when we do add it in
  • Groups would be re-usable and sharable between users.
  • Reconsider if popups are the best display medium for additonal info when rendering in mobile or in an iframe.

So possible record structure might be:

`

// Main form record
{
	id: 1
	datetime: 'yyyy-mm-dd',
}

// Group (id = 1) records
{
	id: 1
	parent_id: 1 // ref to form.id
	label: 'Warks',
	checkbox: {'value1': true, 'value3': true},
}

`

Elements could be repeatable if they're arrays:

`

// Group (id = 1) records
{
	id: 1
	parent_id: 1 // ref to form.id
	label: ['Warks'],
	checkbox: [{'value1': true, 'value3': true}]
}

`

''URI Structure''

Itegrate the idea of apps from the start and use REST style urls:

View a app called shop:

http://site.com/shop

View shop products:

http://site.com/shop/products/

View a product

http://site.com/shop/products/the-lord-of-the-rings/ (would require the slug to be unique)

Each page can define its main Global layout?

Might want to use

https://github.com/oJshua/mongoose-forms as a starting point - nice way to map mongoose models onto Form classes.

Ember.js with handlebars for front end display / rendering

Clone this wiki locally