calculate number of working days on a rails form - javascript

I have two fields, 'from_date' and 'to_date' on my rails form. When a user enters the dates I have to display the number of working days i.e, exclude (sat, sun and a list of other official holidays in a database table).
Is this something that should be done in the client side javascript
Or is this something that should be done by making an ajax request to rails.
Can you tell me how I can accomplish this.
thanks much.

Depending on how often that feature would be used I'd opt for doing both, create a .js-file (or generate dynamically and just make sure rails caches it) and try it with javascript locally for instant gratification. Then make sure it's correct on the server side on saving.
The upside with doing it both on the client and on the server is that you may save some hassle when the guy can see it directly on the site without doing a request. But if they have javascript disabled it'll still work. And if it's anything important you should never trust what you get from a web form. :)

This patch might give you some ideas. https://rails.lighthouseapp.com/projects/8994/tickets/2304-add-concept-of-weekdays

You might be interested in business_time.

Related

architecture for get and store api request data

This is more of a architectural questions. An external platform had product and price information for let's say, books. There is an API available to get this information.
What I read is that it should be possible to create a function in Javascript and connect the Javascript to a page where you want to show the data on my own website. This would mean that for each page request an API-call is made. Since the requested information only changes once a day maximum this does not sound the most efficient solution.
Can someone advise a better solution? Something into the direction of a similar php or javascript function that does the request on the background, schedule an update and import the data into mysql? If so, what language would be most common.
I need the solution for a Joomla/php/mysql environment
Here's a simple idea - fetch and store results from the API (ones you think aren't gonna change in a day), either on disk, or in the database, and later use these stored results to retrieve what you otherwise would've fetched from the API.
Since storing anything in frontend JS across page reloads isn't easy, you need to make use of PHP for that. Based on what's given, you seem to have two ways of calling the API:
via the frontend JS (no-go)
via your PHP backend (good-to-go)
Now, you need to make sure your results are synced every (say) 24 hours.
Add a snippet to your PHP code that contains a variable $lastUpdated (or something similar), and assign it the "static" value of the current time (NOT using time()). Now, add a couple of statements to update the stored results if the current time is at least 24 hours greater than $lastUpdated, followed by updating $lastUpdated to current time.
This should give you what you need with one API call per day.
PS: I'm not an expert in PHP, but you can surely figure out the datetime stuff.
It sounds like you need a cache, and you're not the first person to run into that problem - so you probably don't need to reinvent the wheel and build your own.
Look into something like Redis. There's an article on it available here as well: https://www.compose.com/articles/api-caching-with-redis-and-nodejs/

SQL Data & JavaScript - Best Practice

Let's say a website needs to pull information from a specific table in a database based on a user's menu selection. That table's data is then fed into some JS equations and thrown onto the page.
What is the best way to go about pulling that table's information? I've read that trying to access an SQL database via JavaScript is bad practice, so is there another way to do this? I know about PHP's json_encode, but I guess I'm not entirely sure
What the syntax is if I'm calling PHP from a JS script, and
If that's 'best' practice. Still relatively new to this, so I'd like to do this right.
Another option as far as I'm concerned is attempting to pull ALL of the possible tables (not a security concern) at once on page load. I expect that'd introduce a good deal of latency, though.
It looks to me that you are not really sure what technique to use. Here are some options. I'm not going to type them here because, there is enough to find about each one:
plain php: w3schools
pure ajax call: stackoverflow
jquery: jquery
Ajax calls are more user friendly and many times more efficient because, you don't have to refresh the page. I usually get all information at once( as long your mysql data is not to big). As for security: You use php either way so it doesn't matter if you use Ajax or not. Oh and don't select valuable data of users data (like password or their emails). I hope you get more overview after this :)

What are some ways to make it harder for the client to manipulate the DOM?

