I'm trying to create CMS with MEAN stack. And I have a conceptional problem on very first fundamentals.
What is the best way to store page tree structure(parent pages and child pages) in MongoDB? I've read docs: https://docs.mongodb.org/manual/tutorial/model-tree-structures-with-parent-references/ but that way force me to search the DB recursively(so I need to forget about async). Is it the best way? Maybe I need to store pages ID in one of configuration files? Or maybe MongoDB isn't good for that kind of app?
Related
I am building a personal work/career portfolio web app project, and plan on using MongoDB for my database. (I plan to build the project using MERN stack.) Most of my data is not one-time data (such as education, and work experiences), however I have a few pieces of data (such as my personal summary (the content for my "About Me" section), and skills summary) that are one-time only data (I think "single instance" might be a better fitting term). I would like to store all of the data in a database, and set up an admin-end to manage and edit the data. However, I am not sure how to go about storing the one-time data in my MongoDB database.
One idea I had was to create a collection solely for the one-time data, and only allow the user (me) to update and read the documents in the collection. Another idea I had was placing all of my portfolio data into a single collection called "entries", and giving each "entry" a type (such as "Education", or "Personal Summary"). Then when I retrieve the data from the collection I would gather all the documents with the same value in their type field together. I was thinking of storing each of the types as a constant on my server. However, my biggest concern with both ideas is if they would be considered bad practice of not.
I would be very appreciative if anyone has any advice on how to solve this problem.
I had implemented this a while back on one of my small projects, and again after discussing it over with some professionals I'm in contact with, they said that the best approach would be to create a collection with a single document that contains all the information, like the links, about, etc...
One more thing I, was suggested is that we could use Redis solely for the purpose of storing this type of information as well.
Something that I implemented a long time back similar to the one collection, single doc approach: https://github.com/codelancedevs/Sundar-Clinic/tree/local-backend/src/api/app
Working on a similar approach here: https://github.com/kunalkeshan/Cam-O-Genics-Backend
Hope this is of some help, I'm still learning as to what might be the best approach. Open to any suggestions out there!
I'd like to build a semi-automated site where pages would be created based on information on the database.
The site would be a vocabulary-like site where there will be thousands of words with their associated meaning, phonetics, and sentence examples along with other useful information.
Since a CMS like WordPress wouldn't work in that sense, what is the best solution for a system like this?
thanks,
I'm working on an e-commerce website using the MERN stack, I'm about to start retrieving data from the db so I came with this question:
what is the best way to deal with dbs? do I have to keep fetching data each time the user switches from a category to another or just do it once and use it everywhere ?
I tried both but I would like to know others opinions.
I would say it depends on how you implement your e-commerce application.
If you are creating multiple pages of categories then on each page you would do a request. If its a single page application then you would need to get all of your information so that you can display it all when the user goes to that page. If that single page application has a really long page with lots of documents, then you could implement something like pagination or infinite scroll where you would call for more documents as needed.
It's really about how you set up your application. You most likely will make new calls when going to new pages, or one call on a single page with few documents. CRUD - create, read, update, destroy, will all need their own routes as well, which you will obviously call when needed. Although, those don't always have to be implemented on the frontend if you plan to maintain your application from the backend then you can of course tap into MongoDB through the shell.
I am working on a Web Project similar to Google-Video.
As for now, I want to start coding the site.
I know some PHP, HTML and MySQL.
I already have:
Database built and ready (in MySQL)
Links and Tags in the Database
The thing is, I don't want to code everything from hand.
As I've seen so far, with CMS it's not possible to use my own database. Or am I wrong?
And what Framework would you suggest me?
Looking forward for your advice!
Thanks
You should probably start over, but use your existing DB design as your logical schema to be implemented in the CMS you eventually choose.
Go to http://cmsmatrix.org/ and compare Drupal, Joomla!, eZ Publish and TYPO3 for the best fit for your requirements.
Also, pay attention to the search engine features available with each one. e.g. eZ Publish eZ Find is based on Lucene.
In terms of functionality ( but excluding add management and your specific layout or graphic-design) you should be able to create a reasonable clone within a few hours using eZ. Here is one example http://untoldstories.eu/ezinfo/about
I am in the process of building a website content management system for one of my clients. It's a highly customized system, so I cannot use any "of the shelve" solution.
I need to allow my client to add pages to the website on the fly. I have two options here:
(1) Create a database driven page in the format of www.mycompany.com/page.aspx?catID=5&pageID=3 (query the database with the category and page ID's, grab the data and show it on the page) - or -
(2) Allow the management system to create static pages, something like www.mycompany.com/company/aboutus.aspx and www.mycompany.com/company/company_history.aspx , etc.
I believe that, while the former is much easier to implement, the latter is a better both for the user AND for Google.
My questions are (finally): (1) Would you agree that the latter is a better solution, and (2) What is the best way to implement such a solution? Should I create and update each file using the FileSystem (i.e. - the site's management system requires the user to supply a page/file name, page title and content, and creates the page on the fly based on these parameters)? Is there a better way?
Thank you!
It's entirely possible to have database driven pages with nice URLs. StackOverflow itself is a great example - this question's URL is http://stackoverflow.com/questions/1119274/adding-pages-on-the-fly-with-a-cms-system, but the page is built from the database, not static HTML.
I would use the first solution, but mask the addresses using a custom request handler. Basically, give each of your pages a unique string ID (such as about-us) and then, with your request handler that takes all requests, find this particular page in the database and render it.
See this article for some additional info (found it when googling for custom http handlers in ASP.NET.) In that article, it has the following handler added:
<add verb="*" path="*.piechart" type="PieChartHandler"/>
You would probably want to catch all paths (*), excluding certain media paths used for CSS, images and JavaScript.
More resources:
Custom HTTP Handler
HttpHandler in ASP.Net
I'd stay clear of static pages if I where you. Dynamic Data, MVC and some good planning should take you a long way!
What you need to do is to create some or many templates that each view/controller in mvc can use. Let whoever is responsible for the content handle it through dynamic data entities.
I would use the first idea, but work out a better URL scheme. If the system doesn't provide nice URLs (without ?), you'll have trouble getting the search engines to parse the whole site. Also using numbers instead of words make it hard on users to pass around URLs.
If you start to have performance problems you could add caching that would generate static pages from time to time. I would avoid doing that until you have to; caching can cause many headaches along the way to getting it right.
Although the existing advice is more-or-less sound, the commentators have failed to consider one factor which, admittedly, you haven't given much detail on. Are these pages that they'll edit once they're built, or a they one-shot creations? If the latter, your plan of generating static pages isn't quite so bad as they suggest. Why bother even having to think about database schemas and caching, when you can just serve flat content.
It will probably make for pretty lifeless, end-of-the-road pages, but if that's what you want ...