<commit_before>
### When to use it ?

>This package helps you in stuations that you want to create crowded web pages with multiple widgets (on sidebar, menu, ...) and each widget needs seperate sql queries and php logic to be provided with data for its template. If you need a small application with low traffic this package is not much of a help.Anyway installing it has minimal overhead since surprisingly it is just a small abstract class.



### So what is our problem ?
#### Problem 1 : Controllers get crowded :(
>Imagine An online shop like amazon which shows the list of products (in the main column) popular products, related products,etc (in the sidebar), user data and basket data (in the navbar) and a tree of product categories (in the menu) and etc... And in traditional MVC model you have a single controller method to provide all the widgets with data. You can immidiately see that you are violating the SRP (Single Responsibility Priciple)!!! The trouble is worse when the client changes his mind over time and asks the deveploper to add, remove and modify those widgets on the page. And it always happens. Clients change their minds.The developoer's job is to be ready to cop with that as effortlessly as possible.

#### Problem 2 : Caching is hard :( 
>Trying to cache the pages which include user specific data (for example the username on the top menu) is a often fruitless. Because each user sees slightly different page from other users. Or in cases when we have some parts of the page(recent products section) which update frequently and some other parts which change rarly... we have to expire the entire page cache to match the most most frequently updated one. :(
AAAAAAAAAhh...

========================

#### So, How to fight against those ? ;(
>__The main idea is simple... Each widget should have it's own controller class, view partial and cache config, isolated from others.__
>That's it !! :)

### How this package is going to help us ? (@_@)

1. It helps you to conforms to SRP (`single responsibility principle`) in your controllers (Because each widget class is only responsible for one and only one widget of the page but before you had a single controller method that was resposible for all the widgets. Effectively exploding one controller method into multiple widget classes.)
2. It helps you to conforms to `Open-closed principle`. (Because if you want to add a widget on your page you do not need to touch the controller code. Instead you create a new widget class from scratch.)
3. It optionally `caches the output` of each widget. (which give a very powerful, flexible and easy to use caching opportunity) You can set different cache config for each part of the page. Similar to `ESI` standard.
4. It executes the widget code `Lazily`. Meaning that the widget's data method `protected function data(){` is hit only and only after the widget object is forced to be rendered in the blade file like this: `{!! $widgetObj !!}`, So for example if you comment out `{!! $widgetObj !!}` from your blade file then all database queries will be disabled automatically. No need to comment out the controller codes anymore...
5. It optionally `minifies` the output of the widget. Removing the white spaces. (In order to save cache storage space and bandwidth)
6. It support the `nested widgets` tree structure. (Use can inject and use widgets within widgets.)



### Installation:

`composer require imanghafoori/laravel-widgetize`<commit_msg>typo fix in readme file.<commit_after>
### When to use it ?

>This package helps you in stuations that you want to create crowded web pages with multiple widgets (on sidebar, menu, ...) and each widget needs seperate sql queries and php logic to be provided with data for its template. If you need a small application with low traffic this package is not much of a help.Anyway installing it has minimal overhead since surprisingly it is just a small abstract class.



### So what is our problem ?
#### Problem 1 : Controllers easily get crowded :(
>Imagine An online shop like amazon which shows the list of products (in the main column) popular products, related products,etc (in the sidebar), user data and basket data (in the navbar) and a tree of product categories (in the menu) and etc... And in traditional MVC model you have a single controller method to provide all the widgets with data. You can immidiately see that you are violating the SRP (Single Responsibility Priciple)!!! The trouble is worse when the client changes his mind over time and asks the deveploper to add, remove and modify those widgets on the page. And it always happens. Clients change their minds.The developoer's job is to be ready to cope with that as effortlessly as possible.

#### Problem 2 : Page caching is always hard :( 
>Trying to cache the pages which include user specific data (for example the username on the top menu) is a often fruitless. Because each user sees slightly different page from other users. Or in cases when we have some parts of the page(recent products section) which update frequently and some other parts which change rarly... we have to expire the entire page cache to match the most most frequently updated one. :(
AAAAAAAAAhh...

========================

#### So, How to fight against those ? ;(
>__The main idea is simple, Instead of one controller method to handle all widgets of the page, Each widget should have it's own controller class, view partial and cache config, isolated from others.__
>That's it !! :)

### How this package is going to help us ? (@_@)

1. It helps you to conforms to SRP (`single responsibility principle`) in your controllers (Because each widget class is only responsible for one and only one widget of the page but before you had a single controller method that was resposible for all the widgets. Effectively exploding one controller method into multiple widget classes.)
2. It helps you to conforms to `Open-closed principle`. (Because if you want to add a widget on your page you do not need to touch the controller code. Instead you create a new widget class from scratch.)
3. It optionally `caches the output` of each widget. (which give a very powerful, flexible and easy to use caching opportunity) You can set different cache config for each part of the page. Similar to `ESI` standard.
4. It executes the widget code `Lazily`. Meaning that the widget's data method `protected function data(){` is hit only and only after the widget object is forced to be rendered in the blade file like this: `{!! $widgetObj !!}`, So for example if you comment out `{!! $widgetObj !!}` from your blade file then all database queries will be disabled automatically. No need to comment out the controller codes anymore...
5. It optionally `minifies` the output of the widget. Removing the white spaces. (In order to save cache storage space and bandwidth)
6. It support the `nested widgets` tree structure. (Use can inject and use widgets within widgets.)



### Installation:

`composer require imanghafoori/laravel-widgetize`
{'fraction_non_alphanumeric': 0.06187029941819214, 'fraction_numerical': 0.002270469703419895, 'mean_word_length': 4.363774733637747, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 13, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 2, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3238230', 'n_tokens_mistral': 1686, 'n_tokens_neox': 1616, 'n_words': 1130}