jdickey/model_form_demo

Fortitude widgets + model-based forms + form objects + "stuff"

Hi there 👋

model_form_demo's Issues

Replace raw Sequel API with Lotus::Model

Lotus::Model is based on Sequel, and provides standardised semantics for entities, repositories, data mappers, etc. With the relatively recent release of v0.5.0, the 14th release overall, it's now being actively explored and used by developers writing production-quality apps.

It also insulates us from some of the quirks of the raw Sequel API itself, which should make coming up to speed easier for folks whose previous ORM exposure is limited to ActiveRecord.

Page layout (both for landing page and New Thing) use incorrect CSS styling

The Bootstrap documentation covering the CSS grid system states that (among other requirements)

• Rows must be placed within a .container (fixed-width) or .container-fluid (full-width) for proper alignment and padding.
• Use rows to create horizontal groups of columns.
• Content should be placed within columns, and only columns may be immediate children of rows.

We don't follow those rules properly as of v0.9, and we Really Should.

This issue depends rather obviously on Issue #5.

Minor feature creep from merging what was Issue #10 here; the new-thing entry page must have some form of header content, not just a web page title (viewable at the top of the tab/window only).

Flash messages still aren't displayed in index view after successful add.

There's nothing in the flash as received by the view. Thought we'd fixed that.

Reek, :Internals modules, and decorators. (Oh, my!)

The cadence isn't as catchy as "Lions, and Tigers, and Bears; oh, my!". #sosuemealready

Casting about for a non-proprietary example to use in this Reddit discussion of @schneems' When to be Concerned About Concerns post on CodeShip to demonstrate our Internals module use convention, I grabbed TableWidget::HeaderRow from this project. It aptly demonstrates how ugly the use of extracting a tiny module into an ornate module is. In the Reddit post, I pointed out that we're becoming dissatisfied with this, and the expedient workaround seems to simply be to say "shut up, Reek" with a configuration-file setting.

But this may not have been the optimal example to support arguing my point. For what I see, looking at the code after months away, is somewhat simpler:

1. The item_string method (however it's packaged) is purely devoted to formatting presentation content without affecting state;
2. There's a name for that;
3. Implementing what is now the TableWidget::HeaderRow::Internals module as a non-namespaced (or _differently-_namespaced) decorator would solve the obviously known problems with the current implementation pattern.

Not to pick on that class specifically; it's simply emblematic of a pattern we've used in multiple classes on each of multiple projects. However, opening this issue here as this is a public project on GitHub that can be used as a demonstrator for the evolved pattern, which can then "infect" other projects as they go forward.

Thoughts, anyone?

Properly style new-thing entry form page

This includes things like some sort of title/header and decent-looking layout for the form. What we have as of Commit a486e72 is functional, but that's it. "Enhancement" because it's not technically a bug, even though usability is adversely impacted by the status quo. When and if the second such issue is opened, perhaps a usability label ought to be added.

Bootstrap CSS and JS not actually *active*.

D'oh!

And we've no tests that prove that it is. Yet.

So even with somewhat defective Bootstrap usage (e.g., the docs state that columns are the only permitted direct child element of rows; oops), we should still see something significantly less craptastic than what's served on localhost:3000.

Error-field styling not visible

To demonstrate, fire up the app and click the "Add New Thing" button. Enter data for the fields, specifying an initial quantity of 0. When you hit the 'Submit' button, Rails wraps the invalid field (label and input control) in a div.field_with_errors (note the un-CSS-like underscores) element. Bootstrap knows nothing of this, apparently; it's incumbent upon us to define it.

This issue depends on both #5 (obviously) and #6.