jsonary-js / jsonary Goto Github PK

Subject should use setSubjectValue(). Target should check for subject value, and get data from document if it's undefined.

render() renamed to enhance()

Currently, only the affected item and its parent are updated, to avoid re-drawing all content on every change.

However, a better solution would be to notify all levels, but to put in a better default update function:

function (element, data, operation) {
    if (operation.affects(data)) {
        this.render(element, data);
    } else {
        var child = operation.getChild(data.pointerPath());
        if (child != undefined) {
            this.render(element, data);
        }
    }
}

(on the assumption that the jQuery-safe element-clearing logic is moved to the render() function)

Using this would be simpler than schemas.containsUrl(...) and might enable future optimisations in renderer-registration.

• types() should be equivalent to basicTypes(), and basicTypes() should be recursive
• extendsSchemas() should be replace with andSchemas() or allOfSchemas() or something
• basic type validation should be done directly
• anyOf() should be the source for the previous TypeSelector class, and should include any schemas from type (for v3 compatability).

There's now a "get started" bundle - there should be a guide for using it.

I'm currently tasked with making something like this work for a project. I'd love to share some details with you and seek lots of guidance. To do that, I would probably use a shared Google Doc or set of files for describing the communication between the server and client, plus an email chain for questions. That way we can add comments to the sample communication and I can figure out the best approach for tacking my eventual goal.

If that sounds good to you, my email address is [email protected].

Currently, definedProperties() returns properties from required as well. This is not correct.

Probably need a second function, knownProperties(), that includes results from required.

For example, particular formats (e.g. "date") might have customised value generation.

Code is on the x-display-order branch.

@Ognian - is this the kind of thing you were thinking about?

I wrote it as an extension defined in the renderers, not part of the core Jsonary library, because it feels like a renderer-specific concern.

Have a look at the diff - hopefully it should be fairly straightforward to see how it works.

Either:

• make this available as data.schemas().readOnly(), or:
• actually check this in data.readOnly()

Two issues:

1. data.schemas().indexOf(...) does not take account of $refs, and it should
2. Schema switcher's createValue() method needs to use getFull() to attempt $ref resolution before creating values.

After creating jData like:
jData = Jsonary.create(d);
jData.addSchema(...);
jData.renderTo('form');

what is the correct way to remove, deallocate everything,
delete jData;
is not enough?
there is a remove() but it looks like this is not enough too...

Create a type-selector interface (will involve schema coercion).

Actually, this could probably include the "delete" functionality. Objects and arrays could then just be concerned with adding things.

Let's say I have a schema created with createSchema()
and this schema has an
"id": "/laborvorschriften#",
inside that schema I have a
"$ref": "#/definitions/ParameterArray"
How to write a renderer filter which triggers only on the referenced part ("#/definitions/ParameterArray") since I would like to use for this part the TableRenderer ?

I thought that containsUrl would somehow match with "#/definitions/ParameterArray" but it looks like "url" is just the second parameter to createSchema()

Thanks a lot
Ognian

Add change listener. Register Jsonary.undo() and Jsonary.redo().

On change, store document along with patch. Have some method in patch/operation that makes them reversible.

When Ctrl+Z pressed, pop latest from undo list, calculate inverse, and apply (ignoring this in the change listener). Add original to redo list.

When Ctrl+Y or Ctrl+Shift+Z pressed, pop from redo list and apply (ignoring this in the change listener). Re-add item to undo list.

It's shiny. :)

Namespaces could be slash-separated

When registering, namespace can be a string (at which point it's added to all levels of the tree) or a list (at which point it's not).

Jsonary.render() then takes a third argument, which is the recommended namespace. It searches that namespace, then goes up the namespace tree until something matches.

Using links for editable data doesn't really make sense.

