Image Editing on Web Application [closed] - javascript

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
On my website users have some images stored. I want to build a system where they can edit those images on website and save them. Edits are very basic like rotate, crop, enhance brightness add filters etc. I'm trying to figure out how I can implement this.
My understanding so far is that there are multiple ways in which I can do this. I can write all my image editing code(using libraries) on server side and then call this service API from my website.
I can also make all the changes on client side. I found PicMonkey library which would let me do it (it's flash based though so I don't really want to use it.)
I also checked how flickr does it, they use this library https://developers.aviary.com/ which lets them do all the client side edits.
I'd like to know more about using these client side javascript libraries ( such as aviary ) what are the pros and cons of using them vs server side edits. What service component I need to write, if at all if I'm using something like Avairy. More specifically, do I send image to server for modification or do I modify it on HTML canvas first and then send the modified image to server to save it.

Today browsers have become very strong, so you should probably do the basic edits on the client side itself, so there is not too much burden on your server and also utilize the processing power of the client.
You have few libraries for doing this on the client side
1) https://developers.aviary.com/
2) http://camanjs.com/
3) http://www.pixastic.com/editor-test/
but as you say,
Edits are very basic like rotate, crop, enhance brightness add
filters etc
You can create your own code for these kind of edits, there are lot of tutorials out there, few I found useful are here,
http://www.html5canvastutorials.com/advanced/html5-canvas-grayscale-image-colors-tutorial/
http://www.williammalone.com/articles/create-html5-canvas-javascript-drawing-app/
there are few things which if you try to do on the client side they will crash your app completely, for ex. a photo bucket tool.
Here is a tutorial as well for creating a photo bucket tool which uses a flood fill algorithm.
http://www.williammalone.com/articles/html5-canvas-javascript-paint-bucket-tool/
But you should keep these kind of heavy algorithms on your server so your app doesn't crash.

If you are good in server side programming my spontaneuos thought was "Why not using the raw PHP GD library or the PHP add-on imagemagick?"
http://www.imagemagick.org/
Photo editing in php
It depends on what server load you are expecting - up to 10 people simultaneously working on it would be OK, but 100 to 1000 people at once? For the second case a client side editing is really the better option, or your server will overload. Naeem-Shaikh gave you some links for that.

I recommed to make it client side.
JavaScript will give you everything you need for basic editing and you ll be able to organize your code in a clean way.
A client side app won t force you to deal with XHR, wait, send, http, all of those you have to master for the same server side app to always display the current draft. Server side you will need servers with available ressources to do the job.
User will be able to continue editing even if they lost connection, and trust me this alone should be enough of a pro to do it client side. Also the editing will feel more fluid.
So why would even hesitate ? Well, server side also has advantages.
There are many (10+) librairies tested, documented, enhanced ready to be used. Perhaps you don t have time or energy to learn JavaScript. Maybe in the future, you ll want to expand your app with new, heavy, editing features that takes more CPU than client have, ...

Related

