This question is not about particular database engine, it's about actual content.
For example, frontend uses some kind of WYSIWYG editor (CKEditor, for example). It's easy to store everything what user types in editor, but this can potentially break design (unclosed tag) or add security issue ( tag). Also, there can be images and we can not simply store it in the same field.
We can circumvent most design/security issues using markdown, but how to store files/images alongside with text?
Should I create another table?
posts
id
text
post_images
post_id
image_id
image_path
And inside post text have something like this
Hello, this is [image_id=22][/images/dgdgsdg.jpg] my image
Or there are other proven solutions?
All big social networks allow some kind of formatting with attached files, but how store it without headache?
We can circumvent most design/security issues using markdown
That is not true. Markdown can contain inline-HTML and you still need to validate/clean the generated HTML. Use the sanitizer-functions of your web framework.
Usually you'd just store the images on your server, the HTML (or markdown) contains the image path. You could also change the filename to a hash of the entire file. Again, usually there are plugins that handle this sort of thing for you (e.g. paperclip for Ruby on Rails).
Related
I want to organize my notes (on scientific articles).
I want to be able save text and images notes for each article
Save the pdf file
Organize it into a hierarchy with a document somewhere with a content table containing the hierarchy of thematics and link to all articles
I want to be able to move fast between articles (open note on an article fast)
Add tags to filter the articles
Add an importance level to filter articles
There is many softawre for that kind of thing but it's often difficult to combine pdf file and notes containing text and images and hierarchy and tags
And they are often not really customizable.
The best solution I can think of is to use html files to put the article contents, and other html files with links to the articles pages.
I currently use a python script that I call from command line with pdf download link and article name as argument
The script creates an empty html page for the article at the good place in the hierarchy, add link in the table of content html page, and the article link with his tags in a seperate file
What I would like to do is to have a button in my table of content html page which would allow me to add an article and so add and modify some files.
t's seems that a very specific case because I'm using web like technologies only to organize local files.
But I don't know how to do that and I don't know where to look. Could it be done with javascript or php ? Or may be use something like python dash to display the html page and run some python script in the background
Sorry for my english I'm not a native speaker
I found some app on github that did almost what I want: trilium and pervane
But I didn't use them because they were to complicated for me to customize them to add new functionalities
I finally find a solution by using flask to render my local notes that are stores as html.
I'm currently writing an HTML5 WYSIWYG using Google Closure Library and I'm providing users to just drag and drop the image file to contenteditable field with text to add an image.
So I have two ways to store these images:
1. Retrieve the data URL from dropped file, create an IMG tag, set the retrieved data URL as value of attribute SRC of this image and insert this IMG tag into editor's field. When user will submit the form I'll just save all retrieved HTML in my MySQL database and will able render his text with images later.
2. Upload the dropped image to my server and save it as regular file.
Then the server will answer like:
"image saved, its URL is http://example.com/images/uploaded-image.png".
After that I will perform the steps similar to my item 1 (create an IMG tag with attribute src="http://example.com/images/uploaded-image.png" and insert it into editable field).
The first way will load database more because it requires to store an image dataUrl in database field together with text. But it makes image adding more easy and fast, so it improves the user's experience.
The second way will load database less because the images will stored separately (in the file system), but this way requires more requests to the server and some processor time on each image adding into text within the WYSIWYG. Also it will not show an immediate result to user so the user will need to wait when his image will uploaded, what will make user's experience worse.
I need the help to understand which way is more preferable in my case considering all pros and cons.
Another way is to store not only images but complete HTML with images in one file. And use the database for storing a link to the HTML file. Then setup Nginx and get the best performance. IMHO if your application is WYSIWYG then the content should be loaded and laid out completely in the browser before editing.
i have a website which contains many news articles. IN the database, each article has so-called "tags" which the user sees displayed alongside the article. When the user clicks on the tag, they are directed to a list of other articles also containing this tag.
Should I generate a distinct HTML page for each newly created tag, or should I create one single page and vary the content based on what tag the user clicked on using session variables????
obviously, the pages will not be completely static since I will update them everytime a new article with a matching tag is uploaded
You certainly shouldn't use session data. That is for data that needs to persist, but it set on a per user basis. Using it for per-request data will just break bookmarking and introduce race conditions.
You should have a distinct URI for each tag. It doesn't matter (from an end user perspective) if you use dynamically generated content (either via a query string, or parsing the URI in your server side code (most frameworks, e.g. Dancer, will handle this for you)) or if you use generated static pages.
Static pages make it easier to handle caching and give better performance on very high traffic systems, but tend to require a rebuild of large sections of the site if content changes. You can get similar performance improvements by using server side caching (e.g. via memcached).
Dynamic pages are usually simpler to implement.
I suggest you to create a listing page that contains title and small description of all articles containing a particular tag similar to WordPress.
For example, here is listing page for the tag jQuery:
http://sarfraznawaz.wordpress.com/tag/jquery/
I would create one page, and then rewrite the url so that it referenced the tag page so something like this
Tag element == New
tagpage.aspx
http://www.yourwebsite.com/New.aspx
this allows you to have one page to update the content with but allows each page to be indexed by Google.com.
I'm not sure what language you are using but I would look up URL rewriting
here's a link for rewriting in apache:
http://httpd.apache.org/docs/2.0/misc/rewriteguide.html
here's a link for rewriting in asp.net:
http://msdn.microsoft.com/en-us/library/ms972974.aspx
How can I load local HTML contents to a WebView on UITableViewCell which can be editable too, Such as the mail body of the apple example of the MailComposer. Here we also can get copy paste and magnifier facilities. Please help me with suggestion or with sample codes. I am warned already to be fired by my company. Please please help me.
With the following assumptions:
Users do not need advanced editing features (images, bulleted lists, WYSIWYG anything).
Users do not edit HTML markup.
The HTML only includes text and basic formatting like linebreaks and indents.
I would suggest:
Maintain two versions of your HTML content, one that displays in the UIWebView and on that the user can edit. The editable one should have all markup tags stripped and, where sensible, replaced with their corresponding plaintext character(s) (so for instance, replace <br> with \n).
Load the HTML version of the content into your table as normal (I assume you are already doing this).
When you table goes into editing more, replace (or overlay) the UIWebView with an editable UITextView populated with your non-HTML version of the content.
When the user indicates they are done editing, take the edited version of the text and invert the replacements you did in step #1 (so for instance, replace every \n with <br>).
Load the modified string you got in step #4 into the UIWebView. Optionally save it to file if you want the app to remember/retain a persistent history of edits to the field.
Although, if the company you are working at thinks that the way to motivate engineers is to threaten them with termination, really you should just thank them for their inept management techniques and be on your way.
What I mean by autolinking is the process by which wiki links inlined in page content are generated into either a hyperlink to the page (if it does exist) or a create link (if the page doesn't exist).
With the parser I am using, this is a two step process - first, the page content is parsed and all of the links to wiki pages from the source markup are extracted. Then, I feed an array of the existing pages back to the parser, before the final HTML markup is generated.
What is the best way to handle this process? It seems as if I need to keep a cached list of every single page on the site, rather than having to extract the index of page titles each time. Or is it better to check each link separately to see if it exists? This might result in a lot of database lookups if the list wasn't cached. Would this still be viable for a larger wiki site with thousands of pages?
In my own wiki I check all the links (without caching), but my wiki is only used by a few people internally. You should benchmark stuff like this.
In my own wiki system my caching system is pretty simple - when the page is updated it checks links to make sure they are valid and applies the correct formatting/location for those that aren't. The cached page is saved as a HTML page in my cache root.
Pages that are marked as 'not created' during the page update are inserted into the a table of the database that holds the page and then a csv of pages that link to it.
When someone creates that page it initiates a scan to look through each linking page and re-caches the linking page with the correct link and formatting.
If you weren't interested in highlighting non-created pages however you could just have a checker to see if the page is created when you attempt to access it - and if not redirect to the creation page. Then just link to pages as normal in other articles.
I tried to do this once and it was a nightmare! My solution was a nasty loop in a SQL procedure, and I don't recommend it.
One thing that gave me trouble was deciding what link to use on a multi-word phrase. Say you had some text saying "I am using Stack Overflow" and your wiki had 3 pages called "stack", "overflow" and "stack overflow"....which part of your phrase gets linked to where? It will happen!
My idea would be to query the titles like SELECT title FROM articles and simply check if each wikilink is in that array of strings. If it is you link to the page, if not, you link to the create page.
In a personal project I made with Sinatra (link text) after I run the content through Markdown, I do a gsub to replace wiki words and other things (like [[Here is my link]] and whatnot) with proper links, on each checking if the page exists and linking to create or view depending.
It's not the best, but I didn't build this app with caching/speed in mind. It's a low resource simple wiki.
If speed was more important, you could wrap the app in something to cache it. For example, sinatra can be wrapped with the Rack caching.
Based on my experience developing Juli, which is an offline personal wiki with autolink, generating static HTML approach may fix your issue.
As you think, it takes long time to generate autolinked Wiki page. However, in generating static HTML situation, regenerating autolinked Wiki page happens only when a wikipage is newly added or deleted (in other words, it doesn't happen when updating wikipage) and the 'regenerating' can be done in background so that usually I don't matter how it take long time. User will see only the generated static HTML.