For the most part, the 3 sites for an organization I run have a single MySQL database that they share. This allows them to interact with each other nicely.
I have a bunch of simple parameters that the sites need to know about, and I wasn't sure what the best route to take is:
Make a table with 2 fields (key, value) where I store the params
Store the values in one or many flat files
They each have advantages and disadvantages.
The database allows a single entry to be used for all three sites (however, this doesn't occur often), all the information is centralized, and the interface is already well defined.
The flat files are easier to work with as FTP and a text editor can be used in addition to website administration, the flat files can be written as PHP meaning the site doesn't have to do any parsing (just need to include the file and use the variables), but they can't be shared between sites.
I can go on and on. What do you think is the better route to take?
My opinion is to use a database if you have the chance. It's easier on the long run. You have built the website, with the flat files, but now the customer wants an additional page with slightly other parameters, so you have to add a new file. Now you are done with this and he ask you again.. well, you get the point.
It is not organised at all. So if you have the chance to use a database, use it. There is reason why it is invented.
But just to get my thoughts clear and firmly know what you are talking about, please tell me more about the settings you would like to store. I can imagine that you are talking about some global variables, or maybe even going to use a define(), but it is also possible you want to store strings.
So please define "bunch of simple parameters" for us.
Related
I'm currently working on a school project that requires building a php application. I've started off by writing most of the functions the application will be needing however i'm not comfortable with the fact that i have to go through all my code to find and change the strings that get printed to the user, being that i make very frequent changes.
I was wondering if there was a better approach? Kind of the way android handles multi-language applications by having all the strings in one file. I understand that the main reason for this is for translation and since my system only has one language, i don't really require this.
So would it be wrong (I.e: it would somehow bring to further complications) to use the same approach?
I was thinking of a class with a bunch of static variables which could be referenced from the other functions.
What about what Mario is suggesting? I understand that this is not my case since i don't need multi-language support but being that the case would a db still be a bad idea?
Thanks
For translations, it depend on size of file, if it will be small one - sure. Can be all in one file. But if project will grow. Better is group strings and put in different files.
It will help only to find and edit it. Doesn’t matter for speed or error handling.
Different thing is separate php & html. But this also depend on project. In some it's OK. I think best is to have separate template global layout from php generated only output. In PHP you will any way put some html tags.
Functions, best - should be group in class. One class - one file.
I am new at web development, and I have started to work on a small website just recently. Now the problem is, that since it is my first time, I move my pages a lot on the server, because of which I have to keep updating all the other pages that link to it. So, I was thinking of a dynamic way of linking the pages, so that I don't have to update at several places, but only at one.
How it is going to work is that,
there is going to be a separate database kind of thing that will contain all the webpages' updated address, and a unique key to identify them. eg. page12345 = "/about/us.php"
and anywhere where I want to include a link to the page, instead of typing .., I'll have to type something like .., or something like that
This method will also enable me to assign tags/categories to pages, and, or add other properties to them. And, I'll probably also use it for media files as well later.
Now, the thing is, I can think of only two ways to do so, one is using an array in PHP, and other is using MySQL database. The array will probably be too much to handle when the site grows and there are, like thousands of pages, on ther other hand, MySQL database will probably prove to be slower, and at the same time more of a hassle.
So what is it that you suggest? Which will be more efficient. Or is there a better way, I am open to any other ideas that you may have.
The typical way to manage that is to not worry about URLs manually at all and leave up to a router. In the end, URLs are just a technical implementation detail of the HTTP protocol. What you really want to do is identify specific pages/actions uniquely. Have a look at any reverse-routing capable router; here the Symfony implementation:
blog_show:
path: /blog/{slug}
defaults: { _controller: 'BlogController::showAction' }
Read this blog post.
This is admittedly a very high level abstraction, using YAML for specifying routes and Twig for templating with a custom defined function. However, it hopefully demonstrates the goal: don't worry about URLs much at all in your actual links. You need to have one canonical place where URLs are defined (the path in the above example), everywhere else you just refer to your target page by name (blog_show here). If you need to move URLs around, there's exactly one place where you need to do so. The thing in the middle that makes this work is the router.
I don't know if this question belongs here or not, someone please move it to an appropriate place if needed.
We are working on a web application using PHP and MySQL. The software is of the sort that provides a lot of pre-fed data to its users. For example, a list of questions and answers like a knowledge base. Now every user who registers into the system would have the liberty to add/update/delete this knowledge base, without affecting the data of the other users.
Now I understand that we would require to have a master copy of this pre-fed data, and would have to make a copy of this data available to users.
I was wondering how to implement this in the system without affecting the performance.
Would we have to create separate databases for each user?
Any pointers?
Thanks!
I find three approaches to this, they'd depend upon your domain requirement.
You're 'seeding' configurations and basic data for which it does make sense (to me) to localize the settings per user. I guess most of the apps follow this.
If it's domain data, when you say knowledge base (which I take to be very huge), it'd make more sense to save the per user edits and merge the master data with a user's personalized data. This is a very abstract & I wouldn't know it's implementation unless I actually see the data modeling, but then this looks a viable approach!
Save edits from all the users separately at one location (per collection or however you wish) if you want collaboration and stuff. With this, I think, it'd be easier to grow your knowledge base, although you can do the same with the previous approach with a little help from DBA!
I have been playing about with an Ajax/PHP site and I am wondering about the best practices concerning calls to multiple PHP files Vs a single PHP file with many functions in it.
All of these calls are simple database access calls - returning data from a query. It seems a sensible thing to have a single file that opens the database and contains multiple functions, one for each of the calls, however I do not know the best practices in this instance and I am unaware of any security concerns that there may be.
Does anyone know the best practice in this case?
Cheers
BK
It's a matter of opinion, really. If you haven't got much code, and don't intend to re-use any of it elsewhere, you may as well just have it all in one file. You don't want to fall into the trap of over-complicating what might be a simple setup.
If your code starts to build up and become difficult to follow, you will then be better off splitting it across a number of files based on the sort of task they perform. This is the concept frameworks are based on, where maintaining a more complex application structure is more beneficial to your productivity than fumbling with a monolithic index.php.
And finally: it is vital to take these considerations into account when expecting other people to work with your code.
This is all based on personal preference. Personally, I like to have multiple files as I feel as though it better organizes my code.
However, many people feel as though using only a single file makes locating code more feasible, and thus editing code more efficient.
As far as security is concerned, there is no difference in one using one file verse using multiple - just make sure you are be cautious when coding, not leaving anything open for injection etc.
Sorry for the confusing title....
We are developing an application to be used by multiple companies. For the most part, the application is the same, your standard sort of database manipulation pages (search pages, edit pages, etc.) customized for the data that it is designed for.
However, each company has a slightly different process, and we will be dealing directly with each company so we'd like to use some sort of system that would allow us to tweak pages depending on which company is viewing the page. For example, one company might want a couple extra fields on a data input page, or another company might want to view a different piece of data on a search results screen, and so on.
I understand this is all hypothetical and I wish I had a concrete example to give you, but honestly the companies haven't even given us very good examples. We just want to be ready.
So my basic question is, what is the most flexible way to allow for these tweaks and customizations on a per-company basis? Obviously, the most flexible but least programmer-friendly way would be to make a complete copy of the app for each company. This obviously isn't an option because we'd need to manage updating code on all the sites, trying to keep them all running and tested and having issues resulting from the customized code.
What are your thoughts on Smarty being a solution to this? Perhaps if we have a master set of templates, but then each company can have a different subfolder with any replacement template files... Of course we'd still need to update a bunch of different template files whenever we change one of them, but it would be a little more localized anyway.
Is there a better way? Some sort of differencing template engine maybe, so that we can still edit the original files and the changes will adapt on top of the originals (kind of like a patch)? Or perhaps we should use the object-oriented features of PHP5 and then use polymorphism? What is your best suggestion, and especially if you've had experience with this sort of thing, what are the options and which have you used and why?
I think the template method pattern will help you out a lot. It's really a great pattern for factoring stuff that is mostly the same but differs in a few places. I'm actually working out a template method hierarchy for my own project right now.
I would suggest you try to create the application either using an mvc framework or using your own implementation of mvc.
In this manner you could create models that could be reused (and also views) for other companies.