Choosing "unavailable" pickup point in online shop [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 months ago.
Improve this question
just discovered one bug in a "n" online shop. The bug is the possibility to change html code (thanks to inspect element) and make an early unavailable pickup point available. As consequence, I was able to order some stuff, pay, and even get confirmation of my order. My question is, how an owner can prevent something like this?
P.s. During ordering, I was only on the one web page, there was no redirecting to another page or refreshing the current, until payment.
P.s.s. just want to mention, that I'm a total newbie in these "magic" things. So probably you can recommend me books/webpages etc. where I can read more about "server responses".
As you found out, editing the HTML code of a site and/or modifying the data sent to or from your browser is indeed not too difficult. That's part of how a browser is designed and intended to work, so you'll have to deal with this kind of "hacking" on the server side.
Here's a very superficial (and not complete) list of things to keep in mind when setting up your server and backend application:
Every request from outside ("the client") is potentially malicious or tampered with. → Make sure you use server-side validation for "everything". This may refer to:
Input fields (length, value, format, ...)
Data formats (e. g. correct JSON/XML structure)
User authentication and authorization
Your business rules (this is, as I think, the one decisive in your example - probably everything else was valid, but the server side did not check for the availability of that pickup point you injected)
Thus, do never rely on client-side validation (typically JavaScript / TypeScript) only! You can use this for a better user experience, but the real "hard" validation must take place on the server side.
Depending on the criticality of your site and the confidence of the data associated, think about adding more security by using a Web Application Firewall (WAF), rate limiting, log crawling and other techniques to identify and block suspicious traffic.
Keep your server software (the operating system with all its libraries etc., the application server (like Apache / Nginx / WildFly / ...) and the software your site comprises of (like a Spring / PHP / Angular / ... application)) up to date. There are means and methods like Dependabot helping you to automatize this process. Outdated software and libraries might have some known bugs an attacker can exploit.
Try to use standard software, frameworks and mechanisms wherever possible. Modern Web Frameworks like Spring Boot, Laravel, ... are well-maintained and security issues are found and fixed early. Also, the have validation and fraud detection methods built-in already, you'll just have to make use of them. On the other hand, if you try to code your own authorization framework (for example), you'll most likely overlook something and leave a security gap.

What language should I use to build a small Costing App? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Am trying to build a Small Cost Calculation and Quotation App. Since Its not so big App, I was planning to use plain Javascript rather than using frameworks like Angular JS because i am not much familiar with it. Am I doing it right.
This will precisely have following :
Front End (User Side)
User Input Interface where the User will Input the values in the required field. This will require to load different modules based on the kind of costing thats being calculated.
Quotation which will constantly update based on User Inputs and will have the options to Print, Save and Email the Quotation.
I would also need the ability to save the Quotation which can be edited anytime later on.
Admin Panel
To Set Preferences (with Preferences I mean the rates / Unit and other details. I do not know if 'preferences' is the proper term to use)
Backend
The Backend will comprise of Cost Calculation Based on the User Inputs and the Preferences Set. How do I do that.
For eg I select a component that requires 10kg of "A" Product where as the Rate / Kg should already be set using Admin Panel
Apart from that, The Costing Calculation workout should also be displayed on request if the admin is logged in.
Database
I prefer mysql as thats wot I am familiar with.
Would I really find help if I host the project on github. Why would someone help me code.
Is there anything like coding online without installing framework like WAMP.
Can anyone advise me if what I am doing is right or not .
Let's start by seeing the big picture. The basic architecture is like this:
Client -> Server -> Database
Frontend -> Backend -> Repository
Javascript -> ? -> MySql
And let's see what you know and are comfortable with - Javascript and MySql. To avoid learning a new language/framework, you should be quite OK with the above technologies.
You just have a missing piece ie. scritping at the server or backend. Php is a good free choice. However if you know other server side languages like Java, those will be fine too. If you can list the languages you know then more specific help can come. Have a look at Node.js since you are already familiar with javascript.
You don't need to host in github. There are many hosting servers available which makes it very easy to run php/mysql if you proceed with that.
You have asked lots of questions. i will try to answer them briefly
1) Yes you can use Angular JS for the costing app. You can also use plain Javascript / JQuery too.
2) I dont understand this preferences thing properly but if your first question and this is taken into account then i guess using php as a scripting language will solve many of these things (for example 'saving the quotations for future use etc)
3) The admin panel thing and display of the particular app after login can be totally done with any scripting languages for example PHP or anything else of your choice.
4) A database like mysql can be used, its good, pretty standard. I dont think you can 'host' a database driven website on Github. You can make a repo of the files there though.
5) Lastly you can code online without using WAMP, XAMPP etc. There are lots of cloud ide-s. For example Cloud9, Nitrous, Codeanywhere. Check those out.
If you find my answer as helpful check the tick beside my answer. Thanks.
Instead of considering the size you should consider its importance and should decide its impact in market..
Instead of using simple JavaScript you should probably go for AngularJs since its a framework..and frameworks since they have their own methods of implementation and their own designs they are likely to be used as they keep your code clean and handle most of the things themselves so you do not really waste your time writing unnecessary code..
I would recommend you to go for
Angular-for frontend
Spring-for backend
MySql-for database
Try to use frameworks as they will surely help you building low cost app

