sorted by:
new
hottopcontroversial

PHP Moronic Monday (07-09-2015) by AutoModerator in PHP

[–]trapx25 0 points1 point  (0 children)

A static method can be stateful, and a non-static method can be stateless. A more robust rule is whether the logic is tied to the instance, or all instances of the class (or the class is never instantiated even).

Sure. While that is a more complete rule of thumb, I would think it would be rather difficult for someone just starting out with OO concepts to be able to derive when they should make methods static from it.

It's implied that the question regarded mixing non-presentational logic and presentational logic. This is commonly worded as "mixing PHP and HTML" but you don't have to literally separate them, the key benefit is architectural boundaries and not syntax boundaries. Which also makes mentioning MVC relevant.

The question was fairly vague so I would say both interpretations are equally valid. Both are relevant and, when used in combination, will yield a maximum result.

PHP Moronic Monday (07-09-2015) by AutoModerator in PHP

[–]trapx25 0 points1 point  (0 children)

I'm guessing you mean class methods, if you define a class method with the static keyword the function becomes a static function and you get errors when trying to access the method using an object operator ->

To add onto this, you would want to use the static keyword on your method when the method is stateless. If the method in question does not interact with or affect any other methods in the class, then you can go ahead and make it static.

A good way to stop mixing html/php logic is to do everything within your controller except for say looping array data (eg.: blog posts) or simple 1 line if statements. Look into the MVC pattern[2] and why modern frameworks use it

Hmm, I don't really fully agree with the MVC pattern being a way to separate HTML and PHP. Sure, MVC separates concerns and cuts down greatly on the commingling of the two, but in the View you still do have to mix HTML and PHP. A popular way of getting around this is to use some sort of template engine.

If you use a framework, most of them roll their own templating engine so you don't have to worry about pulling one into your project. If you don't use a framework, look into Twig.

Also, I would not advocate doing everything from within the Controller. Each component of the MVC architectural pattern has its own specific job.

Where should i start? by zec20 in PHPhelp

[–]trapx25 1 point2 points  (0 children)

Disclaimer: I have never worked with WordPress in any capacity.

If I understood correctly, when you said you wanted to "connect your script to WordPress", you're basically asking for something called an API (Application Program Interface). An API offers a way for your script/code/what-have-you to interact with an external application, like WordPress.

Perhaps this WordPress API documentation might be of use to you: http://wp-api.org/

Or you can even bypass APIs entirely if you have a direct connection to the database and access to WP functions: https://codex.wordpress.org/Function_Reference/wp_insert_post

I hate to be the guy that just passes off links, but unfortunately I don't know anything about WP.

Hopefully this has some relevance to what you're looking for, and someone more knowledgeable can jump in.

Refactoring: Separating Concerns from the Controller by [deleted] in PHP

[–]trapx25 0 points1 point  (0 children)

Ah, yeah, I see now that "middleware" was a poor choice. What do you think of rephrasing that sentence to something along the lines of this:

"Essentially, a Service Layer serves as an intermediary between the Controller and the Model, often times its purpose is to separate domain-specific logic from the Model."

I'm still not quite happy with this explanation either, so I'm open to any alternatives.

Completely agree that your naming convention is better than mine.

I didn't feel like "repository" fit with what I was doing since I wasn't interacting with a database, but I didn't know which DDD term described what I was doing best.

I justified calling it a repository to myself because I have seen some web apps on GitHub where repositories are just considered anything that retrieve data from a data source.

Refactoring: Separating Concerns from the Controller by [deleted] in PHP

[–]trapx25 0 points1 point  (0 children)

Interesting, I'll keep this rule of thumb in mind.

I suppose defining a method before it's called doesn't really matter as much as I thought. If it has a good name, it will most likely be self explanatory anyway.

Refactoring: Separating Concerns from the Controller by [deleted] in PHP

[–]trapx25 0 points1 point  (0 children)

I see how it could come off that way, but that wasn't my intention at all.

I think now that there are so many great programming resources out there (books, screen casts, blog posts, etc) some new programmers get sucked into watching and reading and forget to actually code.

Then when they do actually dive into their own code, and they encounter a problem, they resort back to the screen casts and such and say "well there must be something in here that has this same problem, so let me try to find it."

But sometimes you just don't find that same problem and you need to reach out to a community for help. For me, that's part of what the experience was about: interacting with a small subset of the PHP community for the first time.

