T
T
Terion2011-01-01 23:26:31
CodeIgniter
Terion, 2011-01-01 23:26:31

An ideological question on the implementation of modularity for a php framework?

I'm a big fan of Codeigniter, but it is known to lack such a thing as HMVC (i.e. there is no question of any modularity out of the box). There are horrible monstrous extensions, but I don't like them.
So I went the “if you want to do something good, do it yourself” way. I found a simple and elegant solution that makes the igniter very modular.
But there are several ideological questions (which affect the syntax of calling modules and not only), which I can’t answer myself:
1. When calling a module method, it must return content (html / json / xml - it doesn’t matter), Or is it worth considering the option that it will return not content, but data, or simply do something and return nothing?
2. Accessibility of the module by URL - in the HMVC prefix, this is one of the attributes. But he bothers me a lot. Writing a modulerouter is not a problem at all, but frankly I don’t understand why? For ajax applications? But for such purposes, it seems to me that it is more correct to write a separate ajax interface, which will contain only what is needed for an application with processing post data, etc. etc. In addition, the issue of security when accessing modules by url is of great concern. It would be very interesting to hear opinions on this.
3. In the case of REST-style module calls, what would be better? modulename/methodname/viewname?param1=x?
Thanks

Answer the question

In order to leave comments, you need to log in

3 answer(s)
A
Alexey Sundukov, 2012-01-03
@Terion

From personal practice.
1. The module returns data and only data. It doesn't matter which of the formats (JSON / XML / etc), the main thing is that there is no markup responsible for representing the data type. HTTP headers are data too.
2. No separate AJAX/non-AJAX interfaces. Therefore, from the server's point of view, all these requests are HTTP requests. And AJAX essentially exists at the client layer, that layer shouldn't be in a back-end architecture.
The ability to access a module by URL is useful when an application grows to more than one server. If you do not think about this initially at the architecture level, then you will have to implement a “separate interface”. If you think right away, you can get it right away, a little bit, so to speak.
3. The above example is more RPC than REST.
There should be nothing criminal in accessing the module via HTTP if it is implemented correctly. They pulled the module code from the outside, but did not pass the authentication themselves? So, if we work in REST style, we return 403 response status.

V
Vadim, 2012-01-03
@MisterX

If you like Codeigniter, you can look towards Kohana, there is both modularity and HMVC

A
ainu, 2012-01-02
@ainu

All IMHO.
1. Sometimes a module needs to do a redirect without returning anything. Or return JSON with a stack command.
2. For distributed applications, in order to access the first one for the module from another machine, being sure that the data will come. Let's say the main machine is the site itself, the second is the auction module with high costs, and it is pulled from the outside by the first machine.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question