I've got a Rails app hosted online, where the standard content has CRUD operations enabled, and multiple editors can create, edit and delete the content using controls in the views. This is working well.
There's also an About page, which contains content that mostly won't change. This is hard-coded in a view, and any changes require me to edit the view, then push the changes to the live site.
I'd like to allow the editors to edit this content online, without requiring my involvement.
Presumably the About page's content will need to be stored in the database, but it doesn't seem logical to enable the full CRUD operations on it. Eg, there will only be 1 About page, and it shouldn't be possible to delete it.
What is the preferred Rails approach for allowing the About page's mostly-static content to be editable online?
If all you want is to avoid allowing editors to delete your page, you can just avoid not putting the delete action (delete, destroy) inside your views and controllers. However, you will need to enable the create, read and update actions (CRU) , as that really is the only way to update the site remotely, short of giving them access to your app directly and having them upload it directly on to your hosting server (not recommended).
I'm assuming you already have a functioning login/authentication system, so you would simply need to just extend that functionality to the about page, by requiring the editors to login and authenticate themselves, before being allowed to perform CRUD (without the delete, D) functions.
Note that even if you were to get rid of the delete function, they could delete the about page accidentally or on purpose by simply performing an update that has nothing inside of it. You should just to be safe be saving your webpages to some sort of version control software (i.e.: Git), so that even in an event where your information gets lost, a previous backup can be used to restore your website to a previous state.
Related
Context/Background: I have an iOS app with a Firebase backend. Each user on the app has a couple of public stories or journals. I am working on the v2 of the app and one of the main features of v2 is to give users the ability to publish their stories as static webpages by a click of a button. The goal is to have a journal for a user with a username "johnhouse", for example, be available at www.the-app-domain.com/johnhouse.
Question: How do can I create web pages on the fly from an iOS app? Im not sure where to start. Which online services should I look at?
I thought of spinning up a server and hosting www.the-app-domain.com on it, getting the app to ssh into the server and creating a directory called "johnhouse" (from the example above) inside the website's root directory and then pasting an index.html file inside it, But this doesn't only sound like a bad idea, it also sounds complicated as hell If I were to generate the html files on the app, how would I get them to the server? how would I get them into the right location?
There are a great many ways you might implement this behavior but I'll suggest one.
Consider what this product might look like if the app had no knowledge of how these static pages were published. All the app needs to be able to do is allow users to set which of their stories are published or not and to inform those users of the url at which their published stories will be available.
There may be real advantages to removing the app from your page-creation process.
If you find that you need to make change to the formatting of your pages you can do so without requiring an app update and you can choose if you want to rebuild every page or just have changes apply to new pages. This might be important if you discover that your pages don't render well on some devices or are not indexed the way you would like by search engines.
If you need to change where your pages are hosted you can do so (and provide redirects from the old location) without needing everyone to update to a new app version.
If you need to add moderation or curation of the content you publish you can do so more easily than if clients (your app) have direct control of your site content. This may be important when someone starts publishing SEO spam links to your site, or registers the username admin or login, or publishes a story containing malicious javascript, or publishes content which gets you a copyright infringement notice.
You don't need to give clients direct access to your web server which could allow them to edit each other's content or overwrite your site with their own malicious content.
Since you're already using Firebase take a look at how you might run your own web server as another client of this backend. One which looks for "published" stories (however you identify those in your data model) and generates appropriate pages for them. Depending on the tools you elect to use these could be dynamically generated pages (client side js or a web app) or static pages build by some backend process periodically or whenever stories change and added to a web server. Without any idea what server side tools would be most appropriate for you it's hard to know what specifically to suggest here.
I'm working on ASP.NET MVC project with C#.
Ok so I have a layout view where I put my partial view which contains just a div that displays notification messages.
Now from some view I have a button that generate a report in 5 minutes in async manner. While the report being generated I need to allow the user to use other areas of the website.
My action method, once the report is generated successfully, simply returns a string "Success", o/w "Fail".
What I want to do is assign that returned string to the div of the partial view which is on the layout page. So this way the user can see the notification from wherever he is within the website.
How can I do this? Thanks.
There's a number of different things going on here. First, you want the server to update the user with the "success" or "fail" status. This requires 1) using web sockets to create a persistent connection between the client and server, allowing the server to talk to the client without requiring the client to first send a request, or 2) long-polling, which is means the client continuously sending requests at a defined interval to see if the server has any updates.
Long-polling (with AJAX) was the only way to achieve this before the advent of web sockets, which are relatively new, and not universally supported. In particular, IIS8+ is required on the server side, and client side, you need a modern browser, which is really any except IE 9 and below. If you can't run the site on IIS8+ or you need to support legacy versions of IE, then you're stuck with long-polling.
However, with either approach, you're tied to a single page. If the user navigates away, web socket connections are closed and long-polling stops. If the user is still on your site, the next page would need to re-establish all this functionality to keep it working. That's not really difficult - just something to be aware of. It just means that you'll need some universal script running on page load across your site for this.
Now as far as replacing the content of your "partial view" goes. You shouldn't look at it that way. I encourage you to read my post: There's no such thing as a "partial view" client-side, where I get into more detail. The TL;DR version is that all of this updating of the client is happening client-side, and at that point, all you have is the browser DOM. There's no concept of a "partial view". If you want to replace a part of the DOM, you must select it and manipulate it. That's all done with JavaScript and it's all on you. There's no easy "replace this partial view" button.
I have an application that has different data sets depending on which company the user has currently selected (dropdown box on sidebar currently used to set a session variable).
My client has expressed a desire to have the ability to work on multiple different data sets from a single browser simultaneously. Hence, sessions no longer cut it.
Googling seems to imply get or post data along with every request is the way, which was my first guess. Is there a better/easier/rails way to achieve this?
You have a few options here, but as you point out, the session system won't work for you since it is global across all instances of the same browser.
The standard approach is to add something to the URL that identifies the context in which to execute. This could be as simple as a prefix like /companyx/users instead of /users where you're fetching the company slug and using that as a scope. Generally you do this by having a controller base class that does this work for you, then inherit from that for all other controllers that will be affected the same way.
Another approach is to move the company identifying component from the URL to the host name. This is common amongst software-as-a-service providers because it makes sharding your application much easier. Instead of myapp.com/companyx/users you'd have companyx.myapp.com/users. This has the advantage of preserving the existing URL structure, and when you have large amounts of data, you can partition your app by customer into different databases without a lot of headache.
The answer you found with tagging all the URLs using a GET token or a POST field is not going to work very well. For one, it's messy, and secondly, a site with every link being a POST is very annoying to work with as it makes navigating with the back-button or forcing a reload troublesome. The reason it has seen use is because out of the box PHP and ASP do not have support routes, so people have had to make do.
You can create a temporary database table, or use a key-value database and store all data you need in it. The uniq key can be used as a window id. Furthermore, you have to add this window id to each link. So you can receive the corresponding data for each browser tab out of the database and store it in the session, object,...
If you have an object, lets say #data, you can store it in the database using Marshal.dump and get it back with Marshal.load.
I have a web part which shows data in one of 3 different formats. The format is selected by clicking one of 3 buttons in the web part. This works fine.
A request has come through to store the last selected state so that the user does not always have to click their favourite view.
It seemed logical to define a Property and define Personalizable(PersonalizationScope.User) but this does not seem to work for most users as they only have Read rights for the page.
What is the best way forward here? Is Sharepoint the right place to store such info or should I be using my own storage?
Thanks
Using your own storage is an option but this means its some more development work for you. How about this option.
Modify your WebPart and add the option to the Web Part property.
Create a new permission level and add the following permission
Update Personal Web Parts - Update
Web Parts to display personalized
information.
This will make sure that users with read only access can only update webparts.
Step 2 will allow them to odify all webparts. You can modify each webpart and remove the following option for webparts which you dont want you users to edit.
Allow Editing in Personal View [Advanced]
This way you can lock all webparts except the one you want.
I use a homebrewn CMS in my site. The texts in it are used by inserting an html-helper into the view:
<%=Html.CmsEntry("About.Title")%>
The entries of the CMS are stored in SQLServer. I need a way to scan all views in my project and see if all tokens are already in the database.
Is there a way to do this? I already enter an entry into the DB at runtime, when a token is not found, but I need a way to do this without visiting each page. Maybe via reflection?
One way to do this is to create a page (controller action) that scans through the files looking for "Html.CmsEntry" and parses out the page names, and then queries the database.
If you have access to the database from your dev machine, you could possible do this in a console app, and set it as a build action, so whenever you compile, it runs.
Failing that, you could try relying on a spider (GoogleBot, or otherwise) to hit all your pages, and trigger your existing logging code.
Alternatively, you could store all your page names as constants or enum values. If you used enum values, you could easily spin through them (using Enum.GetValues) and check they're in the database.
All that said, if the pages are stored in your database, can't you do away with all the static pages that call them, and generate everything dynamically from the content already in the database?