3 ms·

I'm genuinely curious to know what is the sweet spot for these admin interfaces and Hobo for that matter? I find prototyping plenty fast with vanilla Rails, a

by asmala 15y ago

I'm genuinely curious to know what is the sweet spot for these admin interfaces and Hobo for that matter? I find prototyping plenty fast with vanilla Rails, a few backend plugins, and Twitter Bootstrap. And on the far end of the scale, my experience is that larger projects require an amount of customization that does not easily fit into the auto-admin paradigm.

markoa 15y ago
That's why we made admin_view https://github.com/renderedtext/admin_view https://github.com/renderedtext/admin_view
bryanlarsen 15y ago
Hobo works great for both quick prototypes and huge applications. The USDA is using it for a couple of huge enterprise applications, for example. Hobo is not an admin interface. It basically is a system to enable smart re-use of components that's tightly integrated into your entire stack. For instance, in Hobo you can type `<input/>` and Hobo will do the right thing automatically: plop down a text input if the current context is a string, a fully filled out select box if it's a belongs_to or a datepicker if it's a date. The name and default value of that input will also be automatically and correctly inserted. Change the definition of `<input for="Date"/>` and you can change the options on your datepicker or switch datepickers everywhere or just on that page or that section. Beginners love Hobo because they can get an app up quick. Experts love it because you can package all of your components up in DRYML and dramatically reduce the number of lines of code in your program. Where Hobo has trouble is in the middle: until you're comfortable with DRYML you're stuck with the components that come with Hobo.
- asmala 15y ago
  Thanks for the analysis. Sounds interesting. Yes, I'm less interested in quick scaffolding, be it via code generation or ready components, but clean reusable view components does sound appealing. Rails helpers are great for some things but more complex cases like custom form builders can get ugly (no, formtastic is not always the answer). Will give Hobo a look next time.

by asmala 15y ago

markoa 15y ago

That's why we made admin_view https://github.com/renderedtext/admin_view https://github.com/renderedtext/admin_view

bryanlarsen 15y ago

Hobo works great for both quick prototypes and huge applications. The USDA is using it for a couple of huge enterprise applications, for example. Hobo is not an admin interface. It basically is a system to enable smart re-use of components that's tightly integrated into your entire stack. For instance, in Hobo you can type `<input/>` and Hobo will do the right thing automatically: plop down a text input if the current context is a string, a fully filled out select box if it's a belongs_to or a datepicker if it's a date. The name and default value of that input will also be automatically and correctly inserted. Change the definition of `<input for="Date"/>` and you can change the options on your datepicker or switch datepickers everywhere or just on that page or that section. Beginners love Hobo because they can get an app up quick. Experts love it because you can package all of your components up in DRYML and dramatically reduce the number of lines of code in your program. Where Hobo has trouble is in the middle: until you're comfortable with DRYML you're stuck with the components that come with Hobo.

asmala 15y ago
Thanks for the analysis. Sounds interesting. Yes, I'm less interested in quick scaffolding, be it via code generation or ready components, but clean reusable view components does sound appealing. Rails helpers are great for some things but more complex cases like custom form builders can get ugly (no, formtastic is not always the answer). Will give Hobo a look next time.