The Form class is a multiton, it allows you to create multiple named instances and use them concurrently.
If you don't specify an instance name. forge() uses the name "_default_". Which works fine if you only need a single instance per request, but which you can't use for multiple (because it can't create it a second time).
Since I don't know what exactly is in your views, I can't comment any further.
Ok thank you ;) But, I create an instance $val = Validation::forge('fastlogin'); and I this error Also, if a create instance with fieldset::instance(), I receive: array_key_exists(): The first argument should be either a string or an integer and I no understood ^^
That alone won't give you the error, unless that code get executed twice.
And you create instance with forge(), you retrieve instances with instance(). Some instance() methods still have a legacy feature that creates the default instance if you don't pass an instance name, but not all do, so don't rely on it.
As to the error mesage, we need at least the code you used to create the error, the Fuel version you use, and a file and a line number, otherwise we've got no clue where to look.
Made your post readable, and please use a pastebin for your code to keep this forum tidy. ;-)
What goes wrong there, is that this is a template controller, it sets template sections, it is not designed to return data, what you want with your HMVC call. It's not a widget, it returns the entire page.
So your URI request executes the page, and your request does it again, which is where the error comes from.
HMVC requests are like method calls, they should return something, not output something. So they can never be part of a Theme or Template controller, which are designed for interactive use.
A widget is in the basis nothing more that returning a view, for which I would not use HMVC calls, unless you're building modular applications.
And I would not use a View, I would use a Presenter, which has the ability to define class methods to prepare data for the View, fetch additional data, etc. It saves you from creating an entire Request stack and running a controller method.
If you want to handle POSTs in your widget as well, you need a controller. But creating a distributed and self-contained widget system is more complex than this, because your page can contain multiple forms (even from the same widget), so you need to track which form was exactly posted...
If you intend to build a single app, and you need widgets containing simple blocks of HTML for a section of your page, I would use Presenters, yes.
If your widgets need to be self-contained (i.e. not only display but also process input), or if your application is modular and you want to re-use as much as possible, I would go for HMVC calls in combination with modules. Probably combined with some CMS style install/remove GUI, and some sort of central registry of modules.
This is the second choise ^^ I use HMVC... But He generate a full web page ^^. I don't see how you use modules, generate some view... (Or I don't understand ^^ (I'm french student ^^)
Because you're using a template controller. These are for complete webpages, where you define a page template, and inject widgets (or only a content body) in it.
This is not what you're looking for. Your controller need to extend \Controller, and the controller methods should return a View (or a Presenter that returns a view) that only contains the HTML for your widget.