With the latest changes to Yii2 codebase I think HMVC is now possible. I still don’t think we’ll advertise it in the guide because there are better tools for the job.
With the latest changes to Yii2 codebase I think HMVC is now possible. I still don’t think we’ll advertise it in the guide because there are better tools for the job.
Interesting. Would you mind elaborating just a little on which changes you are referring to?
Recent testing-related stuff: wrappers around request and response.
I’d just like to add an example use case to this thread for internal requests using HMVC that I don’t believe could be resolved using any other method including modules.
I work for a web and mobile development company. I’m their primary PHP ‘engineer’. About 80% of what I build are RESTful API’s to interface with the Android and iOS apps we build. Basically, we create API’s for nearly every action taken on a model, then use those for both the mobile apps and any web interfaces we use. Most of the web stuff is AJAX so it works pretty well.
There are often times though we need to internally call the API internally.
For example if there are multiple user types, we would call the create user method for say "publisher" and that would internally call the API for basic users. This way we can still call the basic user independently, but can also reuse all that logic for publisher users that might need other tables and data setup as well.
A second example is multiple requests bundled into one. With mobile apps speed is one of the highest concerns. If we need to do one API request for brands, and one for zip codes, and yet another for say venues, 3 separate requests can be expensive and timely. Instead we can have a API request handler, where an array with say:
Array(
'request1' => (
uri => "api/brands",
method => "post"
data => array( ... )
),
'request2' => (
uri => "api/venues",
method => "get"
data => array()
),
request3 => ( ... etc ... ),
)
Which can handle extra requests.
I can see how there’s not an incredible need for HMVC for view components when there are modules, but those don’t provide any solution for an API driven site.
I posted a little more detail about this type of site design here.
When I’ve designed API at Stay.com we had the same concerns and it was solved w/o HMVC. I’ve just created another layer that incapsulated all the logic and both used in API endpoints, batch endpoint and the application itself.
Nothing is set in stone with Yii2. Qiang had the foresight and experience to look many years into the future of framework development. Building an HMVC or PAC layer on top of Yii2 as mentioned earlier is possible but very little documentation exists for doing so. Interfaces can be replaced where necessary, Classes can be extended as needed, alternate ideas and design patterns can be adapted, and so on in designing a new layer. Moving to a TRULY event-driven API is possible using existing design patterns. The bits and pieces for simultaneous client-to-server and server-to-client communication already exist on Github but mostly in pieces.
My point is, why couldn’t Yii be just an API foundation and why not build layers on top of that foundation to create different API implementations. Is Yii3 really necessary. Could your new framework ideas be implemented as a layer built on top of the existing foundation.
@mmx I agree that the foundation Qiang built is impressive but still we want to fix some of its flaws in Yii 3. It could not be done without breaking things and since that’s the foundation, it breaks many things.