See GitHub Readme Stats for an explanation of the stats above.
sweh / ajja Goto Github PK
View Code? Open in Web Editor NEWJavaScript library for simple creation of forms and display of collections
License: MIT License
JavaScript library for simple creation of forms and display of collections
License: MIT License
See GitHub Readme Stats for an explanation of the stats above.
Originally reported by: sweh (Bitbucket: sweh, GitHub: sweh)
The bitbucket repo will be left as the fanstatic integration package of the gocept.jsform JS-Package.
This involves:
gocept.jasmine
integrationThis should be done before further development is done, therefore priority "critical".
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
When instantiating Form
or ListWidget
both use jQuery to retrieve the parent node. However, jQuery allows many operations on an empty list. Therefore providing a selector that does not match any node will not raise an error! It just does not render anything or raises an error so far away from the selector, that it is hard to see where the problem lies.
Thus we should check during __init__
if the given selector returns any node, otherwise raise an error.
Originally reported by: Thomas Lotze (Bitbucket: tlotze, GitHub: tlotze)
Form and widget templates can be influenced in a variety of ways, and providing custom templates requires their element ids to be specified via form options. The whole story should be cleaned up (probably dropping the feature of accepting a template text itself via options) and simplified, so that it is, for example, possible to override a template default with the same id.
Done:
"It might also be interesting to be able to use the content of the place-holder element itself as a template." -> It is now possible to specify an empty string as the template id, meaning that the form node is used as is.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
The JS library https://harvesthq.github.io/chosen provides really good looking select widgets that can search through available options. It also fits in nicely with Bootstrap. The question is whether we want to incorporate another JS library into the core of gocept.jsform
and provide this "superior" select as default. Or if we want to stay bare bones and keep the usual HTML select widget.
Integration is really easy, just call $('#field-to_recipient select').chosen({width: '100%'});
on a select template.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
Only the template gocept_jsform_templates_string.pt
has the Bootstrap class form-control
. But this class should be on other templates, too. Like textarea for example. Before we become framework agnostic, we should at least become framework compatible.
Currently JSForm
expects an ID without #
(form
), but ListWidget
expects an ID with #
(#form
).
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
Currently we are using a custom template to add the CSRF token to the body via a hidden template. Even though this specific need may be eliminated by #17, there are use cases where you want to supply additional body fields that are not visible to the user.
Therefore the core should provide a hidden template, rather doing it anew in every application.
#!html
<script id="hidden-template" type="text/x-template">
<input type="hidden" name="{{name}}" data-bind="value:{{name}}" />
</script>
Originally reported by: Michael Howitz (Bitbucket: icemac, GitHub: icemac)
If the value is a number gocept.jsform
tries to use a template named gocept_jsform_templates_number
which it does not find because it is not delivered with gocept.jsform
.
Additionally the browser renders a cryptic error message that Handlebars got undefined
as template.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
Currently nothing happens.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
Currently gocept.jsform
is fully localized, but ListWidget is not. We should provide the same API and translate all texts currently available.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
Currently some configuration is supplied via the options dict when creating an instance of gocept.jsform
, other options are read from the template via data-attributes.
It would be nice if all widget specific configuration can be done both ways, thus gocept.jsform
has to check the options dict and the data-attributes of the template. The documentation should tell that both ways are supported and which is preferred if both are given.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
In one project we have used Dropzone to upload files. Each file generates a list entry in ListWidget, thus additional information can be displayed / edited. This seems to be so useful, we should consider integrating it into gocept.jsform
.
Our template inside the project:
#!HTML
<div class="field form-group">
<label class="col-sm-3 control-label">Dokumente</label>
<div class="col-sm-9">
<div id="documents-list"
data-collection-url="${documents_collection_url}"
data-template="document-item"
data-form-template="document-edit"
data-form-options='{
"title": {"label": "Titel"},
"category_id": {
"label": "Kategorie",
"source": ${category_source}}
}'
data-modal-title="Dokument bearbeiten">
</div>
<div id="upload" class="dropzone" tal:condition="not view.readonly">
<div class="dz-message">Bitte Dateien hier ablegen.</div>
</div>
</div>
</div>
And JS to set it up:
#!javascript
var widget, dropzone;
widget = new gocept.jsform.ListWidget($('#documents-list'), {
default_form_actions: []
});
widget.load();
Dropzone.autoDiscover = false;
dropzone = new Dropzone('#upload', {
'url': '${upload_url}',
'headers': {
'X-CSRF-Token': $('#csrf_token').val()
}
});
dropzone.on('success', function (file, response) {
widget.render_item(response);
dropzone.removeFile(file);
});
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
We extracted the ListWidget to create a list of elements, which can render a form each using a modal dialog. However the concept greatly differs from gocept.jsform
: Rather having good default options for almost anything, the ListWidget requires you to give all information up front. To be more specific: Only fields that have a given label are shown.
We should unify the approach used, so both (gocept.jsform
and ListWidget
) use progressive enhancements.
In order to get the Form-API more REST friendly, the save_url parameter should be replaced with a generic url parameter for save and load of data.
For backwards compatibility, the first parameter to the Form.load() function should stay as is (data or url
), except that providing a url as data and a url in options should result in an error.
If data is provided directly, url must be provided in the options.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
When using a CSRF token for security, we currently have to filter out the CSRF field from the body on server side during save. It would be better to submit the CSRF token via a Header field, e.g. X-CSRF-Token
.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
When adding an item to the list, a PUT is done on the server. The expected response must be a dictionary with target and content (given as {resource: ..., data: ....}
). However, this expectation is not enforced, leading to errors way deeper in the code. Therefore this signature should be checked explicitly, so the developer knows very early that he returns a malformed JSON response on PUT.
Currently, gocept.jsform looks for an input field (usually hidden) with the id csrf_token to find the csrf_token which will the be send with every save request.
The user needs to append this hidden input by himself. A better approach would be to filter the csrf_token from the initial form data and render the necessary hidden input field automatically.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
When overwriting the default form template, it would be of help if we could say "insert all input fields here" rather listing them one by one. The same goes for "insert all actions here".
This is helpful, since the inputs are added to the bottom by default. So a form with a save button would have the input fields below the save button, except all input fields are listed one by one above the save button.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
The options that can be given into __init__
are already somewhat documented. However, everything concerning data
attributes is not documented at all. In the ListWidget, this is used to define which template is used for the list items, which title is displayed in the modal and so on. This must be documented.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
Currently if I have a form field which is dependent on another form field, I must register a handler for the onchange event, which registers a done handler on every change to reload the dependent form field. This will look something like:
#!javascript
$('#field-fahrzeugtyp').change(function(e) {
self.jsform.field('fahrzeugtyp').data('save').done(function() {
self.jsform.reload_data(function(data) {
self.jsform.set_data(data);
self.jsform.render_widget('bauteile', data.bauteile);
self.jsform.update_bindings();
});
});
});
Since this is a pretty common Use Case, I would prefer a shorthand for this. Something along the lines of:
#!javascript
$(self.jsform.field('fahrzeugtyp')).on('after-save', function(e) {
self.jsform.field('bauteil').reload(); // load data & render
});
This requires two independent pieces of infrastructure:
Doing the latter by loading the data for the whole form may not be optimal, either. This, in turn, requires some thought on specification of the REST/JSON interface design in the first place.
Originally reported by: Thomas Lotze (Bitbucket: tlotze, GitHub: tlotze)
The place-holder form and widget elements should be reused instead of substituted with the expanded templates. This allows for easier access to the DOM elements, associated objects and event handlers at any point in time. Also, it will be easier to attach data values that are syntactically difficult to supply via a template.
Originally reported by: Thomas Lotze (Bitbucket: tlotze, GitHub: tlotze)
Widget configuration is optional and falls back to value-type sniffing. This will obviously break with fields that may have a null value. When loading values, it should be considered an error for a value to be null and at the same time have no widget configured.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
Currently the class add
is applied to the button, but this is way too general and might interfere with existing CSS.
Currently if tabbing fast through a large form, an auto-save request is performed for any field (even if no changes were made). Due to performance, we should avoid saving a field without changes.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
When using a form with a save button, you currently have to manually check that all fields were successfully saved before submitting the form. It would be great if gocept.jsform
provides a custom save button, that by itself calls save_remaining
and waits for successful responses.
There already is some support build into gocept.jsform
to do so, but the integration must be done manually in each project. Very cumbersome, since this behaviour is needed in almost any form. (When typing into an input field and clicking save before it lost focus you need to make sure the filed was saved before performing the submit.)
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
Due to changing to a new version of Jasmine we had to rewrite all async tests. To get back to a green bar we took the shortcut and often replaced runs
and waitsFor
with stupid setTimeout
blocks that will wait for 100ms rather waiting at most 100ms. This slows down 30% of all tests.
To speed up tests again, we should try to replace those blocks with proper event handlers, i.e. expect
and done
are called inside an event handler that waits for the previous action to be completed. It might be required to inject more events for testing.
Originally reported by: Thomas Lotze (Bitbucket: tlotze, GitHub: tlotze)
gocept.jsform should strive to be framework-agnostic (which it is not at the moment, as some details happen to be too much inspired by bootstrap 3, such as the CSS class for errors being named "danger"). This requires configurable framework integration so that DOM structures and CSS classes may be adapted to whatever HTML/CSS framework the application uses. It will probably be a good idea to have hooks rather that simple values in many places. It may also turn out that different kinds of fields may need different field wrappers to be more flexible while still using the basic widget implementation from gocept.jsform.
Originally reported by: Thomas Lotze (Bitbucket: tlotze, GitHub: tlotze)
Forms have a data attribute that is a dictionary of the field values. The code looks like the expectation might be that this dictionary is updated when fields are changed, which is, however, not true.
Either the data dictionary should disappear altogether, or be fixed such that it does reflect the current form data. In the latter case, a good point in time during the saving steps needs to be determined, i.e. it needs to be well-defined whether the data dictionary reflects the UI state or what the form assumes should be the server's state.
Update: The data dict is now updated when saving a valid form value. This means that it reflects a validated UI state. This fact needs to be documented in the code and tests need yet to be written.
Originally reported by: Thomas Lotze (Bitbucket: tlotze, GitHub: tlotze)
Select and multi-select widgets may have an empty option which is currently simply a part of the widget template. Since this creates the need for these templates to be replaced completely in order to turn off the empty option, the latter should be made optional.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
Besides the ListWidget we also have build a TableWidget (and a GroupWidget) in a project for Verdi. They build upon the ListWidget and it seems like we can reuse the TableWidget in an upcoming project.
The TableWidget renders a table, which is compatible with http://datatables.net and we also provided Bootstrap like styling.
Originally reported by: Thomas Lotze (Bitbucket: tlotze, GitHub: tlotze)
A jQuery plugin is the expected idiom for creating something interesting on top of a DOM element. This will require keeping the form element and augmenting it instead of substituting it with the expanded template. This, in turn, allows for a better way to access the form object and register jsform-related event handlers even before the form is created.
Bootstrap is used for modal dialogs. We are not sure about jQuery UI, maybe the styling used for the accordion. We should definitely get rid of those dependencies and provide easy solutions instead. For example the form should render below the ListWidget
rather using a modal etc.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
Currently save_remaining
triggers a save event for each field and also displays an error message for each field. Maybe that could be optimized to save all fields in a single request.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
Currently the width of the modal dialog is fixed. Therefore longer labels overlap the input field. Maybe we can / want adjust the width automatically, depending on the length of the label?
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
Currently the form always uses autosave, thus you must adjust your model to not contain required fields to use gocept.jsform
. This is not very programmer-friendly. We should also allow to disable autosave, thus a save button is used to submit the form.
The approach to use no autosave is very helpful when all options and values are given up front, rather relying on a JSON API on server side. Maybe we should render the save button automatically when autosave is disabled.
It's not a very catchy name and strongly coupled with our company.
Thoughts so far:
Originally reported by: Thomas Lotze (Bitbucket: tlotze, GitHub: tlotze)
Events and state of the form are communicated by either triggering Javascript events, manipulating Deferreds, or sometimes both. It should be clearer and better documented why these things are done the way they are done; it just might turn out that things can be made simpler.
One example is the signalling of the fact that a form has been loaded. This uses both an event and a Deferred, with the latter being there at least for testability according to the comments.
Originally reported by: Thomas Lotze (Bitbucket: tlotze, GitHub: tlotze)
Validation is being done by the server and validation errors are notified only after saving the respective fields. This is the reason for the whole save_remaining thing, so before leaving the form the application has a chance to query the server for remaining validation errors.
It would be better to send validation information along with the initial data (which would require a different data structure to be loaded into the form) and consult that when leaving the form, and maybe also when starting to edit a field.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
Currently I have to provide a really long name to choose a default template, e.g. template='gocept_jsform_templates_multiselect'
. Is it possible to provide shorter names for the default templates, i.e. just template='multiselect'
?
Originally reported by: sweh (Bitbucket: sweh, GitHub: sweh)
Follows #42.
gocept.jsform should become a NPM package. One main benefit is that we can use require
to include local and external resources and we can use gocept.jsform as a resource in other NPM based packages.
In order to stay compatible with bower, which we use as the package manager for the browser, we need a compile step for grunt (e.g. browserify or webpack).
Originally reported by: Michael Howitz (Bitbucket: icemac, GitHub: icemac)
When referencing a template which does not exists Handlebars complains that it got undefined
as parameter for a function.
Expectation: Test whether the template exists before handing it over to handlebars. Bail with a helpful error message if a template with the given ID cannot be found.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
We should separate the save_url
into save_url
and autosave_url
. The former is called when submitting the form and the latter is used for autosave using a JSON API. This is important for some use cases like sending an e-mail based on form input, since that triggers a completely different action.
Originally reported by: Florian Pilz (Bitbucket: florianpilz, GitHub: florianpilz)
We are currently using HTML template files. However, this means that we need to go an extra mile when using the templates via bower & bowerstatic, since normally just JavaScript files are included.
The easiest solution would be to use JS files to deliver the templates.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.