I have just learned that "#Java Bean" has two completely different and incompatible definitions.
One is a dumb, badly designed data object with getters and setters.
The other is... a service object managed by the Spring framework IoC container.
Holy hell. This is 10x worse than #Laravel "facades."
Am I wrong here? This is what I'm finding from online tutorials. Is there more nuance that is not coming through, because for now I just hate #Spring even more.
@sarah Perhaps, but in practice the global function calling the app container has never caused any problems for me. And you definitely could inject the config repository where needed, it's just not conventional Laravel. I prefer sticking with conventions.
Macros are one thing I enjoy using the most in #Laravel. It's a way to extend the functionality of many built-in #Facades by providing custom callbacks for a specific key.
One production example I use macros for fairly often is what I call the "admin alert". Especially in smaller applications I want to get notified whenever an error or an event occurs the admin (mostly that's me) should know about.
Using global query scopes for simple one-to-many tenancy.
Code example of a #Laravel cat pension #SaaS app I've started and never finished. It's structured like this:
A user belongs to a pension
A pension has many clients
A client has many animals
Users (cat pension owners and their employees) can only view clients and animals from the same pension. Global query scopes ensure this rule is consistently applied throughout the app without accidentally forgetting it somewhere in your code.
When developing #Laravel applications I'm always a little afraid of sending emails to actual customers or placing real orders by accident. So I came up with a habit that works super well for me and maybe this will suit you as well.
In my /config/mail.php I add a 'developer' email address and ensure in my AppServiceProvider all emails are sent to this address when in non-production environments no matter what. Makes me build and test stuff way more confidently 😁
@rolfdenhartog That's a great solution, thanks! For such cases I usually work with Laravel Herd. However, many times I know my clients work with outlook for example and then I ensure everything looks fine in outlook. But still, your approach in general feels cleaner than adding my code snippet to the service provider.
#PHP 8.4 is introducing newing up a class and accessing methods, properties, etc. on it without wrapping it in parentheses first. Another useful feature I will probably use on a daily basis. In my daily work with #Laravel I often need to crawl some content from a website or an API. This feature will make my code a little less cluttered.
Please, web app developers, consider how your users will upgrade. If your upgrade process is "remove the old one, unzip the new one", then it's not an upgrade process. It's an encouragement to never upgrade.
I can integrate it in my app to deploy it in production.
I need to have a git repo on the server (mainly for private repo). And it configurable with y'all config.
But with a cli command, the component will:
creates an export of given tag
extracts it in some place
runs composer install
can run some other commands
copies secret files into app dir
create a symlink (for apache)
In case of problem, I redo a symlink on previous version