I'm refactoring an older online catalog system where the various messages sent to users - things like 'Thank you for registering with our store', 'Thank you for your order', 'Your order has shipped' - were all stored as text fields in the database.
It's worked well enough and it's nice to have the CMS subsystem be able to simply pull a db field into a browser-based editor for updates. But a browser-based editor is also a downside if I want a richer editor to handle more complex layout functions.
Should I give consideration to moving the messages to the filesystem and just store a URI in the db?
thx
It sounds like you're already considering it! :)
Well, doing that will add complexity won't it, because information will have to be looked up. You'll have to look in the database anyway to find where the file is, so what's the point. It'll probably go wonky over time, unless you're very careful, you'll end up with URI's in the database where the file is missing, or files without a URI in the database.
I'm assuming your richer editor works on files, and that's why you're considering switching to file based?
How about, when you get the record out of the db, just extract the data to temporary file then. Then edit it in the rich editor, then when you've finished and saved it, write it back to the db.
To be honest, I don't really know enough to answer this. What editor are you considering using?
Related
WebApp Stack: Nuxt.js with #nuxtjs/i18n, Express, Mongoose/MongoDB
Take into account that the webapp needs to work in offline mode so it needs to download content and translations or have them in the app-package and make packages for different langs.
Translations for general porpuses are stored in /lang/<lang_code>.json
But how should I store my translations for the content?
Options I was thinking:
Store them in the database for each /post{ title: { en-US: "Title", es-ES: "Titulo"} inside the post data.
Store them in /lang/post/category/<slug|id>.json
Make separate databases and do /api/es/post (probably not a good idea)
You can have your whole translations in a single file, per language. Of course, you can split it even further but having it static after build is totally fine and should be fine enough. And, if you are in need of an online solution, it's still the most simple and efficient one.
You can pretty much nest it as much as you can too. It depends of you need but having a 3k lines of translations is fine IMO. Just need some nice and organized structure.
i18n-ally is an excellent VScode extension that may help you a lot with your i18n workflow. :)
I'm creating an app which generates a random question from a list (currently stored as a Numbers doc). Once that question is answered by the user, the unique question ID, the question itself and their answer is stored in core data.
When the user requests a new question one will be generated randomly from the original document and it will then be cross referenced with core data to find out if the user has previous answered that question.
I haven't included the code of my app at the moment as I'm not really looking for specific coding help. As someone who is new to the world of code I'm just looking for a nudge in the right direction for me to go and do more studying.
JSON looks like a possible, but the more I read about that the more it seems that it is about an app communicating with a website. I don't really want the questions to be accessed by just anyone, so putting them on my website might not work? Could I do it with a file local in the app? maybe a CSV?
I'm anticipating the file may become quite big as I add more questions - so I'm not sure if that changes things?
Thanks so much in advance, and apologies if this isn't quite the right way to ask questions on here.
I'm just looking for a nudge in the right direction for me to go and
do more studying.
There are many options to solve your problem. Each option depends on your skill, time and if the solution is even necessary for the app you want to make. In the end it's you who decides on which solution solves your problem. There are a few options:
creating your own backend
have a local file in your app
or use a third party service like Firebase.
Each option has its own benefits. Just to list a few:
Local file:
You could have a local file in nearly any format (XML, JSON, .plist) etc. The downside is that your app isn't dynamic - you have to manually keep adding text to this file and update your app trough the App Store for your users to see these changes. If you're going with this approach, I'd recommend using a .plist or a JSON file which is saved in your project. How to implement this correctly is beyond the scope of the question, but there are plenty tutorials out there to help you getting started.
You could put your data in a .plist file. This is nothing more than a dictionary with key-value data (same principle as JSON where each key has a value). An example:
question1 is the key, of type String, containing the value "How are you today". It's easy to read from this .plist since it's the same principle as JSON.
Also, JSON is just a format, it's used often to communicate with websites, but it's not limited to sites only.
Custom backend
This means that you make a backend on which your app can communicate with. You'd have to host your backend, write logic / code on your backend and so on. This can be very time consuming, especially if your app isn't that big/demanding. I wouldn't recommend this unless you have the experience, time, patience and need for this solution.
Third party
This can be a nice solution. Using a third party service like Firebase means that you have your data online. The Firebase library has been well tested and has great documentation to get you started. It's secure, fast, simple but .. it does take a little bit of time to learn how it works - but the end result is that you have a dynamic app where you can add, delete, edit questions and so on. This data can be protected if you wish - which means only authenticated users can access this data (Nobody else will be spying on your data :))
I don't really want the questions to be accessed by just anyone, so
putting them on my website might not work?
Read custom backend and Third Party.
Could I do it with a file local in the app?
Yes. Read Local file.
maybe a CSV?
That's possible but I wouldn't recommend it, but that's a personal opinion. I find it outdated and it's more difficult to work with than JSON.
I'm anticipating the file may become quite big as I add more questions
- so I'm not sure if that changes things?
What is a big file? Nowadays reading a "big" JSON file is probably nothing more than a few MB at most. Your phone reads this in no time. This won't be an issue for your phone or app.
I've tried to google this for a couple of days and I am still pretty confused, so I thought I would try here.
I have an iPhone app that uses Core Data with an sqlite database. I am trying to implement a simple backup/restore of the database with Dropbox.
I downloaded the Dropbox SDK, and I have everything running fine as far as linking, uploading and downloading my .sqlite file.
However, I don't want users to have access to the actual .sqlite file for security purposes. I have been seeing JSON on these boards for some time now so I decided to look into it. I think it is exactly what I need.
Easier said than done. I have never worked with Java and have never implemented anything like JSON before, so I have had to try to figure out where to start.
I understand basically what is going on, but I'm having a heck of a time figuring out how to do it. I think I found a way to get the Core Data model into JSON format (and I do use the term 'think' loosely here). But then what - what exactly do I upload to dropbox? Do I somehow combine the model (in JSON format) and the database? What gets uploaded to Dropbox? I'm sorry if this seems obvious to most, it really is not obvious to me, and I have looked.
I am willing to do the work, but it just seems like I could go in 90 directions without some basic guidance and a start. I am not trying to do anything fancy as far as determining data that has been changed, etc. - just want to backup/restore the whole database. I just need some basic explanation and to be pointed in the right direction. A simple core-data sample project would be tremendous.
I'm not an experienced programmer, but I am a fast learner. Just break it down easy...
Thanks in advance.
JPK
Thanks Andrew. I didn't want to 'give away' the database structure of my app, but i can now see that the json string wouldn't be much better than the sqlite file in that area. I am a teach-myself programmer (stay at home mom) so this is all pretty new to me. Maybe I want encryption? But is that allowed for iPhone apps anyway? I recall them asking about encryption when I have uploaded binaries.... I know that iCloud is coming out soon, and I do plan to implement that as well, but with the limited amount of data that can be synced for free, I want to be able to do a simple backup as well. Many of my users have asked for it - a backup in addition to that of iTunes, which really is not a great backup since you can't restore data for just one app (you would have to restore for all apps on the iDevice). Hmmm... Any suggestions as to how to upload the file in such a way that it is not easily readable? Is encryption the way to go in this situation?
JPK,
I think you're crossing multiple streams here.
JSON is a data transfer format. IOW, it has almost nothing to do with the architecture of what you are attempting. You will almost certainly use JSON to communicate with Dropbox.
I have a question: why do you think that the user won't have access to any data you send to Dropbox? I suspect that you are probably wrong. The user will have access to everything.
You are doing to an awful lot of work. You already have the .sqlite file being persisted on Dropbox. If you are doing this to make a backup, that data is being backed up in many other venues. In other words, your task is likely moot and unworthy of your time.
I use JSON, REST networks and Core Data daily. If you have a specific question, I am happy to answer it.
Andrew
Instead of saving the whole database, save out a plist file to Dropbox that you can rebuild a database from. That's assuming you have a lot of extra stuff in your database you do not want the user to see, otherwise just back up the DB as-is if it's all user generated data.
You could also encrypt it but why? Adding encryption only means you have to answer "yes" that you use encryption and may not be able to sell to specific companies, should you choose to encrypt - it's not forbidden.
Could anyone help me? I need to insert information to the header of a pdf from a customer form online with php. I am not a programmer so I need a sense of direction before I speak to my developers.
The idea is to get licence information from a field, insert the information to the header and save the result as securely as is reasonably possible before the customised file is downloaded.
Any help would be greatly appreciated.
This will generally involve opening your existing PDF file with an appropriate PDF manipulation module (Zend_Pdf works for this purpose), performing whatever operations you need, such as inserting data into the document, and then outputting the document to the user with the appropriate headers (content type and disposition) set.
If you want customers to be able to download files several times, it would be wise to have the licensing information be gathered from the user account information, rather than a form.
First of all, asking for information on a particular library or tool to use is off bounds for StackOverflow (as it draws mostly opinionated answers. But even more importantly, in my experience, going to your developers and telling them which library to use while you don't know anything about it and are not a developer, is not generally a good idea. Focus on what you want to accomplish; don't worry too much about what technically is needed for them to do what you want. That's their job.
Looking at your question, there's a couple of things you might think about and discuss with them:
1) Taking information and adding it on top of an existing PDF file, is not the end of the world from a technical point of view. There are probably 100 or more different tools and libraries that can accomplish this in many different ways.
2) Much more technically challenging and worthy of a discussion with them is "save the result as securely as is reasonably possible before the customised file is downloaded". Normally, when you add information to a PDF document, it's not trivial to change it afterwards. But it's far from impossible. And if it's only a matter of removing stuff, it's even easier. A tool such as Adobe Acrobat for example will happily let you remove a bunch of text / graphics from a PDF file. If you want to prevent that, you have to at least protect your PDF document; set a number of flags in it that prevent it from being edited for example.
That's still not going to be waterproof, as these flags are supposed to be honoured by PDF processing applications. Adobe Acrobat does that and so do most other "decent" PDF applications, but it's certainly possible to circumvent this if you want it hard enough.
So, from your product management point of view, think about what reasonably secure means and have a discussion about that with your developers. That's probably going to get you much further than suggesting a particular library they're going to resent instantly because it comes from a non-developer :)
We have a web application which contains a bunch of content that the system operator can change (e.g. news and events). Occasionally we publish new versions of the software. The software is being tagged and stored in subversion. However, I'm a bit torn on how to best version control the content that may be changed independently. What are some mechanisms that people use to make sure that content is stored and versioned in a way that the site can be recreated or at the very least version controlled?
When you identify two set of files which have their own life cycle (software files on one side, "news and events" on the other, you know that:
you can not versionned them together at the same time
you should not put the same label
You need to save the "news and event" files separatly (either in the VCS or in a DB like Ian Jacobs suggests, or in a CMS - Content Management system), and find a way to link the tow together (an id, a timestamp, a meta-label, ...)
Do not forget you are not only talking about two different set of files in term of life cycle, but also about different set of files in term of their very natures:
Consider the terminology introduced in this SO question "Is asset management a superset of source control" by S.Lott
software files: Infrastructure information, that is "representing the processing of the enterprise information asset". Your code is part of that asset and is managed by a VCS (Version Control System), as part of the Configuration management discipline.
"news and events": Enterprise Information, that is data (not processing); this is often split between Content Managers and Relational Databases.
So not everything should end up in Subversion.
Keep everything in the DB, and give every transaction to the DB a timestamp. that way you can keep standard DB backups and load the site content at whatever date you want if the worst happens.
I suppose part of the answer depends on what CMS you're using, and how your web app is designed, but in general, I'd regard data such as news items or events as "content". In other words, it's not part of your application - it's the data which your application processes.
Of course, there will be versioning issues between your CMS code and your application code. You could manage this by defining the interface between the two. Personally, I'd publish the data to the web app as XML, which gives you the possibility of using XML schema to define exactly what the CMS is required to produce, and what the web app should expect to process.
This ought to mean that most changes in the web app can be made without a corresponding alteration in the rendering of the data. When functionality changes require this, you can create a new version of the schema and continue to make progress. In this scenario, I'd check the schema in with the web app code, but YMMV.
It isn't easy, and it gets more complicated again if you need additional data fields in your CMS. Expect to plan for a fairly complex release process (also depending on how complex your Dev-Test-Acceptance-Production scenario is.)
If you aren't using a CMS, then you should consider it. (Of course, if the operation is very small, it may still fall into the category where doing it by hand is acceptable.) Simply putting raw data into a versioning system doesn't solve the problem - you need to be able to control the format in which your data is published to the web app. Almost certainly this format should be something intended for consumption by software, and therefore not usually suitable for hand-editing by the kind of people who write news items or events.