Welcome Guest, Not a member yet? Register   Sign In
Poll: CI4: Module support?
You do not have permission to vote in this poll.
yes
88.46%
115 88.46%
no
4.62%
6 4.62%
maybe
6.92%
9 6.92%
Total 130 vote(s) 100%
* You voted for this item. [Show Results]

Module support?
#31

(06-24-2015, 09:31 PM)ivantcholakov Wrote: In pure CI3 $this within a controller context means the controller itself, $this within a view context means the loader class instance. I don't see a difficulty for understanding this concept, it is already being in use.

It's not difficult to understand at all. But WireDesignz' HMVC library does something a little different. It's not necessarily dangerous, but can be at times. The get_instance() command is built into the CI_Controller, and represents an instance of the current controller, as you said. However, when you load a second controller you now have a conflicting instance that is pointing to the second controller whenever accessing something not specifically set in that controller. To get around this, the HMVC libraries, IIRC, have an additional CI class that is used to help create a common instance that $this points to for things not within the class. And this seems to work most of the time, but can lead to some tricky debugging moments.

(06-24-2015, 09:31 PM)ivantcholakov Wrote: An additional library... No, thanks. As a rule, I don'want to write libraries with methods that return HTML output. I want to use MVC triads as visual widgets that I can simply put within the views wherever I want. Actually, it is often a designer to do these visual changes within the views only, without touching controllers, libraries or other programmer's stuff.

And that's a design choice that works for you, and that's awesome. And a decent use of MVC. What I was proposing was simply replacing the C in your triad with an L. Conceptually, they're very close, but controllers in CI have a very specific design that I think runs risks and makes things more difficult to debug on occasion. (See the Form Validation library issues that HMVC system has). Instead, the Library represents more of an Entity, I guess, than a controller, since it's not responsible for controlling the flow of data from request to response.

(06-24-2015, 09:31 PM)ivantcholakov Wrote: A reference to a talk that is close to to this one: http://forum.codeigniter.com/thread-61509.html

You're right - and I said there I liked what they did. I even implemented a simplified version of it. However, that wasn't controller calling controller. It was calling a separate class, which, in the CI world, is a library. And I don't believe their controllers have the same "global $this" issue that CI does.
Reply
#32

@kilishan I can swallow concept changes, no problem. Just it is desirable the back-end developer from one side and the front-end developer and the designer from the other side not to interfere in their works badly.
Reply
#33

(This post was last modified: 06-25-2015, 01:12 AM by sintakonte.)

(06-24-2015, 07:52 PM)kilishan Wrote: I'm a huge proponent of module use, myself. But also very much against the "controller calling controller" method that WireDesignz' code uses due to the possibility of a confusion of what "$this" means in the different contexts (since "$this" is simply an instance of the calling controller).

It seems to me you could use a library from another module to get the same results without the potential issues with controller calling controller.

thats the reason why we do 95% of our stuff in our models - even form_validation; We pass an prepared data object to the models and let the model do all the stuff- and pass just the data through the controllers who decides which data they want
but there are simply cases where its quite comfortable to load a module in a controller
In our system we've by now about 250 controllers and some of them put out different formats (like pdf, csv, doc, xml etc.)
a last example should illustrate what i mean

PHP Code:
public function pdfExport()
{
    
$this->load->model("onlineshop/OnlineShopCategory_Model");
    
$this->load->model("shopbackend/SaleItems_Model");
    
$mainCategory intval($this->input->post("category_type",true));

    
$objCategory $this->OnlineShopCategory_Model->getCategoryFromId($mainCategory);

    
//print_r($objCategory);
    //die;
    
$objPDF = new PDFExport_Object();
    
$objPDF->setHeaderTypeToHtml();
    
$objPDF->setFooterTypeToHtml();
    
$objPDF->setDefaultFont("arial");
    
$objPDF->setConfigVaues("margin_top",22);
    
$objPDF->setConfigVaues("margin_bottom",22);

    
$arrData = array("objCategory" => $objCategory);

    
$objPDF->setPrintHeader($this->load->view("shopbackend/sale-items-header",$arrData,true));
    
$objPDF->setPrintFooter($this->load->view("shopbackend/sale-items-footer",$arrData,true));
    
//$objPDF->setPrint
    
$objPDF->setPDFFileName("abverkaufsartikel-".date("Y-m-d").".pdf");

    
$objCategoryWrapper $this->SaleItems_Model->loadItems();
    
$arrMainViewData = array("objCategoryWrapper" => $objCategoryWrapper);
    
$objPDF->setHtmlText($this->load->view("shopbackend/sale-items-pdf-export",$arrMainViewData,true));

    
modules::run("PdfExport/createPdfFromHtml",$objPDF);

    



Again - of course i can use a library but i don't want to because of the reasons i mentioned in an earlier post.
Also, i don't want to make a religious thing out of that (my posts are just my opinion), but i really want the freedom to call a module where- and whenever i want. 
If i don't have that, i think its use- and pointless to integrate a module based system in CI 4.
Reply
#34

I love CI and HMVC and Module if have

Thanks CI and HMVC
Reply
#35

I agree with Kilishan 100%.
Your controller methods should be relatively thin.
Controllers calling controllers sounds like you are doing something wrong? Don't be afraid of writing a library or 10.
That way your code can be used any where (in 50 controllers if it needs to be used) and then controllers aren't calling controllers to get at certain code which you only wrote in said controller.

DMyers
Reply
#36

There is nothing wrong with what sintakonte has written, he knows what he is doing very well. Let us get away from this "controllers calling controllers" phrase, because it makes people blind. The point is how an independent visual widget (capable to retrieve its own data without main controller's assistance) to be placed inside the main view, or even to be placed inside another visual widget. A library with methods that return HTML output is not the right tool for this purpose. I can tolerate such a manner, not in my projects of course.

WireDesignz' solution conceptually is not wrong. It has a hack inside, but on the other hand, the author had had to stick with the precondition that CodeIgniter's system files should not be touched. On CI4 development this restriction will not be present, so, why not these implementation details ($this, CI, maybe isolation of data inside views too) that are not liked to be addressed and improved, instead of scrapping the whole concept itself and proposing a new one?

There is legacy and practice, I've seen in the past good videos on how CI+HMVC to be used, I think, good links could be found in this forum too. Why would we waste this legacy?

There always be people doing stupid things with HMVC and complaining later. It does not mean that something is wrong with HMVC.

I agree that it is better controllers to be thin, libraries are not the only, the exclusive solution, but this is another topic.
Reply
#37

You make a valid point controllers calling controllers is not a good term for that.
I like you "Visual Widget" term better

DMyers
Reply
#38

'Visual Widget' is almost as bad.

A Controller can be used to create output which is not a visual widget at all, like XML, a PDF or something else.
Reply
#39

@RWCH
You gave more examples about the "second possibility" that was previously mentioned. Thank you, I know that. I don't care about names and terminology, the point is about implementation.
Reply
#40

+1 hmvc
Reply




Theme © iAndrew 2016 - Forum software by © MyBB