projectcaluma / ember-caluma Goto Github PK

Currently we have an initial load time of approximately 15000ms on a fast device and a 1GB/s internet connection. This is way too slow.

This happens, because we fetch all the documents with their answers and associated forms and questions nested. We should fetch all documents with answers first and then the needed forms with questions. The tree can be built in javascript, this should not be too expensive. Also the second request can be cached which should improve the performance drastically.

Related issues:

• projectcaluma/caluma#376
• projectcaluma/caluma#474
• projectcaluma/caluma#476

Related PRs:

• projectcaluma/caluma#473
• #295

/cc @winged @czosel

Questions exist in caluma also without being associated to a specific form. It should be possible to manage (CRUArchive) questions without opening a specific form first. Especially questions which are not associated to any form are otherwise "lost".

... and not just rely on the browser locale. This should allow creating multilingual content in the form builder.

We need a field where calculations can be desplayed. The field shouldn't be editable in the form.

It seems the validation for required fields checks for a true value, which leads to an error if we want to save 0 in an integer field. It should only throw an error if the field is truly empty.

I thought we had an issue to track this already ... but I didn't find any.

Backend support landed it projectcaluma/caluma#353

The current state of our documentation is absolutely poor! We need to drastically improve the documentation at least of the components we need the most (e.g cf-navigation, cf-form)

It is no possible to save a float in a min/max field of a float question. Expected would be that it is possible to set a float as a min/max value.

For example:
Max value 12.5

Values of placeholder and information text of all questions and options of choice/choices questions get a default value assigned, overwriting the given input.

I think it would be better if we rename the "isHidden" field to "isVisible". When a user wants to build a form, the form should show specific fields if a radio button or a checkbox is clicked and not hide them.

For example:
'nutzungsart-wohnen' in 'nutzungsart'|answer
is more understandable than
!('nutzungsart-wohnen' in 'nutzungsart'|answer)

E.g. for the isHidden field we need to implement a simple JEXL expression editor. The JEXL expression can use the values of other questions (with a transform).

If the main form contains only FormQuestions, it would be nice to automatically redirect to the first subform that actually contains questions that can be filled out.

See projectcaluma/caluma#212 for how it is implemented in Backend.

The title pretty much says it all: It would be nice if cf-form would show a loading spinner while the form is loading.

projectcaluma/caluma#360 implements format validations. This issue can be used to track the frontend integration:

• Form builder integration
• Form rendering integration

#179 (review)

When a new row is created, it should be possible to just close the modal without saving the row.

When the Widget Type selector is used and a different value is selected, the new value doesn't get displayed.

When a table was closed without clicking on the save button, the table doesn't reopen if you click on the edit button.

In the overview of all forms we should think about implementing some kind of "tree view". Forms can be nested so there should be a way to see this the way it is structured in reality.

CC @kaldras @czosel what do you think about that?

The best way to add the namespace to the input field would probably be to write a render component for the namespace input case. The solution we have now works, so this is just a optimization proposal. ;)

Currently, creating a table question without selecting a row form does not raise a validation error like it should.

From projectcaluma/ember-caluma-utils#125

The atob helper does not only call the native atob function but also does a splitting of the id. With the current name it is confusing why not just the native function was used. Better rename the helper to decodeId or something like this.

