Just a quick question I know how I would build a cms using a database but why would you want to create a cms with xml?
What are the pros and con's using xml also if I was to build a cms with xml would I need the help of a database of does xml just remove the need of a database?
I havent't seen CMS without a database in a while.
I think most of those were developed because "a long time ago" you didn't always get access to a database when purchasing/renting webspace.
You might be interested in storing your data in a changing format. XML definitely allows that - being able to define your own tags at will is somewhat akin to being able to add and remove columns without migrating data.
XML can remove the usage of a database - but as the size of the XML file grows, lookup and search become ever more costly. For a personal content management system - especially one where you are looking at the beginning of a file in your most common use case - it could be an acceptable solution.
Making a CMS like this would be something like using TiddlyWiki, which is a single html file that hosts an entire wiki.
For even slightly larger scale CMS, I would immediately opt for a database - probably SQLite for smaller scale, because it's the thing to do nowadays.
Related
I'm writing a webapp in german, so all buttons,text,tooltips etc. are in german for now. But I want to use some kind of template file for the webapp so I can quick change to another language if needed. I thought about textfile that I explode with "\n" and load into a sessionvariable to have always all text the user will need in his session. An other approach would be to parse such a file i.e. a XML document like this:
<?xml version="1.0"?>
<phrase>
<placeholder></placeholder>
<value></value>
</phrase>
where every field has it's own name/value that represents a textsnippet or button or whatever on the website, and then cast it into an object an cache it for everyone. I think the second approach is the best for working with multiple languages for a webapp. Anybody perhaps some pointers what I could do even better, or just post how you did this kind of languagetemplating for mutlinational webpages/webapps in the past.
Since you are looking for a translation solution, I understand you don't use a framework to develop your site, since most of them provide you with solutions to handle translations.
Most frameworks and apps I've seen in php use arrays, where the original sentence is the key and the translation is the value. So, to make easier to translate it to several languages, the key is in english.
In case you use gettext as suggested, or another aproach, it'll be useful also to parse your code to catch all strings to be translated automatically, since it can be a mess doing it manually when the base code grows and you want to keep up to date your translations.
Take a look at GNU Gettext, its very handy for multilanguage support.
The main idea is that you just wrap your words or phrases into a function, like
echo _g('Hello');
so you do not have any engine changes. You will have to add translation files for each language you are using.
You've come up with 2 solutions for storing the data, but I suggest you need to think further about the architecture and take a more complete view of the lifecycle of each request.
Regarding architecture: neither solution scales up to describe an extensive vocabulary very well - although for one or 2 pages it will suffice. The alternative approach, to manage a translation database (such as gettext) which might be overkill - and performs less optimally with small numbers of pages but importantly performance does not deteriorate significantly with large/multiple dictionaries. A compromise solution might be to have a dataset for each URL/language (which might be extracted from a consolidated database).
If it were me, I would not use either method you proposed for storing the data: parsing XML creates a sginficant overhead for each page request : using \n as a delimiter precludes the use of \n within a translation. Using a serialized PHP array seems to be the least expensive solution.
I'm working on php, mysql on a project
I'm planning to add a multilanguage option, usually I use single textfile for each php file, but I want to know if one of the followings is good or not and why.
Using one single textfile for the whole site: This would make my life peacefully because I have to make changes in one place only, but I don't know how scalable this option would be.
Using xml files for each php, is this scalable for dictionaries?
Using one single xml file, is this scalable for dictionaries?
Using a table in the db, I used this options a few times, but I read that it make the webpage slower and is not really scalable
That are my options, if any have a better one I would be greatfully, and if anyone have an advice on the pseudocode (I usually use a big array) and a replacement Welcome too :D
use gettext
wordpress is a good example if you need one
as for your question, separate language files is the only solution, letting many people work on different languages separately
I only use db when I need other people to add / modify datas in my translation.
Else I use a php file by language, defining my variables in each.
I am coding a forum system using PHP.
I am currently storing a threads ID, title, author, views and other attributes in an SQL database and then storing the thread body (the HTML and BBcode) in text files inside a folder named after the thread ID.
In practise it's really simple to grab the database values then just grab the thread body from the text file, but I was wondering if this is the 'proper way'? I have personally no problems doing this but if it turns out it is massively inefficient and I should instead store both the thread body HTML and BBcode in the database instead then I will change.
However, to me it seems wrong to store such a (very possibly) huge string of multi-line text along with lots of different characters in a database - I was taught that databases are more for short field 'values' rather than website content.
I would just like a definitive answer to this because it's been bugging me for ages as to wherever I’ve been doing it properly.
Does anyone know how popular forum systems store threads?
Added
Thanks for the answers, so it's best to store thread content in the database, what field type should i use?
Also what about replies? Another table which has the thread ID and comment ID then the comment body?
I'm new to this database stuff so thanks for your help.
Confluence (a commercial wiki) stores the entire page content within a single column.
The reason to store large text in the database is:
There's (hopefully) no disconnect between the value and the record(s) the text is associated with
There are technologies like Full Text Search (FTS) to make finding specific strings in large amounts of text
Simplified backup & restore process
It would be best practice to store the thread in the database since that will allow you to scale and search easier.
If you want to continue using files to store the content, I would recommend using something along the lines of GridFS. Basically just chunks up files and stores them in NOSQL.
I know that DotNetNuke and the AspDotNetStorefront use a database to store such data. These aren't forums, but a content management system and a shopping cart with content management capabilities.
I've also experimented with several forums (Such as YAF) and all of those use databases as well. Personally, I'd stick with a DB for the HTML, and any image/content files should be stored on the disk with a reference to their location in HTML.
Perhaps the strongest argument for storing in the DB: It's a heck of a lot easier to search the text fields with a LIKE clause than to search for a strong in a text file.
Also, with free forum software cout there, can I ask why you're writing a new one from scratch? I realize there are probably good reasons, but just in case it's something you hadn't thought of yet...
Added
Most of my references were .NET code. Here's an open source forum written in PHP: http://www.phorum.org/
This is an aside as the question has already been accepted, however you should check out phpbb3 (http://www.phpbb.com/). Very robust php forum. May save you some development time :D
I agree with the other answers, storing all the data in your database simplify scaling, backup/restore, allows you to query the data and so on.
If you're concerned with performance, you could implement a cache for the page content. I know PHPBB does this by having a serialized array in a text file with a expiration timestamp. Could also be done using memcached or otherwise.
Storing the data in a database give you the most flexibility and convenience, most problems related to serving the data to the end-user can be handled by caching the data.
I'm developing a website that will be available in different languages. It is a LAMP (Linux, Apache, MySQL, PHP) setup, and it makes use of Smarty, mostly for the template engine.
The way we currently translate is by a self-written smarty plugin, which will recognize certain tags in the HTML files, and will find the corresponding tag in an earlier defined language file.
The HTML could look as follows:
<p>Hi, welcome to $#gamedesc;!</p>
And the language file could look like this:
gamedesc:Poing 2009$;
welcome:this is another tag$;
Which would then output
<p>Hi, welcome to Poing 2009!</p>
This system is very basic, but it is pretty hard to control, if I f.e. would like to keep track of what has been translated so far, or give certain users the rights to translate only certain tags.
I've been looking at some alternative ways to approach this, by either replacing the text-file with XML files which could store some extra meta-data, or by perhaps storing all the texts in the database, and retrieving it there.
My question is, what would be the best way to make this system both maintainable and perform well with high user-traffic? Are there perhaps any (lightweight) plugins I could take a look at?
You could give a shot at gettext. It is the way it is done in most C/C++ linux applications and it is an extension to PHP too. The idea is not very different from what you're already doing, but there are tools that ease the mantainance of translations (i.e. poedit).
For user rights to translations, gettext won't be of much help, I think you'll need to do it on your own or look at some frameworks if they have smarter solutions.
Maybe taking a look to gettext lib could help you get some hints http://php.net/manual/en/book.gettext.php hope it helps!
You will need to have a table in your database that you can use to store strings of text, each with an composite ID. the composite ID will be made up of language ID and text node ID.
You will need to give the user a chance to select a preferred language. You should make sure that you either have a default "this has not been translated" for every language you use, or a default language that your entire site can be vied in.
For every bit of text with in your web site, rather then store the text with in the page, you just assign it an ID.
When serving the page, look up the text node ID and preferred language ID and load that string of text, or the string for the default.
in our project, http://pkp.sfu.ca/ojs, we use XML files to store translation key-value pairs. Browse our code: http://github.com/pkp/pkp-lib/blob/master/classes/i18n/PKPLocale.inc.php
We use that class to read the XML files for each locale and in our code we use Locale::translate('locale.key.name');. Similar to gettext, but using an XML file for easier updating.
Looking around at web stuff today I came across this website: http://translateth.is/
It looks simple to use... copy paste in some javascript.
As an exercise in web design and development, I am building my website from the ground up, using PHP, MySQL, JavaScript and no frameworks. So far, I've been following a model-view-controller design. However, there is one hurdle that I am quickly approaching that I'm not sure how I'm going to solve, but I'm sure it's been addressed before with varying degrees of success.
On my website, I'm going to have a resume and an "about me" bio section. These probably won't be changing very often.
For my resume, I think that XML that can be rendered into HTML (or any other format) is the best option, and in that case, I could even build a "resume manager" using PHP that can edit the underlying XML. A resume also seems like it could be built on top of MySQL, as well, and generated into XML or HTML or whatever output format I choose.
However, I'm not sure how to store my about me/bio. My initial idea was a plain text document that can be read it, parsed, and the line breaks converted to paragraphs. However, I'm not sold on that being the best idea. My other idea was using MySQL, but I think that might be overkill for a single page. What I do know, however
What techniques have you used when storing text for a page that will not change very often? How did they work out for you - what problems or successes did you have?
Like McWafflestix said, use HTML, if you want to output HTML. Simplest case within PHP:
<?php
create_header_stuff();
include('static_about.html');
create_footer_stuff();
?>
and in static_about.html something like
<div id="about">
...
</div>
Cheers,
Just use a static page, if the information won't change very often. Just using static HTML gives you more control over the display format.
Generally treating infrequently changing information the same as frequently changing information works well if you add one other component: caching.
Whatever solution you decide on for the back end, store the output in a cache and then check to see if the data has changed. Version numbers or modified dates work well here. If it hasn't changed, just give the cached data. If it has changed then you rebuild the content, cache it and display.
As far as structure goes, I tend to use text blobs in a database if there is any risk that there will be more dynamic databases. XML is a great protocol for communicating between services and as an intermediate step, but I tend to use a database under all my projects because eventually I end up using it for other things anyway.