Reporting

[nicklasb]

Ok, this is basically of topic from the get go, but i am just wondering if any others have the same thoughts:

The same way schema form validates and enables inputting data using the schema and forms, the same way, it should be possible to turn that process around, and use forms to layout JSON data. There are some nice plug-ins for making charts, and plugins for making pdfs and other stuff.

So I have seen fng-reports but that seems to depend on forms-angular, and I am thinking that there might be something from schema-form that is usable here.

As we now are considering a schema-form-builder, I am thinking about a reporting framework and visual builder.

I can't see that something like that exists for angular. Which was somewhat unexpected to me.

[davidlgj]

Interesting idea! Schema form is designed to use different "decorators", I don't want bootstrap 3 to be the only one (been tinkering with material, but hitting snags). And there should be nothing in the building part to stop this. Maybe just that right now you need a schema, but that could be made optional.

[nicklasb]

Ok. What I was thinking about was not that schema form uses bootstrap, I am thinking generally about the fact that angular-schema-form renders a layout. And that means it at some level has some kind of engine that takes the form structure and the data and translate that into markup.

It is at that level I am thinking that reporting could converge and use the same code base. Because a report does the same thing, with the exception that it doesn't allow editing.

There are some things that I think could be useful for both schema form and reporting For example, layout features, like different kinds of positioning and visual stuff.

What is needed by reporting is the ability generate headers, footers, lists and stuff like that. It is not very useful for schema form to be able to edit long arrays of complicatedly laid out data directly. Or perhaps that could be cool. I don't know.

Looking at the "decorators", I think that is an attractive and extensible solution, I see no problem with adding labels, layout-elements and stuff like that. I am thinking that much of the builder code as well can be used for both as long as the base is the same. Or maybe even the same.

Anyway, the thing is that I come from backend and applications development, and there, reporting is a huge thing, and we had expensive reporting components that could to lots of stuff. Especially, I was in the financial sector and there it was this major revenue stream. It amazes me that there aren't a multitude of them at the front end.

[davidlgj]

Ok. What I was thinking about was not that schema form uses bootstrap, I am thinking generally >about the fact that angular-schema-form renders a layout. And that means it at some level has some kind of engine that takes the form structure and the data >and translate that into markup.

Yeah, I didn't explain myself the right way :) What I meant to say was that the design decisions I did to support more than bootstrap 3 in the future probably should let you use it more generally than for just forms.

It is at that level I am thinking that reporting could converge and use the same code base. Because a > report does the same thing, with the exception that it doesn't allow editing.

Exactly at least static reporting that don't allow you to drill down etc.

There are some things that I think could be useful for both schema form and reporting For example, layout features, like different kinds of positioning and visual stuff.

What is needed by reporting is the ability generate headers, footers, lists and stuff like that. It is not very useful for schema form to be able to edit long arrays of complicatedly laid out data directly. Or perhaps that could be cool. I don't know.

Looking at the "decorators", I think that is an attractive and extensible solution, I see no problem with > adding labels, layout-elements and stuff like that. I am thinking that much of the builder code as well > can be used for both as long as the base is the same. Or maybe even the same.

I think this is possible too. Schema form basically builds it forms by looping through the form definition and creating a directive for each form object. Currently that directive is always the same the "decorator" directive, and that chooses and $compile's a template depending on the form definition type. (This might change though, since it turns out that its bad for performance, better to have one directive per type. Note that this is a flat structure, any tabs, fieldset or array type directive in turn renders the directives needed for its items. The validation part is all in the template so if you leave it out schema form don't complain, it just doesn't validate.

Actually it's basically a for loop for directives, so maybe it won't help that much... :)

[nicklasb]

Ok.

Oh, I am thinking completely static reports, drill-down and dynamic reporting is according to me of limited use in practice. Maybe I am a bit boring, but either I wan't reports that look good to capture a certain state for displaying to customers or management, or I want populated spreadsheets that people can play around with. The drill-down is more an interface feature, like part of a presentation.

Flat? You mean that it isn't nested or something? Isn't it nested if the things it loops calls their own, effectively creating a tree? Perhaps I don't understand?

Anyway, I don't think that anything more than a loop is needed, what I am after is that of all the solutions a reporting engine needed, all the basic issues should be solved already. This as reporting, with the lack of input and validation, would seem to be a subset of current functionality.

Yeah, perhaps one would want a some more stuff, but I'd just think that it could be built on top of this.

[nicklasb]

Heavily edited my latest post, might not wan't to go by e-mails.

[davidlgj]

Flat? You mean that it isn't nested or something? Isn't it nested if the things it loops calls their own, effectively creating a tree? Perhaps I don't understand?

What I mean is that the nesting is done by the directives, not by the "building" part of schema form, let me give you an example: The "building part" is here: https://github.com/Textalk/angular-schema-form/blob/development/src/directives/schema-form.js#L94

A form definition like this:

[
 {
   type: 'fieldset',
   items: [
     {key: 'name', type: 'test'}
   ]
 }

Becomes something like this:

<sf-decorator form="schemaForm[0]"></sf-decorator>

That's what I meant that it was flat :), the building part that is. But that might need to change, this way is a bit slow. It would be more performant to render the entire tree using transclusion for fieldsets etc.

The fieldset has a ng-repeat that renders its children, see https://github.com/Textalk/angular-schema-form/blob/development/src/directives/decorators/bootstrap/fieldset.html#L4 so that's how tree structures are done.

[nicklasb]

I see, that it is like super-un-flat to me. :-)

However, I kind of like that items are themselves responsible for themselves and their children and their scopes. Are there performance issues now? I have not encountered any serious ones?

[davidlgj]

i hadn't either... until now. We did a largish form that is actually more of an entire admin page... we styled the tabs type to look like a menu and made another one for each tab that looks like a side menu. The entire schema + form is something like 3000 rows of indented and prettified JSON. It takes many seconds to render.

I did some profiling and testing to get it faster and one big culprit is that I use one directive with a manual $compile inside the link. Every time a template uses an ng-repeat, like the fieldset or the tabs type, that link function and that $compile gets called. A "ordinary" directives template is only compiled once then cloned inside the array, much faster. But to do that I need to generate different directives depending on type.

I got an idea on how to do it, the working plan is to generate as much as possible up front and let transclusion to the heavy lifting, so the fieldset in the example above should instead be something like this when generated:

<sf-fieldset form="schemaForm[0]">
   <sf-text form="schemaForm[0].items[0]"></sf-text>
</sf-fieldset>

But that basically means that I need to find another solution for my $$value$$ hack, probably an extra watch per directive with inputs in them. I'm not sure how yet, but I need to speed it up :-)

[nicklasb]

Aha, and I suppose those seconds are at 100 percent CPU, too. You can't just simply memoize some of those functions?

[Anthropic]

@nicklasb is this at the point of being an enhancement now based on the discussion? Worth raising a more detailed issue specifically for an enhancement?

[nicklasb]

I don't know. If is a discussion, it would be nice to be able to have some kind of reporting format.