is not used any more and exists only for history. Post new tickets on the Github account. n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Opened 12 years ago

Closed 9 years ago

#1072 closed enhancement (fixed)

Better flexibility in jForms

Reported by: laurentj Owned by: obs
Priority: normal Milestone: Jelix 1.5.0
Component: jelix:forms Version:
Severity: normal Keywords:
Cc: andrea.iacoponi@… Blocked By:
Blocking: Documentation needed: no
Hosting Provider: Php version:


It is difficult to support new control in an xml file of jForms, without hacking the core. We should change the architecture of jforms in order to support a new kind of plugin, which will allow the jforms parser to parse new elements and to generate new jformscontrol object.

Builders should be also more flexible. We should have a class for each king of control to generate the corresponding content, so we could have also some plugins to generate content, dedicated to a specific control. It will be easier to do it (instead of creating a plugin inheriting of a builder...)

Attachments (1) (49.7 KB) - added by aiacoponi 11 years ago.
Proof of concept. Only limited capabilities.

Download all attachments as: .zip

Change History (12)

Changed 11 years ago by aiacoponi

Proof of concept. Only limited capabilities.

comment:1 Changed 11 years ago by aiacoponi

  • Cc andrea.iacoponi@… added

I proposed Laurent about this enhancement.

I wrote a piece of code to demonstrate an alternative way to implement the jForms controls. Unfortunately I am still not so smart to use Mercurial and patches but I am going to learn. The uploaded archive contains selected replacement of the Jelix library ver. 1.1.5 (forms and plugins folders). The code may only parse and generate "input" and "submit" tags, and is based on the "htmllight" builder.

My approach was to concentrate into the "plugin" either the XML form parsing and the HTML generation. The basic idea is that if I need to develop a new jforms control, I only have to code my own plugin and to enable it in the configuration file. The final result is that the "plugin" could understand its own XML file description of the form and generate the corresponding controls. Probably, all plugins will share a similar forms description syntax also because it will be natural to copy a whole plugin code to start developing a new one. This way should permit to use different JS libraries in generating more dynamic HTML code beeing free to implement new XML tags and attributes.

Laurent remarks are that this approach will break the MVC logic as the parsing of the xml is the "Model" part of jForms while generating is the "View" part. As far as I can understand, forms XML files contains already some "view" specification; <secret> tag, for instance does not only relate to a textual string, but also specify implicitly the display properties of the field (i.e. hide typing).

Drawback of approach I proposed is that common code parts have to be cloned between "plugins"; this applies to XML parsing and, probably, also to HTML generation. It may pose problems in code maintaining. Also, change of plugin may cause malfunctioning in the program, because XML forms may rely on a specific XML syntax. But I suppose it is not a real issue; as said before most of the syntax may be shared between the plugin, and it may be foreseen a "compatibility" procedure to fall-back to basic controls if the "plugin" does not support the one specified (i.e. if my form use a <autocomplete> control that is not handled by my 'plugin', it will substitute the control with a simpler <input> control).

It is only an idea: I only hope to have contributed to the discussion.

comment:2 Changed 10 years ago by laurentj

  • Status changed from new to confirmed

comment:3 Changed 10 years ago by obs

  • Owner set to obs
  • Status changed from confirmed to assigned

comment:4 Changed 10 years ago by obs

Here the github branch used: github branch

comment:5 Changed 10 years ago by laurentj

I think we should provide only plugins for builders (and improve builders). The current XML grammar is enough I think (however we can improve it with things like <switch> etc ...), and plugins for the XML will be too complex.

I think that most of time, we only need to control how the HTML is generated, and probably too, how the content is checked after the submit. We could provide a plugin system for builder, to allow plugins to generate HTML/JS content during the display of the form. So, for example, an HTML editor could be used on an <input> element in jForms. Having its own element (<htmleditor>) could be not usefull in fact, if we could have the ability to indicate filters on <input>. So we could bring too a new attribute filter or whatever (in an other ticket). And then we could use <input> for any "exotics" HTML render.

comment:6 Changed 10 years ago by obs

I understand the XML compilation and the jForms displaying plugins part(it's a very good idea/vision), not the "content checked after the submit" part.

When i want to add a totaly new element (like a GPS position map) do i need to add a new jDataType in lib/jelix/utils/jDataType.class.php ? Or will it be a plugin too ?

comment:7 Changed 10 years ago by laurentj

For content check, new datatypes etc, it will be an other patch, an other ticket. I propose here to do only a plugin system to generate html of a control. Here some specifications: rfc/jforms-controls-plugins.

comment:8 Changed 10 years ago by obs

  • Blocking 1445 added

comment:9 Changed 9 years ago by obs

Commit to trunk

Laurentj, we may close this bug when jelix 1.5 is released ?

comment:10 Changed 9 years ago by laurentj

  • Milestone set to Jelix 1.5
  • Resolution set to fixed
  • Status changed from assigned to closed

comment:11 Changed 9 years ago by laurentj

  • Blocking 1445 removed

(In #1445) à priori, il s'agit d'un dup du 1072...

Note: See TracTickets for help on using tickets.