Compare form generation with other frameworks about semantic_forms HOT 11 OPEN

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.

from semantic_forms.

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

from semantic_forms.

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

from semantic_forms.

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.

from semantic_forms.

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.

from semantic_forms.

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 .

from semantic_forms.

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.

from semantic_forms.

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 .

from semantic_forms.

Again, I don't agree as I think this architecture is harder to understand for an external developer. But you're the boss.

from semantic_forms.

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

from semantic_forms.

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

from semantic_forms.