I'm using laravel framework and mysql to build a site which needs to be translated into, at the moment 3 but it may increase, different languages. Using Laravel it is relatively easy to create different language files for different languages and call them in the html for relatively static strings. However, for data coming out of a database, what is the best practice for localizing such data? It seems that storing the localized versions of the strings would work well in the sense that they can all be added at the same time as the data is created; however, it seems it would be horrible in the sense of adding a new language. Using language files for the data seems better for adding new languages, but would be annoying to keep up with when new rows are added to the database.
I've come up with a solution to translate some of the data in a relatively static selectbox (it uses a static array of ids/names of some of the most common data) so that users may be able to utilize that part of the site pretty well no matter the language, but the data as it shows up on the rest of the site is naturally unaffected by that change.
What is the best practice for handling such an issue? The few solutions I can come up with all seem rather flawed.
Note: the new rows are added on a management site which is separate from the main site, but shares the same data in the database. The people adding the new rows would not have direct access to any language files.
Instead of reinventing the wheel, you can try something like Laravel Translation - https://github.com/Waavi/translation
Related
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.
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 2 years ago.
Improve this question
I have been developing a program for the visualization of some data. My program takes specific input from a MySQL database and draws some graphs (libchart library), creates some tables etc.
My problem is that right now its a code hell in there. I have around 7 php files (index, graph-page, gallery, etc) with HTML/CSS and PHP/SQL code all together (some of them just have the php extension but have only HTML inside). I have no problem to read and understand the project for the time being, but I guess if someone else tried to, he might get a headache. Plus, continuing programming like this is not practical because the project might not be easily scalable in the future.
Do you have any suggestion on how to successfully seperate HTML/CSS from PHP/SQL? I don't want to use a framework since I'm not doing anything that requires user-input, session handling, etc. I just run some queries and visualize the results. I'm mostly talking about architecture here, and if applicable perhaps a script to help me (I've read about Smarty but I'm not sure if that's what I need).
Do you have any suggestion on how to successfully seperate HTML/CSS from PHP/SQL?
Congrats for looking how you can improve code. That's the precondition, you need to want to improve it and the topic is lengthy. So your will is crucial.
I start lightly and then try to give some tips. As you're missing experience, look for one point to start with, most certainly the last one of the list below. But first things first:
To separate something from each other, you need to have some code that separates:
[HTML/CSS/PHP/SQL]
[HTML/CSS] <--> [SEPARATOR] <--> [PHP/SQL]
The Separator here actually is PHP code as well, but I think you get the idea.
As you can see only the Separator talks with HTML/CSS and PHP/SQL.
So both HTML/CSS and PHP/SQL need to have an interface with Separator (the line between) to make this work.
Normally in a program you pass around data that get's processed. The data is pretty dynamic and can have a compound complexity, especially if you pass data to an output routine that should format it properly.
There are multiple ways of how such a Separator (or multiple of them) can be written. You can layer your software or provide components that do things in their area or domain. E.g. you have a database layer or database component that takes care about the interaction with the database.
Or you have a templating engine that takes care to put your strings and arrays into some readable HTML.
In short this is the pasta theory of software design:
Spaghetti code - all in one, code is heavily interwoven, preferable with Bolognese or Aglio, Olio e Peperoncino.
Lasagne code - Layered, one layer has two other layers it interacts with (unless bottom or top), always with Béchamel sauce.
Tortelini code - Small components that just do their job, they have Meat or Spicy Vegetables inside.
Like we eat different pasta in our lives, when programming we need to deal with all these different type of code as well, and we develop our own preferred taste over time. As a kid we're feed but over time we start to cook something our own and vary the recipes.
So I think it's a good point you just don't want to now eat MVC Framework X with much awesome for the next weeks only because somebody told you it's the way to eat now. And before eating, there is tasting, right? Not to mention fast-food, you know like these noodles with sauce in package - only add water. Urgh.
I don't know which data your output needs and what the input is. Following are some rough refactoring tips for applications that output HTML/CSS and interact with a MySQL database. This can not be a complete list and the descriptions can only roughly outline some thoughts:
Move CSS out of HTML. Use selectors effectively in the linked CSS definition and replace any style attributes if you still have some. This makes your CSS code re-useable and more modular. It will help you to find flaws inside your HTML and to separate the Structure (HTML) from the Presentation (CSS). Effective HTML start with effective usage of CSS, those two are very powerful together and often this already will lighten your programs output routines.
Move business logic out of HTML. Both HTML and your code can be a beast, so better keep them apart. They have the tendency to fight with each other, and as both are very powerful, the fight will continue while you develop your application, that distracts you from the work you need to do.
Consider if you need to already have complex output inside your application or if you can just pass on arrays with subelements (a key is a var, a var can contain a string or number or another var-array). Normally that is all needed to pass even complex data into a view or template. You HTML then only needs to echo some array members and or foreach over subarrays. This is a very simple technique to create a template. You can use PHP for it, so you're actually really flexible (just draw the border which code belongs into your view layer and which is part of the application, e.g. providing values for the view).
Move SQL out of your code. Move the database interaction code away. Create yourself one or multiple objects that have methods which return the data in a way you need (consume) it in your actual processing code, like $component->getThatData() which then returns data in a normalized form. Make those components then use a dedicated database component to talk over with the database. In your application code (business logic) only use the database component and preferably the objects you create to get the data, so you don't have any line of SQL any longer inside your main code.
Divide and Conquer your application code: Divide your code into Transaction Scripts. They are often easy to create from existing spaghetti code and will be probably become the said Separator you're looking for in middle terms. They will then have the role to process data and passing it on (into the output/view).
Use clear language: If you have complex formatted string data that is not normalized, write yourself Parser classes that do the work for you and which can be easily re-used (if that's the case in your application). As you should look forward to minimize the use of plain SQL in your code, you should also look forward to move complex regular expressions away as well. Encapsulate what varies is a key point. Same applies to long routines to just handle some data (e.g. sort, order and arange it in another format), move them into components of each own and think about how you can make them accessible and re-useable.
Make your code functioning: Find out about the logic how you invoke functionality in your program. You can try to separate functionality away from how it's invoked. E.g. some routine that invokes any of the Transaction Scripts. This might not be necessary if you request PHP files directly via the browser, as those are then your transaction scripts and the webserver takes care to resolve the command send via URL into your application to the transaction script. But you should then wrap any logic needed to process the incoming command and it's parameters into re-useable components (e.g. a Request class that contains standard code to get the URL and or variables from a HTTP request).
Create a common entry-point by including the same file at the very top of all files that are called via the browser. You can then put common code (like setting up the application session state object and initializing the database component) into it, see as well Application Controller
Remove duplication by looking for literally duplicated code. Wrap it into a function or class. Create a library folder for your own application into which you put your includes. If you follow a common pattern with Classnames and Namespacing, you can easily use an autoloader to keep inclusion easy. Make your library apart from third-party code. Place all third-party code into a library folder of it's own with one subdirectory for each third-party component.
Use lightweight, existing components. Lightweight is important because you have your own code already, you don't want to turn and press it all at once onto a framework.
Existing is important because you don't want to re-invent the wheel. You will have enough work for your own refactoring your code. After you feel better about your application and you still have power and will, you can always write everything new. But if you're alone or in a small team, Existing is pretty powerful.
Simple libraries are for example:
Templating engine: Mustache
Database layer: NotORM
Create Application State, e.g. as an object you can make use of in case some components need to know about the application state or each other without direct interaction. By default in PHP if you don't have one, global and global static variables are used to create state. However these variables can make your live hard as code grows. When you create an application state object, it's clear which components make use of it, access to it can be controlled (e.g. calling a method instead of reading a variable, which can help with debugging) and components as well can find out if it's the right time in the application flow to come into action. It's also a good tool for refactoring your code over time.
Preserve a Working Application, keep your code in a state to run. Ideally this would be backed up by automatic tests. Consider that you need to rewrite much. For example if you start to integrate a database component, do it. Move all your existing code to it in one step. So who tells you it still runs? Use git for better undo and to test stuff. That's more important than choosing the right library. Preserving a working application is also always the key point because that's why you change it, right?
Why not use a templating engine? TWIG is very easy to use and great for this sort of thing. It is often used with the Symfony framework, but can easily be used on its own.
as you don't need user input and store session.
You can just create a controller -> model & controller -> view structure
the controller: will help you get data from DB (via. model) and embed data into view.
You can create 3 folders controller, model, and view. In each folder, you can create files based on your needs(e.g.MVC for User).
The model can access static objects written in mysqli.inc.php or pdo.inc.php based on your need you can write a template for connection, query, disconnection, in all your model classes.
In model file, you can call static function DB::query('SELECT/INSERT/UPDATE/DELETE', );
For view, you will need a render function to embed data into HTML Code for example
function render() {
//start output buffering (so we can return the content)
ob_start();
//bring all variables into "local" variables using "variable variable names"
foreach($this->vars as $k => $v) {
$$k = $v;
}
//include view
include($this->file);
$str = ob_get_contents();//get teh entire view.
ob_end_clean();//stop output buffering
return $str;
}
In the controller, you can include your model file call particular class and function for data. Call view file with render function for example,
$view = new view('../view/data.php');
$view->name = 'Your Name';
$view->bio = "I'm a geek.";
echo $view->render();
you can either return or echo your view based on your requirement
This is a long and old question that doesn't get to the point. I basically wanted to know practices involving flat files and the extent they could be used, as a replacement for SQL, mostly in terms of multi-user capability.
At the time, I was wanting to replicate a SQL table editor interface with flat files, allowing collaborative editing. Basically like a multiuser Excel, with an automated data-entry interface, and interactive sortable tables.
I also wanted to build a CMS index page for a server, which parsed text files in order to construct a dynamic webpage, which allowed for easy updating/managing.
I've been beginning to learn MySQL, and XML. For dynamic data storage, I prefer XML over MySQL because it doesn't require a server and can be edited within a text-editor, but I'm unsure whether they can be used for similar things.
(I know that MySQL and XML are two completely different things, but I'm looking at this in regards to data storage.)
In the past I've manually stored lists of stuff in *.txt files (to keep track of things), sometimes with multiple fields per-row kinda thing, like a table, or lines with related data. HTML tables are good for this, but it would be even nicer to be able to edit directly in the page without the need for a text editor, and in certain situations, allow multiple persons (collaborative editing) to edit different sections at the same time.
(I want to use PHP to create scripts that can do this - allow editing of files in browser, including collaborative. I want to learn data manipulation methods in general.)
So basically, I want to create an index for whatever scripts and documents I'd want to display, in the form of a Content Management System. I'd want pages to be modular somehow.. Some modules would be a CRUD (create, read, update, delete) with tabular data, another module could be a pastebin-like text dump derived from a PHP script, some sort of article-publishing system for wiki-like linked articles, single articles or blog posts.
Anyway, I've made scripts that parse XML files, and I like the idea of separating content from presentation, but I don't know how/if XML could be incorporated into a CMS (or any dynamically-editable situation), as most popular ones use MySQL. This is only for personal use and not for some big site, and it would be nice for it to be simple and portable, only requiring the Web server. I'd only prefer MySQL as a last resort, as I don't like having to setup MySQL every time I switch servers, or going through MySQL connection errors.
What should I do / Any suggestions?
I prefer XML over MySQL because it doesn't require a server
I prefer to travel on foot rather on wheels because it doesn't require a car. So, I spend 6 hours to get to my job and back every day.
XML can be edited within a text-editor
In theory.
In practice, XML is bound with such a number of strict rules and standards that you scarcely can edit a comma without breaking the whole file.
Face the truth - it is for programs, not humans.
In the past I've manually stored lists of stuff in *.txt files
You'd better stick with this approach further
HTML tables are good for this,
HTML tables are worse for this, even worse than XML.
I want to create an index for whatever scripts and documents I'd want to display, in the form of a Content Management System.
You are taking Content Management Systems wrong. It's Content Management System, not scripts management system. It merely manages the content, the data stored somewhere.
I like the idea of separating content from presentation,
I like it too, but your XML has nothing to do with this idea.
What should I do / Any suggestions?
Learn to drive a car. Do not remain a pedestrian.
Learn databases.
An interesting reading http://www.joelonsoftware.com/articles/fog0000000319.html
So you have two questions: "Can XML be used like MySQL?" (No, it must be treated different, use XPath instead of SQL etc.) and "Can XML be used for building a CMS?" (Yes, there are some like that, e.g. GetSimple CMS - see http://get-simple.info/start/)
You must be aware that XML is suitable only for smaller amounts of data, but in that case you probably don't need the weight of a database.
I am considering to use a php framework (never used one before), I know I have to abandon the way I am used to work (I can deal with this), among many concerns a first thing that comes in my mind is this:
I have two techniques I like to use (have used them for years)..
I always use index.php?somePage.php as href so never loads another page other that index.php, then index.php includes the somePage.php
I always used to store all texts, any text, titles, button names, link names, stories, articles, anything, in a single (or more) files or in GLOBALS array (depending on size).
I want to ask is this aproach wrong, is there any better way?
Second, from what I have read freamworks have some rules, does my approach create some conflict? I am thinking of KISS_MVC framework cause it declares to be easy for framework beginers.
I have no experience with frameworks and I am concerned, about all this, I can't wait for the day I will feel like home with using a framework.
Thank you all in advance!
That pattern is known as front controller - it gets all requests and routes them internally (not based on file loaded). That pattern is fine, it should look like /index.php/whatever to which you can then patch over with .htaccess to make /whatever (Examine $_SERVER['REQUEST_URI']).
Database is a good place to store large amounts of text. Files you create rarely are - they offer none of the advantages of using a database. $GLOBALS rarely is a good place to store data. You generally should keep as little as possible available globally. You can make a registry class to store global stuff if you need.
The best way to know what does and doesn't work with a framework is to try and get familiar with a popular one such as Zend, Kohana, Yii, etc.
Are there any PHP based CMS which could be integrated with an existing database? My client already has a big inventory solution which was written in VBA. Now we need to setup a web based shop for them and we are thinking of setting up a CMS from the shelf.
Is there any way we can integrate the current database scheme with that of CMS ?
That depends entirely on what the big inventory solution does, where it is running, how it is structured, and how the two solutions are supposed to coexist.
Usually though, you will want to make use of existing export/import functions on both sides (e.g. XML) instead of having two applications meddle with the same data base. That often ends in tears.
The issue is that the CMS would have to understand how the database was laid out. Even having a different number of columns would prevent the CMS from understanding the structure of the tables. A CMS isn't a human. It just interacts with data how it's told, it doesn't ever interpret or understand the data.
Your best bet would be to first install a simple CMS with a table prefix (something like installing WordPress with "wp_" as the table prefix) to prevent it from over-writing any existing tables. After this you would need to write a plugin for the CMS which tells it how to read your database. It may be possible to find a plugin which already does what you want and then modify it to use your table design rather than the intended one.
In either case, though, the information in a database is part of the site's content. As such it's the job of the content management system to both create and maintain it. Creating it outside of the CMS will generally confuse it and require some work to integrate it.
first of all, just for curiosity, why cms and not framework? Using framework will ensure you can fully integrate your existing database with less effort (in terms of long-time consistency and reliability).
Still, if you want to stay with CMS, I would recommend Drupal. They have nice feature which allow you to interact with multiple databases without modifying your current data structure. Furthermore, you can build your own customized modules or even installation profile to suits your need.