Server side programming vs Client side programming [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I'm trying to understand this concept better. Is the whole point of server side programming is to allow us to communicate with others? Whether it is to get new ideas or to get data that can't be stored locally on the client because it would be way too much information?
There are several typical software architectures:
Non-networked application (does not communicate, client-only)
Server-client application (has typically one or more central servers, and multiple clients that contact the server(s))
Peer-to-peer application (only has clients that communicate with each other).
Here, client is typically the part of the application that is executing on the user's computer, which the user is interacting with. Server is defined as the part of the application that user is not interacting directly, and is not on his computer but somewhere else. This separation can be for any of a number of reasons: data size, data security, data availability, or simply coordination.
For example, when you go to Google on your web browser, the web browser is a client. Google is the server. Your computer does not know where everything on the Web is; but Google has a pretty good idea.
For another example, if you play MMORPGs like World of Warcraft, your game is the client, and Blizzard's computers are the server; you tell the server what you are doing, and the server tells you the results, just like a pen-and-paper gamemaster. Without the server, you couldn't know what everyone else is doing.
Or, if you want to consult the atomic clock at the U.S. Naval Observatory, again, you are the client, the clock is the server; you contact it because, obviously, you don't know the correct time, and it does.
Now, for example, you might say that server might not be needed in some cases. For example, in the MMORPG case, couldn't the players contact each other directly? The first problem is discoverability: how would they find each other on the Internet? There has to be some central location to tell everyone everyone else's address. But if that is all the server did, you would have to contact all of the online players (and there are a lot of them) to ask them where they are, and if they are on the same map ask them the same question very very often; your internet connection would not be able to do it. There is also security to consider: a server makes sure (or should make sure) that you are not teleporting around on the map by changing the game's code and telling other player bogus values. For example, if client was responsible for remembering how much gold a player has, it would be trivial to become very rich very quickly: just lie about it to others.
When you go to a website on the internet, your browser is the interpreter that reads HTML/CSS/JavaScript. To read these, your browser must first download the code, then interpret it, then display it to you. Since your web-browser downloads the code, it is really easy for you to see it. (as seen below).
This is great for small projects like blogs, informational websites, project-pages, etc. But say you worked really hard on a big project, and you don't want people to see your code. In client-side programming, the webbrowser reads code, and displays it. If you right click and save a static (HTML, CSS, JavaScript only) website, you'll be able to view it even if you shut off your internet. In server side programming, your web-browser can't read the code because the code will not be the usual HTML/CSS/JavaScript. Since your web-browser can't read the code, it looks to the server (which is a giant computer in a data center far, far away). The server does everything for the web browser, and just returns results. The web browser has the results, but doesn't know how the server processed them, so it displays the results, but doesn't display the code behind it.
This is great because for one, all your code logic is happening privately, which is essential for security and privacy. And, it's happening really fast. Since the server is some huge computer that is much much faster than yours, all your logic for your website is processed really quickly. Also, you get to communicate with databases, and store data, whereas in client-side programming, everything is happening on your machine and your machine only. Basically your code gets the ability to remember.
In essence, you would use client-side programming for information, styling, and small projects. Client-side is usually referred to as front-end development because it's what the user see's (the front). Back-end development (server-side) is the background logic, and is everything that happens behind the scenes, which the user doesn't, and shouldn't see. If you were making some big website, and you had user accounts in it, you can't just store their user/pass in a javascript variable because a) everyone would be able to see the code, and thus, the user info and b) their user/pass would be gone as soon as they closed the page. Server-side communication opens a bunch of more doors for us.

Somebody help me to answer me why do we use script in asp.net? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
when i use asp.net to coding for website. Asp.net in server call sql server (ado.net, linq or entities framework) and get back data, send for clientside. i use some control as girdview to show data. actually, i do web optimization ( sql server - store procedure, create index, partition => faster, acceleration for get data. Website: UI simple, do not use too many effects)
but why in client-side, when server return data for client, many people always are going to use script (such as javascript, jquery, node js, angular js, bootstrap, react, google o/i....) to show in webpage.
so, it slower or faster when we use girdview?
And when User (people in clientsite) stop scrip in browser, it's mean, Manufacturers allow user or offer to stop script on browser in clientside., so why do we user them ( *.js), when User can stop script?
Even many people use asp.net (new version - 2013) in server, they also use script in there. so asp.net + script in server is faster or slow when we only use asp.net?
please, help me answer.
(I'm apologize because my English is not good.)
Thank you so much.
In the early years of Web development, Javascript on the client side provided for considerable enhancement of the client's "user experience" that static HTML delivered from the server did not. This includes such things as the enabling or disabling of certain interface features based on user input, the appearance or hiding of certain regions of a display based on user input, or combination of other pieces of data.
As web development evolved, the need for even more robust client-side interaction with back-end web servers became evident, and the "frameworks" you mentioned all work in various ways to improve the design, responsiveness, and behavior of a web-based application in ways beyond just enabling or disabling a button. This amounts to complex data binding, callbacks to web services, reducing server round-trips, and creating rich client interfaces, to name only a few.
They're all tools, each with their own role, each working to make web applications a bit more robust than those of the generation before them.
If I understand your question right, the answer comes down to speed and preference.
Firstly, if you disable client-side javascript, your asp.net controls aren't going to really work anyway. You'll find few places that still disable this so it's not really a concern people have anymore.
Secondly, it comes down to where you want to focus development effort and what kind of developers you have. If you have a lot of people used to working backend (C#) and want to stay there, then using asp.net controls and the like make development easier.
If you have javascript developers or people who want to use it, then you have more options that allow you to more decouple your server-side code from your front-end code. This can work out well for maintenance purposes.
The real point is that if you can utilize ajax (http://www.w3schools.com/ajax/default.asp) within your web application, you can make it a lot more responsive. ASP.NET Controls can often cause your page to refresh and cause unnecessary server-side computing to get the data and re-render the entire page (or partial page with asp.net mvc). Using new technologies like angular and others you listed, you can focus data computation and network traffic only on what's important.
For example, if you need a table to change what data is loaded, you can make an ajax request JUST for the data you need to load and then just render that portion on the client.
First of all, every "script" you mentioned (jQuery, AngularJS, Bootstrap, React) is a library written in JavaScript. Except node, which isn't even front-end. And I'm not sure what did you mean by google o/i... JavaScript is currently the only language which works in all browsers.
Initial purpose of JavaScript was to check form values before sending data to servers. It quickly evolved past that, although the usage was throttled by browser adoption, which is still a problem today.
Nowadays we can use JavaScript to render whole webpages. First when opening the page, it can help with rendering, meaning that server doesn't have to do all the work, but can just send plain data, usually in JSON. It's also used to add content to page later, without reloading the page (AJAX). Most well-known examples are real-time chat systems, like the one on facebook. This greatly improves user experience, I can't imagine how terrible it would be if whole page would reload to display a single new message.
Although user can disable JavaScript in their browsers and this would mean the page probably won't work, except if there is fallback design for such cases, I do not know why would someone disable it. And to be honest, probably most of the regular users don't even know this can be done and where is the setting to disable JavaScript.

Transmitting a huge amount of data from a Web server to the client [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm starting a new project that will render a complex graph using HTML5 canvas.
Currently, we have a Windows Forms implementation and we want to migrate it to the Web. So, the layout, the drawing objects and all drawing metadata are generated in C#. We only need to implement the drawing, and we will use HTML5 canvas.
The server side will be ASP MVC. It will calculate the drawing model, and will send it to the client. Then the client will use the canvas to represent the data.
The problem is that the drawing model sometimes could be huge. Maybe 10Mb-50Mb of metadata. What is the best way to send all drawing data from the server to the client?
Use the model to an script in the page that creates the drawing objects in JavaScript
This would be the standard way. I will generate a model with the drawing objects in C# and then I will convert those objects to JavaScript.
PROS: Easy to implement
CONS: The page will be heavy.
Returning a JsonResult from controller that return the drawing data
I could get it using jQuery, for example. This option failed because I reached the maxJsonLength property. I know that it can be changed in the web.config but it doen't seem to be a good idea. 3.
PROS: Easy to implement, could use ajax to load drawing objects from the server and report progress to the user.
CONS: Doesn't seem to be a good idea changing the maxJsonLength property in the Web.config.
Generating a temp script file with the drawing data in server and including it in the client page
The server will generate the drawing data in a JS script file. Then the server will include this page as a JavaScript in the client page, so the drawing data will be loaded in the client. This load could be done using ajax also.
PROS: Is like download a file, if it's very big it will not be a problem.
CONS: More difficult to implement. Need to manage temp files and we need to know when the file has been transmitted and then delete it.
Other alternative
Any other options will be welcome, since I'm not an expert in HTML programming.
I think somewhat different approach I will take. I will use servicestack, here I am assuming that you have your business tire separated. Now, instead of canvas I ll go with backbone js or angular js. There are quite a few other frameworks for UI generation. Now, using require js like library I push only that details that are needed for UI generation or push HTML with UI that is needed for UI. So, here speed will be more and page will be light weight. Once minified Javascript come to client it will not load but used only to calculate and render html portion on page. And single page application will be as fast as desktop. Almost that much. I hope this is useful to you. I have added links if you need more details please let me know.
Put the heavy part (script and data on a sub-page) in an iframe on a lightweight page so that the heavy stuff can be loaded asynchronously. This has the ease-of-implementation benefits of the first script-on-page option, while gaining the pros (and none of the temp file management cons) of the third load-as-separate-script-file option.
While the iframe is loading, you can display a loading image so that the user knows what's going on.

Categories