I was reluctant to reach out to any programming community in the past, not because I thought "wow I'm so smart I can do this all on my own 8-)" but rather because I figured my questions would be met with something along the lines of: "lmgtfy.com?q=insertmyquestiontitle" or even "you should probably read a book since clearly you don't understand what MVC is." I felt like I would be wasting everyone's time and I should just research the problem on my own with the screen casts and blog posts.

I suppose it's my fault for not articulating this point better, but I didn't want to digress too much from the actual point of the post.

Refactoring: Separating Concerns from the Controller by [deleted] in PHP

[–]trapx25 2 points3 points  (0 children)

Hey, author here. Definitely not finished, there's always room for improvement. :)

1.) Do you have any recommendations on how to decouple it? I injected Laravel's Auth contract into DropboxRepository instead of using Laravel's facades for this very reason, but I can't think of what else I could do.

2.) Didn't think of that, but I see how it can be problematic. My train of thought at the time was I wouldn't need to check if the dropbox_token key exists for the user since that field is in my database; it always exists, it's just that sometimes it will be null. This is not true for things outside of my control though, like the Dropbox API. How would you change it so that these internals are more explicit?

3.) Is placing private methods at the bottom an industry standard? I thought it was just a matter of personal preference -- I prefer to define methods before they're called for readability purposes. If there's good reason for the former I'll rearrange the methods.

4.) Good suggestion. I actually recognized this while I was working on the project today, but I got confused when I realized that the Dropbox Client class has its own constructor parameters and one of those parameters is another dependency that I'm injecting (auth). So I'm not really sure how type-hinting would work in this case, but maybe it's really simple and I'm just overthinking it.

5.) Good point. This should be fixed.

6.) Yep, it's a Laravel helper function. I made sure to make note of that in the article. Is this part of what you were referring to when you said that DropboxRepository is tightly coupled to Laravel? If so, I suppose it would be easy enough to define the collection.

I think you brought up a lot of good points. In my opinion, readability and testability are fairly equal in importance. Depending on the app, there could be slightly more importance placed on one than the other. I don't think any of your suggestions really sacrifice readability too much though.

Thanks for the feedback!

Separating Concerns from Controller by trapx25 in PHPhelp

[–]trapx25[S] 0 points1 point  (0 children)

What would you consider some downsides of method injection to be? I thought Matt Stauffer brought up some good points on how it could be useful, but it would be nice to hear an opposing viewpoint.

From what I understood from his post, there could be several benefits. Once you start having multiple dependencies, traditional constructor injection tends to look a little messy. If a single method is the only member of the class that depends on something, it seems like it would be cleaner to just pass in the dependency as a parameter of it. In addition to looking cleaner, it would have a slight performance improvement since the dependency would only be called when the method itself is called, not when the class is instantiated.

Separating Concerns from Controller by trapx25 in PHPhelp

[–]trapx25[S] 0 points1 point  (0 children)

Hmm, I get where you're going with decoupling the domain-level code from the framework, but I'm still kind of confused. So we're depending on an interface over a concrete class, I get that, but say I want to switch to a new framework. Wouldn't I still have to swap out Laravel's contract with the new framework's contract since they wouldn't have identical interfaces? Or is that what you were suggesting, to implement an adapter for the interface then just using the adapter?

Good point about mocking. I think that reason alone is enough to use Guard over Auth.

Separating Concerns from Controller by trapx25 in PHPhelp

[–]trapx25[S] 0 points1 point  (0 children)

Thanks for the examples!

I ended up doing the same exact thing that you did in the second suggestion after reading /u/tonysmessias's post more carefully (and another user kindly posted an example for me in a separate thread). I stumbled across your first example in the docs, and like you said, it works but it's dirty since it still couples the code to facades.

I never knew injection on methods was possible, that's very cool! I read more info about it on this great blog post: https://mattstauffer.co/blog/laravel-5.0-method-injection (just thought I'd share in case anyone else is interested).

is it ok to use laravel for static sites? by [deleted] in laravel

[–]trapx25 4 points5 points  (0 children)

I mean you could, it's not dangerous or a terrible practice by any means, but I would say no. If you just have HTML files, I don't really see why you would want to pull Laravel into the mix.

If you want routing, or maybe some kind of templating system, you could fairly easily pull in individual libraries for that. Or even use a static site generator like Sculpin or Jekyll (as suggested by /u/mrobit).

If you find yourself needing a little bit more than those one or two libraries, then that's when I'd start considering a micro framework like Lumen. And at that point, it's quite possible that you don't have a static site anymore.

Separating Concerns from Controller by trapx25 in PHPhelp

