Jump to content

Envrin

Members
  • Posts

    15
  • Joined

  • Last visited

Contact Methods

  • Website URL
    https://apex-platform.org/
  • Skype
    envrin.group

Profile Information

Recent Profile Visitors

2,809 profile views

Envrin's Achievements

Member

Member (2/5)

2

Reputation

  1. A lightweight, straight forward dependency injection container that simply works, and works well. https://github.com/apexpl/container/
  2. Canadian citizen, 19 years high paced and professional experience within online software, and with me your imagination is the only limit. For an idea of capabilities, creator of Apex at https://apexpl.io/, an open source software platform. Also highly proficient with the bitcoin protocol and own https://envrin.com/ if you need any bitcoin / crypto-currency related operations developed. Resume can be found at: https://apexpl.io/Resume_Matt_Dizak.pdf Can handle jobs of any size, simple $100 tasks, large scale systems that require multi-year contracts, dozens of online operations spread across multiple servers, distributable software, or anything else. . Specialize in back-end development of larger scale systems that require a high proficiency with clean database architecture and optomization, server administration and security, horizontal scaling across multiple servers / instances, redis caching for speed and scalability, a quick moving agile environment, etc. You may get a better insight into my thought process by reading an article I wrote a good while back at the below URL, with more articles to come shortly. https://apexpl.github.io/monoliths_done_right Thanks for your time, and if you need quality online software of any size or scope, please e-mail me anytime at matt.dizak@gmail.com, and I'll be happy to provide you with consultation. Looking for $40/hour, which I think is quite reasonable. Stay safe, and Kovid free. Best regards, Matt
  3. Just fyi... upgrades out, and a new minimalstic site with new demo installation video now online. Please check it out at: https://apex-platform.org/ Any feedback, perspective, suggestions, questions, or anything else, please let me know. Would love to hear from you.
  4. After 2 years of hard work and retraining, backed by 19 years of experience, Apex Software Platform is finally done. Open source PHP software platform, and designed to be a modern day and professional replacement to Wordpress. Would love some feedback on it, and please check it out, and do an install if wanted at: https://apex-platform.org/ You can view a demo admin panel at: https://demo.apex-platform.org/admin/ Demo installation video to see how quick and easy it is at: https://youtu.be/owfK4HiLQGQ Intro video at (sorry for snpping fingers, future vids will be professionally edited with intro): https://youtu.be/B8SNUCHa_tA I've put a massive amount of work into this, it's all open source under the MIT license. Would love some feedback. Please feel free to do n install, check out the code base and let me know. Thanks.
  5. Another way is to simply: ALTER TABLE table_name SET AUTO_INCREMENT=0; Hope that helps.
  6. Welcome to the forum, hope you find it useful, and learn lots.
  7. Ohhh, I figured it out. I was indenting the @param lines by 4 spaces, so it was picking them up as a multi-line tag. New lines only get 1 spce indentation, no more, got it!
  8. I have to be doing something wrong here, but so far Googling hasn't helped. Take a look here: https://demo.envrin.com/api/classes/apex.app.msg.emailer.html#method_send The doc-block is correct, or at least as far as I can tell it is, character-by-character. I'm blind though, but have tried different combinations of things like "String" instead of "string" or "@Param" instead of "@param". Made sure the ends of the @param lines ende din a period, and that seemed to help a little. Nonetheless, why does it keep adding the namespace to everything in front of "string" like that? Any why are the paramaters section all screwed up? Any help would be appreciated. Thanks!
  9. Still struggling here a bit. I can't seem to get the simplicity of static methods with dependency injection, but I know within the modern software world static methods are a crime against humanity. I really enjoy the power of dependency injection, and definitely want to keep that. I like the ability of easily swapping out classes for different ones just by modifying a small PHP configuration file, and as long as both classes implement the same interface, everything still continues to work like a charm. For example, if you want to use a different log handler or http client than the default one, it's no problem to switch it out. Problem I have is once you begin using DI, you have to basically call 100% of everything via the container because everything has dependencies that need to be injected. This causes a real mess, and that's when I begin missing the simplicity of static methods. So here's my workaround, and I'm just curious as to your thoughts. First, I have all my base classes (database, log hander, debugger, template parser, event dispatcher, etc.) and these are all proper PHP classes with non-static methods that implement certain interfaces for structural integrity, etc. Then I have some very basic "service" classes that look something like: <?php namespace myapp; class db { private static $instance = null; public static method singleton($obj = null) { if ($obj !== null && !self::$instance) { self::$instance = $obj; } return self::$instance; } public static function __callstatic($method, $params) { return self::$instance->$method(...$params); } } I have one of these classes for each "service" I want (eg. db, log, debug, template, rpc, etc.). Then within the bootstrap / config script fo the app, I "assign" the services with something like: use myapp\interfaces\LoggerInterface; use myapp\services\log; $obj = $app->make(myapp\sys\log::class, ['channel_name' => 'default']); $app->set(LoggerInterface::class, $obj); log::singleton($obj); So it creates an instance of the logger class via the DI container's "make()" method allowing for injection if necessary, then sets it into the container as the LoggerInterface::class, plus sets it as the instance within the services\log class. If I want to switch out to a different log hander, I simply modify that config file and change the creation of the class to say "monolog\monolog\Logger::class", or whatever. As long as it's PSR3 compliant and implements that LoggerInterface, it will work fine. It's also sitting in the DI container and available for injection where ever necessary, plus also available via my small services class to keep accessibility simple. I can then access methods of the log handler anywhere within my code without any injection required by simply using: use myapp\services\log; log::warning("This is a warning"); This is the equivalent of have the "LoggerInterface $obj" injected into a class / method, and calling the "$log->warning()" method. I end up with the power and flexibility of dependency injection, the simplicity and accessibility of static methods, and proper non-static PHP classes allowing for the developer of proper unit tests. Plus I don't have to worry about writing all that extra code and creating a mess due to paramater / constructor / method injection, or calling methods via the container instead of directly, etc. Would love to hear any thoughts anyone has about this, and if it's a horrible methodology, why?
  10. I need to get this right, and am a little confused. Been using the popular http://php-di.org/ package for dependency injection, and although I fully understand the concept, I'm quite obviously missing something when it comes to implementation. Many of you know a project I've been working on: https://github.com/envrin/apex/ You guys tore my head off for not using DI, and using too many static methods. Ok, so I've basically got DI implemented now, but it's not really adding up for me The concept of DI is excellent, and I do understand it. My main issue is basically, if you use DI anywhere, then you have ti use it every where 100%, because everything has dependencies of some kind, which means everything has to flow through the container. I'm struggling to see how this is more efficient than just including a class via "use" statement, then calling it via static methods. Will do my best, but take an example order class: namespace myapp; use myapp\products; use myapp\utils\forms; use myapp\utils\components; class orders { private $app; public function __construct(app $app) { $this->app = $app; } public function add($product_id, $country) { $this->verify($product_id); } private function verify($product_id) { $client = new products(); $client->lookup($product_id); } } In Apex right now, I'd either just leave the above class as is without "app" being injected, or create a "lookup" static method within the products class and just use: products::lookup(); We're using DI though, so that's out. In the above class, "app" gets injected, which is our container itself. Now there's no way we can just createa new instance of the "products" class like that, as it will have its own dependencies, hence it either has to get called from the container or injected into the class. We can always call it from the container with: $client = $this->app->get(products::class); Not the greatest, so there's always constructor injection same as we did with "app".. That means: - Define a "$client" property - Add "products $client" to constructor arguments list - Define "$this->client = $client" within constructor - Use "$this->products->lookup()" in that method. Again, not the greatest. We could do parameter injection via annotation with: /** * @Inject * @var products */ private $client; Then we can just use "$this->client->lookup()" within our method. Again, still not great. Then there's always method / setter injection, such as: /** * Verify the order * * @Inject * @param products $client */ private function verify($product_id, products $client) { $client->lookup(); } That seems decent enough and workable, except now we can't just call "$this->verify($product_id)" within our class anymore, because it has to go through the container instead so injection occurs. Instead, you have to call it with something like: $this->app->call([orders::class, 'verify'], ['product_id' => $product_id]); That's definitely no good. Now put this into context of a larger class with 50 methods that has a total of say 12 dependencies, each of which has their own dependency so everything MUST go through the container, and it creates a real mess. This is especially true when you have say that class with 50 methods, and there's one dependency class used one time in one method, and you're forced to do either: - Constructor injection - Parameter injection - Method injection with annotations, but call the method via the container and not directly. At least from my POV, none of those seem like a good option. I do really like the concept of DI, and that method / setter injection seems to the best, but obviously I'm missing something. Is there maybe some type of "call handler" similar to an error / exception handler, so I can call methods directly within the code and still have injection occur without having to call the methods via the container? I really like the idea of just having everything you need at your fingertips via reflection / injection like this, but not really at the expense of all this extra code. What am I missing here? Could someone please kindly help? I need to get this right. ```
  11. Could use some help with dependency injection, as I can't seem to find the answer anywhere. Ok, take a quick PHP class: <?php namespace myapp; use myapp\template; use myapp\order; class user { private $template; public function __construct(template $template) { $this->template = $template; } public function add_order(order $order) { // do something with $order here } } I'm using the php-di package from http://php-di.org/ right now, but open to changing. My question is, how do I call that "add_order()" method, and have $order injected into it? Constructor injection is easy, and just use: $container = new Di\Container(); $container->make(myapp\user); How do I do that, but calling the add_order() method instead? I want something like: $container = new Di\Container(); $container->make(myapp\user::add_order); Any help? Thanks, Matt
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.