critique of vibe.d

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 10 July 2014 at 07:56:43 UTC, Jacob Carlborg wrote:
> To me that sounds a bit backwards.

I can go both ways, depending on the design of the form and how 
many helper tags we decide to use for the project.

My dom library doesn't dictate how you do it, of course, it just 
provides access to the html structure and has functions to help 
build one. But among the functions I've written for this are:

createAutomaticForm, which is found in my web.d module. It takes 
a D function signature and creates a form to call it, using 
static type info to generate the appropriate inputs.

This is a really old demo but still shows the principles:

http://arsdnet.net/cgi-bin/apidemo/add-some-numbers

That form is generated from "int addSomeNumbers(int a, int b);" 
The URL routing, field names, and types are pulled out of the 
identifiers used in D.

http://arsdnet.net/cgi-bin/apidemo/get-a-box

This one is "Element getABox(Color color);" with "enum Color { 
list here... }". Enums are rendered as <select>.



I find this is really convenient to quickly throw something up 
(web.d will do it automatically for any exported function that 
doesn't have a custom form function), but real web designs tend 
to need more flexibility so it doesn't do everything.


I have three other solutions too:

1) Just write the HTML form manually and fill it in with dom 
helper functions. This has become my preference in a lot of 
cases, it is really easy.

<form id="foo">
   <input type="text" name="field" />
   <textarea name="other"></textarea>
   <select name="auto_list" 
data-options-from="some_backend_item"></select>
   <select name="list">
      <option value="whatever">Cool</option>
   </select>
</form>

And so on and so forth. A lot of people don't like html, but I 
don't mind it at all; especially once you start using html5 
attributes, it is fairly concise for this stuff.

Another thing I like with this is the designer can write it with 
just a plain browser, no need for the whole backend 
infrastructure just to see some quick tweaks. Helps a lot when 
they are working offline too.

Filling data is easy. Either use the functions directly:

auto form = document.requireSelector!Form("#foo");

foreach(k, v; your_data)
    form.setValue(k, v);


Or, if you are using my database.d with dom.d, relatively recent 
versions include a fillForm function:

fillForm(form, your_object, "object_name"); // object_name is 
used if the function takes a struct rather than individual items 
- another relatively new feature


To fill in data from a form, you can most easily use my 
DataObject class from database.d which doesn't take a hash 
constructor like Ruby but with foreach, it is close enough:

auto obj = new DataObject(db, "table"); // you could subclass it 
for a specific table, database.d even has functions to generate 
those classes from MySQL CREATE TABLE declarations automatically

foreach(k, v; cgi.post)
    obj[k] = v;

or you could easily enough list the expected keys in that filling 
loop, kinda like the Rails strong params (as I understand them - 
rails is now my day job but I'm still a bit of a n00b).



Filling the form data and generating the model updates was the 
most painful part of writing PHP IMO, so dom.d made them all 
stupid simple. Now I don't feel the need for form helpers, the 
DOM is smart enough to fill in the gaps from whatever it is given.

dom.d also has a function to get a value hash out of a form but I 
never actually used it. Maybe with local imports, I can make that 
smarter and selectively depend on cgi.d to actually have it cool. 
I gotta come back to this stuff some day.


2) Generate the HTML with the DOM library along with helper D 
functions to ensure more consistency.

auto form = cast(Form) Element.make("form");

form.addField("name", "value", [options]);

addField has several overloads that pick the right HTML to make 
from a given data type. It generates consistent HTML for labels 
and spans so it is easy to style with CSS.

But since this is D, it is a bit harder to pass to a HTML guy to 
edit the design. Otherwise though, dom.d's helper functions make 
all kinds of manipulations really easy and it is tempting to use 
more than I probably should.


3) Some hybrid, where you use custom tags in the HTML which are 
run. dom.d's more recent versions also include passing <%= %> and 
similar tags to a handler, if we really wanted to, we could use 
scripts there as well as custom tags and data attributes to fill 
things in.

Early on, I used a LOT of custom tags, but nowadays I prefer to 
stick to mostly standard HTML so it works better stand alone.

> The view uses appropriate names for the form fields, scoped in 
> the same name as the model, like this:

Yeah, that's pretty nice. database.d's fillData (on which dom.d's 
fillForm is based and web.d does the same for struct arguments) 
just uses dots:

name="person.name"

which would fill the

void handler(Person person);

person.name field there. Then you do person.toDatabaseObject (an 
auto-generated function btw) to get a SQL builder class out of it 
and modify it if you want then finally just 
person.commitChanges(); which is like Rails' .save!

Perhaps I'll make the mixin just throw in a save method at some 
point too.



This stuff is fairly new and underdocumented/advertised, even my 
by lax standards. I think this is the first time I've even talked 
about it on the forums.


tbh from what I've seen, my collection of stuff is closer to the 
"full web framework" than vibe.d itself - as we discussed a 
couple months ago, I also have my SASS like css expander (which 
unlike the real sass doesn't need the rest of your life to 
recompile after any trivial change... though it is admittably 
still slow for D), javascript expanders and generators, various 
SQL backends, the list goes on.