It would be great if the displayed columns in a table were configurable in the form builder (currently we're always rendering the first 4 columns). For storage, I'd suggest using meta on the TableQuestion. The most basic implementation I can think of is just a static list of question slugs. This list could potentially run out-of-sync with the form backing the table, which something I wouldn't solve in a first version.

A more advanced version would allow for dynamic column contents, e.g. two field values joined together in one column (might be possible using JEXL). But that seems like something that we better leave out for the moment.

For the basic version, I'd expect a checkbox group with all the table's questions in the form builder UI.

/cc @fkm @kaldras @anehx

From projectcaluma/ember-caluma-form-builder#39

See projectcaluma/caluma#255 for backend implementation.

A few things to note:

• A copy of a form will reference the same questions as previous forms
• Copy of questions will reference the same options as previous questions.

Both of this is important that jexl expression are still valid in a new form context.

After a copy has been made user interface has to guide user so it notices when a question resp. option is updated on all form copies or whether the question is only added to current form.

This is especially true for options as user interface looks at them as not global but in the backend they are because of keeping jexl expression valid and multi language support.

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (github>projectcaluma/renovate-config)

Just like in the precursor of this project, it would be nice to display "previous" and "next" buttons below each form.

Currently we can't navigation to a root form which haves subforms. However, our data structure would allow a form to have questions but also subforms. We can solve this issue in two ways:

1. Allow navigating to forms with questions and subforms
2. Disallow creating a form with questions and subforms

I'd personally prefer option 1

Currently host apps with [email protected] can't use ember-caluma because we still use [email protected].

We should update it according to those instructions

When clicking on an info icon in a table modal, the info modal opens and closes the table modal automatically. Displaying the info modal on top of the table modal would solve the problem, but it's quite ugly and probably also not meant to be done with uk-modal. If we decide to give uk-drop another try, we have to figure out the sizing/formatting issues that lead us to using modals earlier.
/cc @fkm

Backend support for this landed in projectcaluma/caluma#333

While initializing the form builder it should be possible to define a namespace which is then added to each slug that is created in this session. For example:

namespace: "foobar"

Question slug of question "blubber" should be: foobar-blubber

It would be nice to see the namespace as non-editable text before the slug field, so the user knows how the final slug looks.

Sometimes a radio button in a table should show a new question outside of the table. This function is actually not implemented.

Backend issue: projectcaluma/caluma#320

• Form builder integration: New field "data source"
• Form rendering integration

... cause issues. Sometimes clicking "save" doesn't do anything, sometimes an error is returned.

Ember Caluma should not dictate the available locales.

Often, typically at the end of a form, there are one or more questions that ask the user to confirm something (terms of service, privacy policy, ...). Those questions usually consist of a single checkbox and a label, e.g.:

• I have read and understood the terms of service

The current MultipleChoiceQuestion doesn't support this use-case very well: It requires a global question label which will be displayed on top.

The easiest way to bring this into the caluma form would be a "Hide label" option for Choice and MultipleChoiceQuestions. Then it is possible to add add a "Confirm" type of question as a MultipleChoiceQuestion with a single option.

Instead of resolving custom rendering components by their slug (which feels a bit magical for our users), we could expand the usage of "display types" (currently hard-coded for choice / multiple choice fileds) to allow registering custom question type => display type mappings, which could then be displayed in the form builder.

For developing a complex form configuration, isHiddenexpressions currently have to be set using the API. This is tedious, because the API requires several fields which are necessary for the initial create, but not actually needed for the update (e.g. options in ChoiceQuestions).

Maybe we could add a text field for isHidden which is part of a "advanced settings" section of the question form? The advanced settings section could be hidden by default and only shown when activated (toggled), maybe also featuring a little warning like "Use at your own risk..."

It seems that the same field reference is passed to all questions. But this also includes the answer property on the field.

I'm not sure, where exactly this happens but to illustrate the problem here's a screenshot showing the relevant tree / values.

The hint would be displayed below the input element and is contains help text for the user. We should consider using a simple markup language (e.g. Markdown) to support things like links inside the help text.

If the same subform is used in multiple main forms, it would be handy to determine the "context" by exposing the form slug in the JEXL expressions. Like this, one can make a specific field hidden/required only in specific form contexts.

The length of labels and slugs for checkboxes is limited. If a label is too long a error message shows up ("invalid options") and the save-button becomes disabled. I think it would be better to allow longer labels and slugs.

Currently, if we add a question to a form, we load all of the available answers per default. Since we have tons of available question in some projects we should limit this per default to e.g. 10 results. This should not be a problem since we offer a search functionality. We could also implement a "load more" button for users who don't really know what they want to add 😉

In order to allow "unarchiving" things, there needs to be a way to find archived things in the first place. Maybe something like a "Show all forms" or "Show archived forms" link below the form list?

The values of the dropdowns do not appear although the arrow change it's direction.

The namespace which was introduced in #97 is just added to the question slug but not the form slug! To make ember-caluma fully namespace aware it should also be added to the form slug.

In one of our projects we currently have subheadings inside forms. Should we add a feature to caluma that allows adding "non-field" / "decorational" content to forms?