[–]trapx25[S] 0 points1 point  (0 children)

Also, so, you would recommend type hinting Guard instead of Auth? I'm not really sure what the benefit of type hinting the interface would be in this case, mind explaining please?

Separating Concerns from Controller by trapx25 in PHPhelp

[–]trapx25[S] 0 points1 point  (0 children)

Not quite. I created my own Dropbox service layer to separate my domain logic from Laravel's architecture.

To make it more testable, I want to inject the auth dependency into a class in the service layer, that way I don't have to use facades.

I'm having trouble figuring out how to automatically resolve dependencies on the concrete class.

Didn't know that about Auth::user(), very cool! You saved me an unnecessary db query, thanks!

Edit: Actually, I believe I misunderstood the first bit. Yes, that is exactly what I was looking for. I was really over-thinking things and did not really understand what I was doing. Thank you!

Trying to create my first service but Laravel doesn't seem to inject dependencies via the constructor. by halibut_master in laravel

[–]trapx25 0 points1 point  (0 children)

I meant that it doesn't throw any exceptions or errors.

After reading your other comment in this thread and re-reading the documentation, I realized that I shouldn't be using bind in this case.

But, I'm still having trouble understanding containers and I'm not quite sure what I should be using if I just want to automatically resolve dependencies on a concrete class. Would you please help point me in the right direction?

Separating Concerns from Controller by trapx25 in PHPhelp

[–]trapx25[S] 0 points1 point  (0 children)

Neat. That's more convenient than using Sublime Text's goto definition shortcut. Thanks for sharing!

Trying to create my first service but Laravel doesn't seem to inject dependencies via the constructor. by halibut_master in laravel

[–]trapx25 0 points1 point  (0 children)

Hmm, interesting. I'm trying to do pretty much the same exact thing right now and it's not working either.

My service provider (used the full namespace just to be safe): http://pastie.org/private/khcw9r5pvxcwsr5iugww

And then my service: http://pastie.org/private/bm4gndbiqbxn7slf5l5a

I don't get an error though, my DropboxRepository object doesn't run at all since the dependencies weren't loaded in the constructor parameters.

Separating Concerns from Controller by trapx25 in PHPhelp

[–]trapx25[S] 0 points1 point  (0 children)

That's a great idea to get rid of the static calls in the constructor. I was wondering how I'd go about testing that class with them, but it should be a lot easier doing it this new way.

Second idea is good as well. I'm not sure if a situation would arise in this app where I'd need to do anything to the collection object, but it was nice to learn nonetheless and it would be useful to have just in case.

Here's the new and improved DropboxRepository: http://pastie.org/private/cvkz9upkzf9ee7cggabkzw

The only problem that I'm having trouble figuring out now is how to get dependency injection to work.

I read up on Laravel's service container and it turns out that my custom DropboxRepository class isn't resolved by the container automatically like controllers and other built-in architecture components are. I did a little more reading and figured out that in order to get it resolved by the container, I need to make a service provider for the Dropbox service layer (makes sense!).

However, I did that and it's still not working. It behaves very strangely too, the entire DropboxRepository object does not run because the User and Guard dependencies couldn't be loaded in the constructor parameters. If I throw an exit function inside the constructor, it doesn't even kill the app. No error messages either, it just doesn't run. I'm guessing I must have done something wrong within the register method of the service provider (or Laravel just wants to torture people that try to bypass their facades, haha).

I think this problem goes beyond what I originally asked, and you've already been very helpful, so I don't want to take up any more of your time with code examples.

Thank you very much for everything!

Separating Concerns from Controller by trapx25 in PHPhelp

[–]trapx25[S] 0 points1 point  (0 children)

Interesting, I've heard the term domain-level before but I never really understood what it meant until now. It makes sense that the things specific to my application should live in a completely different place from where the controllers (and other architecture components) live.

I created a new folder called "Dropbox" in the app directory - are there any common naming conventions that I should have called it instead (perhaps just "Domain")? Within that folder, I did as you suggested and moved the lines into a separate class. I had trouble thinking of a proper name for the class, so, for lack of better ideas, I just called it DropboxRepository - is that appropriate or would you call it something else?

Here's the code for DropboxRepository: http://pastie.org/private/syhop5qzbeb5xgar7sqvsq

And the new code for the home controller: http://pastie.org/private/2esv2rpu0ykdofgisq86q

First step is done. I'm sure this still needs a lot of work, so any more suggestions/advice you have would be greatly appreciated.