Add requireness to HasOne form

[goosys]

The nested form for HasOne didn't have the requiredness mark, so I added it.

Before:

After:

[nickcharlton]

Can you think of a reasonable way to test this, so we don't break it in future?

[goosys]

I will think of a reasonable way to test this and add it!

[goosys]

I've added tests.

By the way, ProductoMetaTag is the only place in the demo app that uses Field::HasOne, but it has too few columns, both of which are String type and required. This makes it less suitable for comprehensive testing.

Would you consider adding more columns?

[goosys]

Regarding this method name, is "requireness" correct? Should it be "requiredness" instead?

[nickcharlton]

By the way, ProductoMetaTag is the only place in the demo app that uses Field::HasOne, but it has too few columns, both of which are String type and required. This makes it less suitable for comprehensive testing.

We should add more if it's needed for testing. The demo app has grown organically and is neither consistent nor coherent in how it works. I've long wanted to switch the demo app to follow a particular pattern. Maybe a shop or something.

Regarding this method name, is "requireness" correct? Should it be "requiredness" instead?

I think "requiredness" is likely more correct, according to the OED it is a word, although not a common one.

[goosys]

Rebased!

[goosys]

Rebased.

[pablobm]

We should add more if it's needed for testing. The demo app has grown organically and is neither consistent nor coherent in how it works. I've long wanted to switch the demo app to follow a particular pattern. Maybe a shop or something.

For a while now I've been thinking that ideally we should have several example apps, or one with several admin interfaces handling unrelated models (or perhaps related). I feel that trying to get every single use case with a single app gets out of hand pretty quickly.

[pablobm]

I think this is good

[goosys]

What do you think about moving this into a separate dedicated repository?

Something like administrate-kitchensink or administrate-storybook. Ideally, I’d like it to have all the community plugins installed, and include many examples using looks.

For example, we could provide multiple implementations for Field::Date, such as a react-daterange-picker version, a stimulus-flatpickr version, and a jquery-date-range-picker version, each implemented using looks. We could also add various examples for other Fields as well.

I think this would help users get a better sense of how things can be used in practice, and also serve as a reference for implementation.

In an ideal world, it could become a place where we can easily try out Fields built on top of minor gems just to see how they feel.

Just a thought.