jmvanel
Compare form generation with other frameworks
Compare Scala code: FormModule, FormSyntaxFactory, Form2HTML
and form RDF specification: https://github.com/jmvanel/semantic_forms/blob/master/scala/forms/form_specs/foaf.form.ttl https://github.com/jmvanel/semantic_forms/blob/master/vocabulary/forms.owl.ttl
to other frameworks, and try to get some good ideas and be more feature complete and developper friendly:
- Ruby on Rails
- Symphony
- Play! Forms
IMHO, the main class should have several capacities:
- bind from object
- bind from request
- iterate over fields
- render as html div
- possibly some other kinds of render
And Each field should have accessible properties, such as value, name, id and type. Fields should also have a render method with a default widget depending on the type, but a different widget should be accepted. Widgets should be declared as independent objects, rendering a field as html or other formats. Developers should be given the option to define their own widgets.
This is quite an architecture shift I think, but that would make the library conform to the current use.
Yes, bind from SPARQL query would be nice. Otherwise, we have already:
- bind from object
- iterate over fields
- render as html div
- plus bind from OWL class, possibly combined with bind from RDF subject and with form specification
Each field (Entry class in FormModule) already has accessible properties, such as value, name, id and type, and more.
There is no render method , as Form2HTML.generateHTML() plays this role; and changing the FormSyntax instance with a different widget for some specific fields is possible. Widgets are conceptual display choices , and I found no use to add data to them. The WidgetType hierarchy is currently a sealed class, but I'm open to additions :) .
Yes but today it's not very clear (at least to me) how every elements are separated. I think there should be a clear separation between different classes:
- Form (which is called today FormSyntax if I'm not confused)
- Field
- Widget
All of them should have a render method. Form should have other listFields, bindFromRequest, bindFromData Nothing else should be used from the outside
The main thing is here in FormModule:
case class FormSyntax[NODE, URI <: NODE](
val subject: NODE,
val fields: Seq[Entry],
classs: URI = nullURI
)
that's a pure structural ( no behavior ) immutable class, that defines the form and its data contents.
The render function for FormSyntax is called generateHTML. and for a field (class Entry ) it's called createHTMLField . A field just has a WidgetType ; the Widget is not an object, and I see no reason to make one.
Yes but my point is precisely that the render should be a method of the Form class, itself calling the render of each field. That would make the whole architecture clearer imho.
render to be a method of FormSyntax, that would not be clean and modular; currently FormSyntax is just a form specification and is independant of any rendering platform like HTML, Swing, GTK, etc.
About renaming in Form2HTML generateHTML and createHTMLField to both render, I don't think that it makes things clearer, quite the contrary .
I disagree, but that may just be my opinion. I think from an OOP point of view, methods should be beared by the class it applies to, and in this case the render behaviour is just one capacity of the class. Having the same name is just a consistency matter, as one won't confuse Form.render with Field.render. And that's how it's done in Symfony, Django and Rails.
The OOP point of view leaves freedom as to which object does the job. Is this case, the job of rendering should be done by a renderer object, which in this case is an instance of Form2HTML .
Again, I don't agree as I think this architecture is harder to understand for an external developer. But you're the boss.
I don't want to do something oriented towards the framework developpers, but something friendly to the applications developpers, contrary to some other projects ;) .
To achieve this friendlyness, we can have an HTML oriented facade; let's talk about it next week :)
That being said, the facades we already have are CreationForm and TableView, and they are actually used in forms_play/ and https://github.com/jmvanel/corporate_risk