I am going to be processing a lot of form data from the client using Ajax. Right now, my way of validating input is to add a 'validate' class to each form control that needs to be checked. When the user enters information (or submits the form) the script looks at the input of each control with that class and verifies its contents before moving to the next tab (or sending it to the server). The issue, of course, is that a user can easily remove the class and the item wouldn't be looked at.
While I will of course be validating the input on the server-side (client data can never be trusted!), a lot of the user-side content generation [new inputs, dynamic forms, removing/adding validate classes, etc.] depends on people not tinkering with the classes. While I know that the client can ultimately do whatever they want, what are some ways to make this process difficult for the client to manipulate?
So far I have thought about:
Running a script at the beginning of the page load that grabs all the HTML inputs with the 'validate' class and stores them in a variable. When the user submits the data or moves to the next tab, instead of looking at the elements with the class 'validate', I instead look to validate the data compared to the contents of the variable.
Adding data-validate HTML attributes to each input and doing the same thing as above (running a script and grabbing the inputs that need validation before the client has time to tinker with the settings)
Is there anything else that can be done? I am a little hesitant to use the above approaches because there may be new, dynamically generated form elements that need to be added/removed to the list; and this + grabbing the data at the beginning of the page load could cause a little unnecessary overhead.
"While I know that the client can ultimately do whatever they want..."
You just answered your question. If that's your starting point, why are you trying to make it harder? Is it worth my while to actually try to hack your site? If it is, I don't care that it's harder. Also, how hard can it be? Are you going to make it so hard to figure out the JavaScript that the next developer who looks at this code also won't be able to figure out what's going on?
Also, you're adding more code. Have you ever written code without bugs? I haven't. So, guaranteed, there are going to be bugs in this thing. So, in the off chance that 1 in a million users might try doing something bad, you'll end up stopping lots of legitimate users who get errors when they're using the site like they should.
Client side checking is ONLY meant to be nice to the end user, to give them immediate feedback. Period.
Might not be the answer you like, but it is the answer. :)
Edit: One last comment. Let's say you did make it REALLY hard. Would you then not do server side checking? Would you say to your boss, "Oh, we made it pretty hard to hack on the client side. They still can. We just made it hard. So no need to do server side checks." Of course not. So, if you're doing server side checks no matter what, you don't gain anything from trying to obfuscate on the client side.

Get the PC date from an app in JavaScript?

After trying many googlings I can not find any thing related to this problem. What I wanted is getting my PC's date not the Google's server date.
I did try by using URLFetchApp to make a HTTP request with a hope that some JavaScript can be executed and then I can have a nice PC's date as the response but it was not so simple. I do not really have no idea how to make some progress right now so may you can give some hints?
Sure. You're going to need this:
(1) Set up a URI on the app side to retrieve the data
(2) use a tiny bit of javascript in your client side to capture Date, and translate it to JSON.
(3) Send that JSON to the URI.
This will be a lot easier if you can make the client initiate it, say at the time your page loads, but it can be done by having the server side request it.
Details of how to handle this depend somewhat on what Javascript library etc you use. I like jQuery, which would make the second step something like jQuery.toJSON(new Date()).

Best practice for handling errors in forms submitted via ajax?

I'm wondering what is considered best practice for dealing with forms submitted via ajax. Specifically, I'm wondering what is the best way to handle a form which contains errors.
I see two possible options upon submitting a form with errors:
A. The server returns a JSON document of name value pairs of fields names / error messages. This would then need to be processed client-side and the form would need to be altered by prefixing each field with it's error message and changing the form's styling (adding an error class to the fields for example).
OR
B. The server simply returns a new HTML fragment containing the form with error messages and styles pre-applied. No need to process anything client-side except swap-out the form.
To me option B seems like the easier/quicker option but I can't help but feel that it isn't 'best practice'. Is there pros/cons for either method?
Separation of logic is a huge one here I reckon.
As a project grows, you generally have a front-end team and a back-end team. Imagine the website gets a huge makeover but the logic stays the same. Option B is harder to change the style when the layout is enforced server side.
The application logic (which is this case is server side validation) should be separate from the presentation layer (which is this case is the html/css rendered by the browser).
But at the end of the day, we get paid to produce results so if your not trying to win an academy award for best quality code, and you got bills to pay, just get it done the quickest way.
I'd go with the first option.
The second option just increases the load on the server ... which you always want to avoid. Plus, I feel that if the styling was done on the server-end, the your website isn't exactly modular ... all styling should be done on the front end only.
This is sort of an opinion question but there are a few objective things to say about the topic. Your first option, the pure JSON choice is best used for apps that focus on speed an keeping HTTP requests as small as possible.
The other option, to process your form server-side then return the new form through AJAX doesn't seem to have too many advantages to me. If you're going that route then why bother with AJAX at all? Why not just do a regular form post to the server?
I usually prefer a front end validation and server-side verification. This way you can avoid a JSON call at all if things aren't valid but just in case someone sneaks something in there the server-side code will verify.
I would establish a JSON scheme for validation on the front end. Just basic stuff like what you're checking for on each field, which fields are optional, etc... That gets baked into every page with a form on it. Then let your front end devs pre-validate to avoid unnecessary calls in whatever way makes the most sense to them.
Pre-built errors isn't against any best practice I'm aware of and it's not a terrible way to go (people tend to throw the UI manual of style out the window when it comes to forms anyway), but sometimes you'll want to give more specifics or different errors for different problems.
Always aim for having your cake and eating it too, IMO.

Categories