-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature proposal: A stand-alone controller #45
Comments
Is there currently a use-case for this? |
Yes, LEV. |
@daniel-ac-martin what would the controller look like, would it form the basis for the hof-controllers or be entirely separate? |
No it needs to wrap around HOF's base-controller. (Well it could just about get by without it but it does need to wrap the wizard's controller.) It could either be a special controller in hof-controllers or it could wrap the whole of HOF. - Which might be cleaner as it's quite a specific use case. - Search forms. I'd image one would either want a multi-step form OR they would want a search form. But I haven't given it too much thought. Would be interested to know what people think about this. |
The annoying thing is that it is very hard to avoid pulling down the wizard. (The standalone controller doesn't need it.) |
We tend to think about HOF and the HMPO form stack as being all about multi-page forms, but actually HOF provides a lot besides that, including:
For that reason, it would be nice to leverage HOF even on very small, single page forms. Also, it would be nice to do so:
I have been writing a controller to provide this functionality. Initially I intend to wrap the whole of HOF but in the long run it would be nice to make this controller available publicly. To my mind, the best place for this controller to live would be hof-controllers but it could otherwise be provided as a separate module wrapping all of HOF.
What do people think?
The text was updated successfully, but these errors were encountered: