Giter Club home page Giter Club logo

ajja's Introduction

ajja's People

Contributors

dependabot[bot] avatar florianpilz avatar greenkeeper[bot] avatar greenkeeperio-bot avatar sallner avatar sweh avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

ajja's Issues

Make current github shim the development repository.

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:

  • Adding grunt tasks for minification, jslint and running tests
  • Making tests runnable without the gocept.jasmine integration

This should be done before further development is done, therefore priority "critical".


Should not fail silently when selector was not found

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.


Make template handling more useable

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.


Searchable select fields via Chosen

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.


Provide template for hidden input values

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>

Allow widget configuration via options dict and data attribute

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.


ListWidget: Provide file upload widget using Dropzone

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);
});

Use progressive enhancement for ListWidget

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.


Remove distinction between `url` and `save_url`

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.

ListWidget: `add_item` does not throw error when malformed response was given

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.


Refactor CSRF token behaviour

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.

Placeholder for all inputs / actions

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.


ListWidget: Document API available via data attributes

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.


Make it easier to reload a widget if another widget was changed

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:

  • an 'after-save' event for each field
  • API for reloading a single field

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.


Reuse place-holder elements

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.


Add save button to form that waits for server side validation before send

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.)


Replace setTimeout in tests by waiting for events

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.


Configurable framework integration

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.


Clarify meaning of form.data (and fix the implementation)

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.


Extract TableWidget from project

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.


Implement jsform as a jQuery plugin

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.


Remove dependency to Bootstrap and jQuery UI

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.

Make autosave optional

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.


Rename gocept.jsform

It's not a very catchy name and strongly coupled with our company.

Thoughts so far:

  • Bread (from BREAD, an alternative acronym of CRUD)
  • Slime (since CRUD means dirt and dirt leads to ...)
  • It should be clear how to write the name when hearing it.
  • It should somehow contain or undermine the basic idea of the library. So best start with 1 sentence describing the library and find a name starting at that sentence.
  • The name should be unique, so ranking high in Google is easy and we do not compete with usual nouns.

Explain and maybe clean up events and deferreds

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.


Handle validation errors on loading form data

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.


Make gocept.jsform a NPM package.

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).


Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.