Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have read a lot about singletons, most people agree that they are bad practice and to avoid them, any way possible. Most people say this because it's hard to debug apps that use them.
Now, creating a simple CMS, I tried a few approaches and they seem to me the best choice.
Configuration data
That file is loaded on application start and I see no reason why I wouldn't use singleton pattern when calling config data throughout my application?
Request data
Request data should store all info from php server variables (POST, GET, COOKIE) so it can be used to read and write (e.g.cookies) data using singleton throughout the application.
Response buffer
I want to use response class (as singleton) that will hold all data that is rendered by my templates. So application can load all views render them one by one and store the echoed data in the response class, and at the end output entire document that is stored in response.
Questions for all examples:
A) Is that really bad practice, and why? I see no evil here.
B) Is there an alternative / better way?
Thanks!
Is that really bad practice, and why, as I see no evil here?
Design patterns are suggestions, not standards. You can use them, hate them, call them "anti-pattern" and do whatever you want but that will just be your opinion. The gang of four and any blogger out there express their opinion about it just like the way you do, and guess what? it doesn't really matter.
Instead of asking yourself if someone consider it a bad practice, ask yourself: "Do I consider it a bad practice?". If the answer is no then go for it.
I'd suggest you to read both sides (pro-singleton and against it) and make your own opinion about it, before taking this decision. But in the end there's no right answer, it's just a matter what you decide.
Is there an alternative(better) way?
Generally speaking I tend to use Dependency Injection more than Singleton where I can. But if there's no way I could use DI and Singleton is an option for me then I would surely go for it.
My suggestion is to learn the most important patterns and use whatever makes sense to you in that particular context.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 months ago.
Improve this question
I'm trying to offer to the users (will be open to the internet, anyone can register) a WYSYWIG editor where users can input BLADE code to code their pages.
I want to provide them with the ability to create small functions to parse arrays/strings so I saw the #php tag of Blade useful for this.
My question: I can't find anywhere if this is like a sandboxed environment where only certain "safe" functions can be run or if this is more like an eval() and thus allowing people to basically inject PHP code to destroy the server and/or pull sensitive content?
I tried testing running basic commands with blade, but I would like a professional opinion on whether it's a bad idea regarding security (like, know exploits or other performance issues)
Thank you
Having a WYSIWIG open to the public on it's own has it's own challenges, because you will have to look into sanitizing the input/output otherwise you'll be opening yourself up to XSS attacks.
Allowing PHP code as well is obviously going to have lots of security risks, I wouldn't advise it personally - but it is technically possible. There are other online php sandbox editiors available, how exactly they secure themselves is beyond me. There are a lot of clever tricks that can be done, trying to whitelist or blacklist functions you deem as safe/unsafe is probably the way to go - but I still personally wouldn't feel comfortable implementing something like that. You may think you've covered all possible attacks, but it only takes one that bypasses what you've setup to essentially take over your server.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I know very little about design patterns out there. In fact i never worked with one yet, as i always went for raw coding. But i think its time to enrich my knowledge on design patterns out there. Specially i want to know more about Factory, Singleton & Strategy design patterns. I googled about them of course but I still not clear about their differences, how to implement them etc.
If anyone can suggest me some good document where i can read much more, that would be very much helpful.
Thanks in advance for helping.
https://sourcemaking.com/design_patterns is a very helpful website, with a lot of explanations and code samples, including PHP ones. I added very short summaries in my own words below. Disclaimer: because they summaries are very short, the may not be very accurate, but give you an idea on how the patterns compare.
Factory Method: https://sourcemaking.com/design_patterns/factory_method
In short: you have a separate class that is responsible for creating instances of a certain class. This is to make sure that a class is always constructed 'in the right way'.
Singleton Pattern: https://sourcemaking.com/design_patterns/singleton
In short: only one instance of a singleton class is possible, the class itself has a static class variable that stores the instance, and a static method that returns the stored instance, or create one if it is not yet created.
Strategy Pattern: https://sourcemaking.com/design_patterns/strategy
In short: if there are multiple ways to solve some problem, provide a set of classes that each contain one implementation to the problem and let the client decide which implementation to use.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've been playing around in the Web Development field for 2 years now and I am pretty proud when it comes to my progress as a programmer looking back at my humble beggining. This is not very relevant but I've wanted to back up my question with some background story. What it comes to my interest during a conversation with a friend was how to best structure your code when it comes to a website so it wil be very scalable for further modifications using an oop aproach. He suggested at the end of the discusion to use php classes to generate the html content. I personally use it like this only when the php helps me to retrieve something server-side related. I use HTML, CSS and JavaScript (in that order) as much as possible before calling in PHP. That's how it should work, in my opinion, especially when you have to work on a presentation website for example. What's intrigue me thinking about my friend proposal is that I structure my code that way using php clases to echo html content parts like header, menu, forms, slideshows, footer etc. will indeed scale my code way better and help my programming skills progress. I should end up with an index.php that returns objects of the respective classes creating that way the desired html content. This is how I image things working and I am asking you to help me reach a decision. I have some upcoming free time available and I want to invest it in becoming a better web developer.
It is generally a bad idea for all HTML to be generated this way.
In professional web development you often have front-end developers and designers whose only responsibility is the HTML/CSS/assets and/or JavaScript. The backend developers, (the ones writing PHP code), are usually responsible for the business logic of the application.
By having PHP generate HTML you are violating separation of concerns principles. Things will get messy. It's harder to scale up, and you will lose the benefits of being able to use a HTML editor.
Generating HTML serverside dynamically has uses in very specific circumstances. It can be done, but just because you can, doesn't mean you should.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Recently, i heard alot of JavaScript being used sever-side. Node.js, express.js and similiar stuff are mentioned more and more, but i never had the muse or time to dig deeper into the topic.
Now, as the information flood would not decrease, i can not longer ignore those circumstances.
I wonder about two things:
Can i replace my complete, simple PHP backend, which is primary used only for database access, with server-side Javascript
and if yes:
are there any benefits of doing so?
and if not:
Why is there such a hype?
The topic seems to be quite complex and not too easy to learn, but as time goes by, i more and more get the feeling that this maybe will be the future of backend coding.
Yes you can.
If you are primarily serving data, a more contemporary approach would be to use node.js to implement a restful api . Node.js is particularly suited for this as it inherently works asynchronously - which means each request to the data source (ie the database) inherently does not block while the server is waiting to return, allowing it to punch well above it's weight in terms of being efficient when servicing many requests.
You could use the node modules express.js or restify.js to implement this.
A warning though - node.js is a single threaded application which means some work has to be carried out before is scale able. There are some good solutions for this, such as using Amazon Elastic beanstalk. But as node.js is a relative newcomer many other proposed solutions may need some coaxing to be production ready.
You may find it beneficial to read 'Javascript the good parts' by Douglas Crockford before you begin - something I needed to bring my knowledge of Javascript to a level where I could write quality maintainable code for node.js
Yes you can replace it.
Main concepts about Node you have to know is being async, second is being event-driven.
So if your PHP app just accesses db and serve responses back, node.js would be more efficient in such applications, as would not block idling for response from db, but can process with other requests and so on.
It is not complicated, if you do it. Just go and dive into. Don't ask - prototype. It is the best way to understand if you really need it or not.
I've replaced all my PHP need to node.js, except templating.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've been mulling over the idea of caching html in variable. I'm using PHP, in my functions include I have declared a variable. In the site pages I test the variable to see if it is empty, if so I call a function and populate the variable, or dump it into the page.
In the testing I've carried out it works as expected. I guess my question is, is it a good idea? What are the potential problems with this as an approach?
Regards
The cons for this method are related to dynamic content that need to change based on the current user visiting. If you can identify portions of your Markup that are expensive to generate but are quite static regarding users visiting the site, you can do this.
But you need to put some thought into your page structure. And to cache Markup, you use output buffering :) obviously and database transients I presume, unless you want to do it in memory.
Also make sure it's worth caching markup and it's not easier caching data structures. Like arrays, objects that are generated from DB and are expensive to rebuild. Caching data structures makes your caching Markup agnostic and you can easily restyle your site without having to invalidate your entire cache.
PS: #Bart, I rolled my own framework and it's not an inferior product :) Stop being a user and start being a developer. Experiment, learn, build from scratch, get near the metal, see sparks flying, feel the burn.
Of course caching is a good idea. Lots of people use an in-memory store, like Memcached or APC cache.
The major drawback is it usually takes a good plan for invalidating caches when the information is no longer up-to-date. It's also a decent indicator you might be prematurely optimizing (or making up for poor-performing code without fixing it).
In your particular case, you might be better off using output buffering or loading views. Most people wouldn't consider this "caching."
No it is not a good idea. Read into MVC: model-view-controller. There are many decent frameworks out there. Get to know them and use them. Rolling your own will most probably create an inferior product.
Good luck!