Salvage exising ideas

[ThomasPe]

I'm gonna try to get some life in here over from json-schema-form/angular-schema-form/issues/304 ;-)

I guess the first step would be to collect the existing ideas from all the different places and merge them here into a roadmap, right?

I really like @nicklasb's ideas for the GUI. Having a drag-and-drop interface is probably the easiest way to deal with more complicated things like arrays. https://github.com/nicklasb/angular-schema-form-builder

Also: would it make sense to create a Gitter for this repo or should we stay in https://gitter.im/json-schema-form/angular-schema-form-projects ?

Thoughts?

[nicklasb]

Hi Thomas,

First, that repo is just a fork of @mike-marcacci's original repo: https://github.com/mike-marcacci/angular-schema-form-builder , so it is mostly their ideas.

And to add more to this thread, @rowino's existing builder is at: https://github.com/json-schema-form/json-schema-builder

There is aIso a demo of here; at http://ralphowino.github.io/schema-form-builder/#/builder

The code looks nice and is vanilla ES6, which is good as we want people from all frameworks all to be able to contribute to it.

[nicklasb]

One thing I feel is important with the builder is that you should be able to use it as part of one's own solutions, for example I want to make it possible for my users to define their own structures.

[ThomasPe]

yes, absolutely! this is exactly what I need it for :D You should be able to use it just like ASF, perhaps by just setting an additional "edit mode" flag? An then just add the markup for the different panels.

<div ng-controller="FormBuilderController">
    <sbpalette></sbpalette>
    <form sb-schema="schema" sb-form="form" sb-model="model"></form>
    <sbinspector></sbinspector>
</div>

[nicklasb]

Something along those lines, yes. I would guess that is what @joelwkent is looking for as well.

[nicklasb]

WRT your example, I'd like to mention that I would like to keep the implementation framework-agnostic and ES 6. Not sure how it should be implemented smoothly to for example work nicely both as an angular directive and react-component.

[ThomasPe]

So I guess it should be based on https://github.com//json-schema-form/json-schema-form-core, right? Not really sure right now how one would architect this, either. You would have to write a small wrapper for both, right? How does (or will) ASF do this?

But you're right, this should certainly be the goal.

[nicklasb]

Forget about the vanilla ES6 stuff I just said. How embarrassing. I just realized that the builder actually is a full blown angular application. Looking at the code, I have NO IDEA where I got that it was pure ES6 from.

So making a pure ES6 version of it is obviously not doable. Instead, the nearest thing we can do is, as you said, to see if we can base most of it directly on json-schema-form-core, which is ES6, and then make thin angular or react-wrappers around it.

[ThomasPe]

Is the core already at a stage where it makes sense to develop the builder on top of it? Does ASF is it as well? I got fooled by the *.es6 files as well :D

[nicklasb]

Actually, I do not think we should build on that until 1.0 is released. (I suppose it was the .es6-ending that put me as well on that track :-) )

So if I could make a suggestion, it would be to now focus on what we want to do with it and try and break down that to a road map.

1. We seem to be certain that we want to use it as a component inside our applications to enable users to dynamically design structures.* I suppose that means making into a directive that takes the relevant params.
2. We also seem to feel that it is important that we do not leave of other architectures that also may want to have a built-in designer, like react.js. So we probably want to break out some part of it. However, there may not be that much to break out if we use the new code directly. It starts to use Angular deep down. And perhaps that is as it should be, I don't know.

* There are some security issues with that, which should be mentioned in the docs. Users can, if it isn't sanitized, insert scripts into the descriptions.

[ThomasPe]

I agree. I guess the first step would be to extract the important stuff from the existing app and making that into an easy to include angular module? / directive?

Since the code is already vanilla js I dont think we need a grunt task, right? The one included for the test app throws a lot if errors for me anyway.

[nicklasb]

Grunt? Isn't it gulp? And it needs building to work.

[ThomasPe]

Of course, no idea why I keep mixing up those two... What I'm trying to say is - I don't really see a need for requiring the library to build since all it does is renaming file endings (.es6 to .js) and switching statements for the actual code. As far as I can tell none of the code required for the library is being transformed (like you would do with .less for example). Wouldn't it be easier to just remove the whole gulp process and just save and include the files how they are supposed to end up?

[nicklasb]

Well..no, I don't think so, we will need to add testing and stuff like that, and that is usually handled by the build tools. Also, it is possible that we want to add different builds for minified, deployment, wrappers and so on.

[ThomasPe]

hm, I guess you're right. I'm fairly new to this whole process as you can probably tell ;-)

So what would be the next step to extract a reusable library from this app?

[nicklasb]

Yeah, basically, I suppose.

[ThomasPe]

so, I finally managed to get everything into a working directive. There's still a lot of code-cleanup, bugfixing and restructuring to do though, so it'll still take a bit until I'm confident enough to create a pull-request.