I'm going to be implementing a lightweight formatting language (probably Textile, maybe Markdown) in a project I'm working on, and I'm wonder how best to store it in the database.
If the user is able to edit the content they're posting, it makes sense to me that the original, non-converted markup be stored so that the user doesn't have to edit HTML the next time around. But since the content is going to be displayed a whole lot more than edited, it also makes sense to store a converted copy of the content so that the original doesn't have to be sent through Textile on every page view.
So, is the common practice to store both the original and converted content side-by-side in the database? Is there a better way?
Thanks!
Store markdown:
Every view = conversion
Every edit = no processing
Store html
Every view = no processing
Every edit = convert to markdown and back
Store both
Every view = no processing
Every edit = convert to html after edit
You have to weigh up your processing costs vs. your storage cost.
You should definetly store original Textile/Markdown markup and use either standard HTTP caching stuff (Last-modified, Expires-At, ETag) to cache rendered pages or just cache the result of processing markup.
I'm currently using Markdown with PHP. I store the markdown-source in the database, and I display the Converted Version upon request. I have no performance issues, and am very happy with this setup.
What I've seen is indeed to store the compiled HTML in a seperate row in the database. Just have one row 'content' and another 'content_html', and save the compiled HTML in the 'content_html' row.
(Surely you have some kind of save method that you can override to do this?)
Related
I am using a Markdown package inside my Laravel 4 application to store user input from textareas into my DB.
https://github.com/vtalbot/markdown
This works perfectly using:
Markdown::string('#test');
However, when I edit a record and set the value of a textarea to the existing data in the DB (the data that was formatted for entry), elements such as P tags are shown, which isn't ideal.
Does anyone know of a way to "reverse" markdown for this? Maybe I should be approaching this differently?
Thanks.
You don't reverse it. You store the unparsed version in the database and parse it when you display it to the user. And if you want to save on some overhead when parsing then you can cache it in some form. Either via an actual cache, like redis or memcached, or you store it in an additional field in the database and update the parsed version whenever it is updated.
I am new to jquery and JSON and i am bit confused as what is best and professional approach.
Suppose i have the long list of data like song name , artist , author etc.
Now i dynamically want to dislay records from database.
I have two options
Here i return the full html and update that with the target element
Second is to retrive the JSON data full of songs info and then build that html with javascript and populate it.
I want to know which approach is better and used by high traffic sites
Second is better because of data size being sent over the network. Reducing it will improve the performance.
Write a function that will use JSON data to generate HTML elements.
If you're running a high traffic site with lots of data then the second solution, using JSON does have the advantage of only giving you the raw data and relying on the browser to generate the HTML to display the data.
Personally I would need to hear some really convincing arguments for using the first option at all.
In an attempt to redesign a website, I put this page together by hand. However, there are currently over 100 more shows already that need to be added, and three new shows get added every year.
In the old system, a text document was used as a makeshift 'database'; it stored data about each show, with shows separated by '#' and data fields separated with ']'. Here's an excerpt:
#The Whorl of the Leaves]WhorlOfTheLeaves]3]F]167
#Aladdin]Aladdin]8]N]0
#A Christmas Carol]XmasCarol84-]7]N]0
#The Feral Child]FeralChild]7]N]118
#Camelot]Camelot]11]N]169
A PHP script was then used to extract the information about each show and make the page seen here.
I'm sure a script could be used to put together a page such as the one shown above, but it seems like there should be a better system than a text document to store the information.
My question is: if the text document 'database' is working, should I bother changing it? Is there a better way to organize the information about each show?
SQLite would be prefect for you. It's a tiny database that requires no configuration or setup - yet comes built into most PHP installs.
Just use PDO and your good.
$db = new PDO('sqlite:/path/to/here/mydb.sq3');
$db->query('SELECT * FROM shows');
Yep, there are a ton of "better" ways of doing this. But if you're happy with it and it works, why change it?
You could save yourself a lot of trouble by using a content management system such as drupal.
Problem:
I don't know the simplest way to allow a single web viewer to update data in a text file on a server. (ie. only 1 person will be changing the data.)
Objective:
To make a prototype web application just one person needs to input in the start and end dates of new assignments and locations of staff and the whole company can visualize the information on a GANTT chart, probably using this Jquery libary.
Constraints:
My data is about the equivalent size of 1000 of these javascript list of lists like
*data = [["John Smith" , "assigment" , "1/1/10", "1/1/11", "Peru"],[...],...]*
Employee assignment data must be on an internal server.
I can't use a database (such as SQlite or MySQL).
I can only use PHP, Javascript, and jQuery.
Fact: Javascript cant directly change a data file sitting on the server.
My tentative fuzzy solution:
On client-side: use jQuery getJSON() to pass the data back and forth between dataReadWriter.php.
On server-side: dataReadWriter.php modifies a PHP array as well as writes modified data and reads JSONdata.txt stored in a text file on our internal server.
Given the constraints, it can't be done a lot smarter than what you are suggesting. One thing though, you shouldn't overwrite the only file containing the data, at least switch back and forth between two files, and make sure that your program does not overwrite the other file if one of the files show any signs of being damaged. You can use a PHP session to keep track of which file is the most recent, but better have some in-file timestamps as a fallback.
Is there anything in particular that you worry about?
I'm creating my own blog in PHP and want to know your opinions on how I should format my post content.
Currently I store the post content as just plain text, call it when necessary, then wrap each line with P tags. I did this in case I wanted to change the way I formatted my text in the future and it would save me the dilema of having to remove all P tags from the posts in the DB.
Now the problem I have this this method is that if I want to add extra formatting in, e.g. lists etc those would also be wrapped with P tags which is not correct.
How would you do this, would you store text as plain text in the DB, or would you add the HTML formatting and store that in the DB to?
I'd prefer not to store unnessary HTML in the DB, but not sure of a way around it?
I think the best way would be to keep the html in the db. You would have too much to work with parsing the text if you don't use html.
See how it's done in other blog tools. I know that Joomla, for example, keeps all html in the db. I know Joomla isn't blog tool :) but still...
Wordpress stores html in the db. You say you are concerned about storing 'unnecessary' html in the db. What makes it unnecessary? I think it is the opposite. You may have headings or bold or italic text in your post. If storing as plain text, how do you save this formatting? How are you saving the lists you mentioned?
I see it as a better practice to store raw user input in the database, and format it on output, caching the result if it is needed. That way you can change the way you are parsing things easily without having to regex-replace anything inside the database. You can also store the raw input in one column, and the formatted HTML in another one.
I assume that you are formatting your raw text with the Markdown or the Textile syntax?
If you store HTML in your DB, you will be just a few clicks away from your current situation:
you can use strip_tags() to remove HTML formating and in case of bigger changes, you can run HTML Tidy on your code to remap tags and classes.