Hello,
having a schema like this

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "id": "/laborvorschriften#",
    "type": "object",
    "properties": {
        "parameter": {"$ref": "#/definitions/ParameterArray"},
        ...
    },
    "definitions": {
        "ParameterArray": {
            "type": "array",
            "items": {
                "type": "object",
                "required": [
                    "name",
                    "type"
                ],
                "properties": {
                    "name": {
                        "title": "Der Name",
                        "type": "string"
                    },
                    "type": {
                        "title": "Die Type",
                        "type": "string"
                    },
                    "additionalProperties": false
                }
            }
        }
    },
    ...
}

it looks like the $ref is ignored.
I did this by looking at:http://json-schema.org/example2.html

What am I doing wrong?
Thanks
Ognian

Include as submodule under the jsonary/ source directory.

• include json2.js
• Array.isArray()
• Array.indexOf()
• Object.keys()
• String.prototype.trim()

Other compatability stuff:

• replace setAttribute("class", ...) with className property
• Doctype headers - enable strict mode in IE, so position: fixed works

That way, things like additional data items could be part of the rendering context. We also wouldn't need that nonsense with uiStates holding the child uiStates.

Sub-contexts could be properties of parent context, but with "used" flags that are reset on re-renders, or something like that. Every re-render is a clean slate, and sub-contexts are only kept if they are referred to.

But that would cause problems with tabbed interfaces - render contexts for other tabs would be dropped on each tab switch.

They should also render HTML by default, not do DOM manipulation.

document.addEventListener('keydown', function() {...}) instead of the current window.onkeydown = ...

It might be useful later to be able to define additional helper functions, or renderer-specific settings, or whatever. This behaviour is probably expected by users.

The constructor should make a copy of the supplied object, wrapping render up with whatever else is needed.

Easiest way is probably a custom JSON format:

• Objects - title/description/properties/methods
• Functions - title/description/arguments/return/properties/methods

Set up quick-and-dirty editing API for local use.

Only in sections without tuple-typing applied, though.

I'm sure you can do that with onmousedown and onmouseover.

You should implement it with a "move" operation.

That way, you can override update(), and conditionally call this.default.update().

By default, assume API follows: http://tools.ietf.org/html/draft-pbryan-http-json-resource-01#section-5.5

If method is "PUT", and no schema supplied, default to editable copy of instance at the submission address.

If method is "PATCH", then default to editable copy of instance at the submission address, and submit the collected JSON Patch for the changes.

Some operations should by default present the response in a pop-up.

RFC 6570

Probably still want to maintain {@} for compatability, though.

Currently, there is no way for a renderer to render a text input as HTML, and get any sort of callback when the value changes.

The "select-basic-type" action does not return true, so no re-draw happens.

This means that for any instance with a schema, it forces all the children to exist.

Jsonary.config should be a Jsonary data container containing config parameters.

There are a couple of references to window.location which we should get rid of, and possibly some other obstacles.

You should also bundle up a release that doesn't include the rendering plugin.

Create a default renderer for JSON Schemas.

It'll be awesome, I promise.

1. It's not itself a renderer
2. It adds something to the Jsonary namespace.

• uses "console.log()" (not available in all browsers)
• </table></table> instead of </tbody></table>

At the moment, when a URL containing %23 is entered, it is placed unencoded into the fragment, but some browsers decode it when it is fetched.

Inside e renderer I'm trying to access the title property of a key in the schema
since i want to display it instead of the key
The following works, but it looks like a "hack" to me:

var keyTitle = subData.schemas()[0].schemaTitle;

what would be the correct way?

Actually, I haven't understand why there is a set of schemas and not only one schema?
Maybe I have to extend the schema List?

Thanks
Ognian

They aren't used.

Should have shortcut methods set(path, value) and get(path).

These methods simply wrap around .subPath(path).setValue(value) and .subPath(path).value().

All links should be attached to data - make sure "describedby" links are applied immediately, to correctly determine the document root.

http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-09

While you're at it, extract this and add it as a submodule (#10).

• data.basicType() -> data.type()

Remove existing use of:

• schemas.extendSchemas()
• data.indices(), data.index(), data.indexValue()

Can then remove old-style method names.

You can make it a dialog that sits on top of the item, filled with an independent data item.