Jump to content

Envrin

New Members
  • Content Count

    9
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Envrin

  • Rank
    Newbie
  1. 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!
  2. 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!
  3. 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?
  4. 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. ```
  5. 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
  6. Hi everyone, Been working on this for quite a while, and although still quite a ways from completion, it's done enough to begin getting initial feedback. If anyone of you have a spare few minutes, please take a look at: http://apex.envrin.com/ And quick start guide at: http://apex.envrin.com/quick_start Github: https://github.com/envrin/apex/ Would love any initial feedback. I would imagine it will get blasted as amateurish, which is fine with me, as I need it for myself anyway. Hopefully it's able to help some folks out there as well though. PS. Please ignore any design flaws. I went blind a couple years ago, but will get a designer on board shortly to fix up the design flaws. Thanks in advance!
  7. Ok, now those are some pretty damning reviews. Alrighty then. First up, on second thought, totally agree with you guys on the tutorials. Good overall concept I think, but horrible format and for now a total waste of time. I still think it's a good premise though, and will rewrite them from scratch later, but on more of a component-by-component basis instead of in a timeline format, which is obviously unhelpful. No, I'm not totally adverse to using 3rd party. For example, Bootstrap, jQuery, jQuery Validator, I have a SQL parser library in there for large SQL chunks (ie. package installation files), etc. When I integrate a WYSYWIG editor obviously I'll use ckeditor or similar, and so on. However, I am a little picky about which 3rd party components I do include, because general rule of thumb, the more you try to mix and match 3rd party components, the more clunky and restrictive the end result is. I know many with disagree, but I personally dislike PDO, as it seems too cumbersome for no reason. If I was going to go 3rd party for the DB layer it would be MeekroDB which I have used before (eg. Synala). It's excellent, clean, efficient, what takes 5 lines with PDO only takes 1 line with MeekroDB, and it's very secure. They've done extensive testing of their own, and I've had my software pen tested as well with no SQL injection found. My DB library is modelled after MeekroDB, and granted still needs some work on security, does work great. Went with my own naubky dye to logging, error handling, and debugging, but also a few other reasons. Honestly, have never used Twig, so will check it out. I'm very familiar with Smarty though, and have used it many times (eg. Synala). It's a great template engine, but couldn't use it for a variety of reasons, one main one being it doesn't really support specialized tags, especially not on a per-theme basis. For example, I need to put say "<e:tab_page title="My Tab"> ... </e:tab_page>" tags in the templates, and have them replaced correctly regardless of theme being used. Many themes format tab controls differently, and at the very least use different CSS class names. Same goes for loads of other elements on pages. I need to be able to grab a theme from ThemeForest, have it fully integrated into the framework within 30 mins, and have it perfectly integrated across the dozens or hundreds of templates, without having to go through and tweak each individual template due to a theme change. -------------------- Thanks for the nudge on the blind thing, and you're right. Will remove that, as not relevant to the content. Also thanks for the slap about PHP 7, as I somewhat missed that whole release while trying to figure out this whole blind thing. Read up on it, some cool new features that I'll will definitely take advantage of. Strict type setting I'm definitely happy about, plus the additional error / exception handling, and others. As for component vs. more standard / modern MVC format, I guess personal taste, plus other reasons. For one, I think it's more organized, as a developer can pop into a system and almost immediately get a brief overview of what's going on just by looking at the file structure without having to sift through any code. Plus I like to think it provides more standardization. With the more standard MVC model developers can sway from the path more easily, so you may end up with a dozen different development styles in the same system, which can get messy. Whereas with this, although you still have flexibility to develop anything and everything, it's more structured, again allowing other developers to easily pop in and out of projects with a reduced learning curve. . Thar, and even with multiple developers involed in one system, the end result to the client will be a coherent, streamlined system that all looks and acts the same. Maybe I'm wrong, but that's my perception at least. Definitely not for everyone, but I'm sure for some people, and definitely for me. Yep, there will of course be full unit tests available, as that's a crucial aspect. Plus extensive debugging features as well, which aren't yet developed. -------------------- Anyway, thank you guys very much for the feedback, as you helped force me take a step back adnd re-analyze everything. Development will move forward, tutorials are scrapped until development is completed, will upgrade to PHP 7 standards, will have to agree to disagree buy component design is staying, etc. Alrighty, here we go. I'll be back with a more finished version. Now just to find a volunteer to help with the jQuery / Javascript aspects. I know the code, but testing and debugging is a little tough without eyesight. Will see what I can do. Thanks again.
  8. Thanks for the feedback, and much appreciated. Let's see if I can answer everything. Yes, you're correct, too much for beginners, and advanced users aren't going to waste their time with it. I guess it's geared more towards the intermediate -- the guy who is done all the beginner stuff, and is that "ok, now what? how do I get better? what should I develop?" phase, or simply wants to hone their skills when it comes to structure, cleanliness, efficiency, security, writing a proper database schema, etc. Maybe I'm wrong, and the pool of developers is too small compared to the time investment. Regardless, this framework is getting developed, as I need it. For one, I don't really like using 3rd part frameworks, as I prefer to know how my systems work inside and out. More importantly, I went blind about 9 months ago, hence reading and sifting through third party code is quite difficult. I need all the code in my head, so when a bug fix / modification comes up, I know exactly where in the code to go. Nonetheless, once Apex is completed I'd be happy to put it up against the big boys like Laravel, Symphony, and even other non-PHP frameworks. Maybe even have a competition, one (or more) developers each use a different framework, same set of project specs, and have say 24 hours to deploy a live system. I'm sure at the very least Apex would stand up to them (once complete), if not beat them. Time will tell I guess. Regardless, I need to develop Apex for my own personal projects at the very least, so figured while doing it might as well try to help a bit by documenting the process from start to finish. Instead of just a tarball on someone and say, "ok, learn this", I thought maybe there were some developers who would benefit learning it in smaller chunks, and more of a step-by-step process. Again though, maybe I'm totally wrong and off base with that. Yep, of course will be uploaded to Github once complete. For now, the zip and tar archives are available at the top of every tutorial, which consist of the full system as is after each tutorial. Thanks, and you're totally right about styling the code blocks. My partner is out of town for the next week, but I'll take care of that when he gets back, since I'll need to borrow his eyes for it. Thanks again for the excellent feedback. Much appreciated!
  9. Hi everyone, Hope this doesn't get flagged as spam, because by no means my intention, and looking for honest feedback. I'm currently developing the third iteration of my PHP framework, which I started back in 2006, now coined Apex Framework. While doing the development, I decided to put together a series of tutorials, taking other developers through the development process step-by-step, to give them a good understanding of exactly how to develop their own high-quality PHP framework. These tutorials are quite a bit more in-depth than your typical MVC tutorials, as the framework includes things such as package management repositories, multi-language, theme library, and much more. To see what I currently have, please check out the one link at: http://envrin.com/tutorial There's 5 tutorials in the series now available now, and the onext one should be online within 24 - 48 hours. Since I'm now blind, these tutorials take quite a bit of time to write, so I'm just looking for any feedback I can get. What do you think? Are they of valuable information to you so far? Should I continue investing time in this tutorial series? Is there anything you'd like to see different? Again, I'm honestly looking for feedback here, and not plugging my site. I'm wondering if it's worth my time to put these together or not. Thanks in advance!
×
×
  • 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.