I'm working on a biology web based application and trying to figure out what language to use. The features I need to include are:
Image viewing frame - This area will display the current image that the biologists wish to see. The application needs to take in a number of coordinates from a file and draw those points on the image displayed here. When the biologist wishes to change images there needs to be no flickering from the refresh. Will do this using multiple image buffers probably. Content needs to be scrollable and able to be zoomed in.
There need to be labeled buttons that advance, step back, zoom, and play the images displaying in the image frame. There also needs to be some type of list view where images titles can be selected to be displayed.
There will be a bunch of folders of images on the server that can be selected from. The application must allow the user to select which folder of images to be loaded. It also must be able to read from either an txt or xml file and visually display the information there by way of line graph.
Would like to be able to run scripts on the server from the application.
I feel that all these things are doable by a web application but I have no idea what language to use. Most people recommend php, but i don't want to delve deeper until I know what its limitations are. Any suggestions are welcome. Thanks in advance.
-Mike
PHP can do everything you need for the back end, but most of the stuff that you describe is UI based, and this is dependent on the client, which is, of course, the browser. For highly graphical projects, you can do a lot in JavaScript and some JavaScript libraries have a lot of these capabilities built in. You might also consider Flash or Flex.
You might even consider a desktop application that runs outside of the browser. You can use Java, which is easy to deploy, but still requires the user to have the Java Runtime Engine, or you could go with a language that you can compile down to a native application.
Regardless of the front end technology that you choose, you'll still need a back end, and PHP can handle this.
You will find almost every server side platforms such as php , asp.net, asp, etc will do all of the above.
PHP is a language that resides on the server and handles all requests. Javascript (and associated libraries) is a language which is executed by the client's browser and handles (almost) all interaction. PHP is definitely able to do what you want, but for the interaction stuff (particularly the zoom, scrolling, etc.), you'll also need to use Javascript.
So, short answer, PHP is good, but you're going to need to use client-side scripting as well.
PHP is more than capable of doing this. You are going to need to use it in combination with some Javascript to handle the client side effects you describe. I would look into modifying galerific for your needs and then whip up some javascript to write points over the images.
From your concerns about image refresh/flicker, it really sounds like a desktop app is what you are looking for, for a rapid response on image changes. The requirements on this really seem to need to be defined better before you can choose a language... PHP can do all the server side stuff you mentioned, but you might have a harder time getting the image viewing "frame" to provide the functionality you want.
Due to the image manipulation requirements it might be easier to go with something like flash with a php backend or asp.net with silverlight. It might be difficult to prevent flicker and delays with using pure javascript as opposed to flash/silverlight.
Image viewing frame
This will most likely need to be done on the client side using tools/frameworks such as jQuery, the canvas element, silverlight, or any of the other 100's that are out there.
There need to be labeled buttons that advance, step back, zoom, and play the images displaying in the image frame. There also needs to be some type of list view where images titles can be selected to be displayed.
PHP or any other server-side scripting language could pull this off. If this is meant to be a quick project running on free/cheap hardware then PHP would be a good choice. If the plan is a large application that will have to be maintained over the course of many years and hosting/price is not an issue then I would suggest something like ASP.NET
There will be a bunch of folders of images on the server that can be selected from. The application must allow the user to select which folder of images to be loaded. It also must be able to read from either an txt or xml file and visually display the information there by way of line graph.
Again any server side language could do the folder listing portion. As for reading files and creating graphs, this would most likely be a combination of server side and client side programming. jQuery for example, has plugins that could quite easily take a xml file and create a line graph.
Would like to be able to run scripts on the server from the application.
PHP, ASP.NET - both could do this. I'm sure many others could, but these are the ones i use most often
The issue with PHP is that quite often, the code turns into a mess over time. This is maybe not so much an issue with the language as the people using it and the purpose the app was built for (a quick, one time project). Classic ASP also has the same issues.
ASP.NET is a good combination of OOP programming that allows you to separate presentation from logic with minimal effort.
Related
I am writing a social website which using Server-side render,
for example , user received the rendered post (HTML) from the server when user created a post,
and append the HTML to the Dom.
--
Now here comes the problem,
when I choose to render everything at the server,
where should I render "small things"?
For example, if I want to generate a photo preview before user upload a photo,
should I create a tag at the cilent side,
then modify it with JavaScript,
or just request the preview from the server to make y website "fully" server side render?
If I choose the former solution, my website will become hard to manage (Because it's like cilent-side render plus server-side render , which makes me hard to manage the templates)
I perfer the latter solution so I can manage all of my templates at the server,
but it depends on the internet speed, and I cant do anything once the user is offline,
What should I do?
Well, would say that your question about where to render "small things" will be responded with a vague answer. It may seem like an innocuous question, but the answer will be responded by more complex questions! IMO, it is far better to ask this question, than to apply a server-is-better myopic view to everything.
In general, I view each rendering task through some constraints all of which can vary dramatically by user!!:
- origin of content (is the information coming from the client?)
- delivering content (network infrastructure)
- viewing content (client hardware)
So, let's try to answer something specific:
For example, if I want to generate a photo preview before user upload a photo,
should I create a tag at the cilent side, then modify it with JavaScript,
or just request the preview from the server to make y website "fully" server side render?
Is the photo is coming from the server?
Yes: have server render preview
No: have the client render it
After reading the first view paragraphs of this Twitter ariticle, I came to the conclusion that their content would be best rendered on the server. But further reading, showed that they are hybridizing their rendering - some client and some server (complex - just like you said!).
But, that conclusion was made 8 MONTHS after they had 100 million users! So, be pragmatic and choose the rendering approach that will enable you to build the application with the least complexity.
After few months I decided to stick with Cilent-side render with Vue.js (and I have to rewrite everything, yay),
The reasons are:
Easier to manage the templates, pages.
Great for storing the data for offline usage (Because CSR get data only, not the whole page).
Separate the render work, so I can spend less money on my server.
Because everything will always outputted to the browser.
I am just stuck a little in making a choice between PHP chart Lib and JavaScript Chart Lib. I do understand that PHP if for the server side and Javascript for the client side. My problem is what difference does it make when using their charting libraries. Is it performance issue or what?
I want to understand the difference in using PHP chart Libs and JavaScript Chart Libs. Please am not looking for examples of their chart libraries. I am looking for why i should choose one over the other.
I tried to google 'php chart vs javascript chart' but didn't get any links that can give me
the difference.
EDIT 1
1)
If this question has been answered before, then point me there.
2)
Am developing the application for internet
EDIT 2
1)
I have found out about PHPChart PHPChart which has both PHP source code and JavaScript source code. If anyone has experience in that library, does it may be solve the problem of server side load (bandwidth issues) etc.. I am thinking since it has both the PHP and JavaScript source then it may be the best to use. Am just assuming. :-)
Thank you very much
Both ways of creating graphs have their own pros and cons.
If you decide to do it using PHP, first you need to make sure that you have all the required graphical libraries installed (e.g. GD, which might not always available on shared hosts).
Assuming you have them, the first negative thing in my opinion is that you will end up with static images. Of course, it's not always a bad thing, as that ensures compatibility with all the clients, be those with or without javascript support, however, it takes away the dynamics of graphs generated on the client side using javascript. Your users won't be able to zoom, move, slide, full screen or do anything that they could with the likes of Highcharts or Flot.
Another con is that images take up more bandwidth than, say, JSON. The bigger you want to have your graph, the more colors it contains, the longer your clients will have to wait till your page loads. And just because those loads are not asynchronous, they will have to wait for the images to load before they will see the rest of the page.
With javscript libraries everything is different though. You only request the data required for your graph and you only request it when your page loads. The amount of data is usually smaller than an image would be plus you can compress your output with GZ to make it even smaller. Users will see nice spinners informing them that the graph is loading instead of some incomplete webpage.
Another thing to take into account is - what if you decide to show a nice table with data in them below each graph? If you chose to render images on the server, you would end up having to add new functionality just to get the data. With JSON, however, you just make one call, render the graph and display the table. Maybe calculate totals or do whatever you want with it. Hand it out to people as an API if you wish, after all :)
If you ask me, I would definitely go with client-side graphs as most of the devices have nice HTML5 support nowadays and being able to display a graph on an Android phone, or an iPhone or an iPad shouldn't pose a problem. If you only need images and you don't wish to expose the original data, go with PHP.
My opinion is that having a server side solution (i.e. php) takes away any browser compatibility issues you may have with a client side solution (i.e. javascript) and hence support issues.
A benfit of using JS is that it does offload resources from your server to the client because you may only have to generate some light weight data (e.g. JSON , XML) and the rendering occurs on the client. You will have to investigate how many hits your server is likely to get, etc to determine if resource is an isuse with PHP or JS.
However, using Php to create images of charts you can always get around the performance/resource issue by using a cache of the image files and serving from the cache (it's a just a folder of images) instead of generating a new one. Whether you cna use a cache will depend on your usage. If clients require up to the second data and its always changing, obviously a cache may not be of use.
Here's what I see :
Using PHP
Increase load on the server for the request
Will work everywhere
Also, like someone said here and made me think of it, you can cache the image that PHP give you, reducing bandwith (no lib to download) and reducing load (cache)
Using Javascript
Decrease load but increase the bandwitch and addition http request (to load the JS lib)
Will work where JS is available
But remember, PHP take more load then an HTTP request.
Also, always remember, Javascript is made for effects and specials stuffs you need to display.
There is one PHP render advantage that no one told about. Since sometime you need to include chart as image into PDF, DOC, XLS etc. file or email it – you have no other way except to render chart on server and store it as image to be inserted.
For data manipulation you use PHP.
For visual and behavioral effects you use JavaScript.
For that reason, you should use Javascript as its designed for visual behavior. Plus it will put less load on your server as all processing will be client side. As more people use your application simultaneously, it will start to slow down as your server will be doing a lot more then it has to.
Hope that helps :)
I'm thinking about setting up a website (based on WordPress) to host video tutorials on interpreting CT scans.
In addition to simply letting the visitor view PowerPoint presentation videos, I'm keen on writing some sort of simple app that I can embed in the blog to allow the visitor to scroll through a series of images (i.e. a scan).
I usually code in REALbasic or Objective-C. I have some experience with PHP. What are my language options for making an interactive embeddable image viewer in a blog? The website needs to be able to be viewed on an iPad as well as normal desktop browsers.
Javascript.
Pick up jQuery, or a similar Javascript framework. It will help you get down to business faster.
What you are asking has nothing to do with server-side coding. It is all client-side. Because of that, your choices are something to do with a plugin (such as Flash), or Javascript. If you want it to work on an iPad, Flash and other plugins are out.
Since you need your image viewer to work on the iPad, ActionScript3, hence, Flash is out of the picture. I would use JavaScript as per the examples on the Apple HTML5 advocacy site, using the canvas element to render the viewer.
I would lean towards a javascript solution. There are loads of libraries out there that will give you a kickstart. If you know some example works of what you are thinking about doing, we can give you pros and cons for serverside vs. client side languages. Additionally, you can use html5 for a lot, but then again it depends on what exactly you are wanting to do.
I need some opinions on using PHP to make completely "scalable" websites.. For instance, using viewport resolution and resizing images, applying dynamic css styles..... In my mind doing this just add's to the complexity and should not be done, it should be fixed or fluid using strictly css and no server-side languages to generate layouts based on the device size..
I need some input and maybe some philosophy on why using this approach is not used at all..
Manipulating a web page in this way is the domain of CSS controlled by Javascript (or a library such as JQuery, see CSS docs). You shouldn't be wasting your server's processor cycles when client-side implementations will be far more responsive for the user and allow all the flexibility you require. Changing font size etc can be done almost instantly in the browser without the user having to request another page from your (remote) server, which would result in a slower user experience.
Really, really DON'T
As Andy says it is the domain of CSS.
Trying to adapt a design with PHP will make your code unmaintainable. You should really learn to use CSS efficiently to avoid this kind of hack.
The only reason for which you could use PHP to detect browser and adapt content is mobile browser.
Given the number of the existing User Agent tokens, it'll be almost impossible to make y scalable websites.
I was wondering if it's possible to create an image of a div inside a page in php, jquery or javascript? Or even just a screenshot of the entire page (on my own server - not external)..
What I want to do is create an image of a graph (drawn in via jQuery) and pass it onto a PDF, as I can't seem to get the jQuery to display in the pdf..
Because of the security risks, it is not possible to get Javascript to make a screenshot of a web page. This would allow you to steal credit card info, etc... You can use an active X control or something like that, but the client has to knowingly install it in order for things to work.
In PHP, you can create an image and place it on a web page, but again, you cannot see what is on the client's screen. It has to be done on the server before it is sent to the client.
Here is an example of a library you can use to draw a graph in PHP. http://www.aditus.nu/jpgraph/
You might be able to mimic what jQuery is doing in your script but it will take a shift in your applications design.
Take a look at this article:
http://www.developerfusion.com/code/181/capture-screenshot/
It's not client-side code, but you mentioned PHP so maybe server-side code is an option. I don't think you can do it client-side...
How about using a server side graph generator, for example for PHP? Maybe the transition hurts but you'd get a really stable and simple solution.
If you describe what kind of charts you exactly generate and what server side options you have, I'm sure you'll get some specific hints.
Your best bet is to use the GD library on the server to generate the graph as needed. There's no practical way to screencap the browser canvas. Check out this PHP graphing library, it may be what you're looking for:
http://graphpite.sourceforge.net/
If you run into problems where you're doing processing on the client-side that don't exist on the server (i.e.: summing up rows or taking in user settings from cookies), maybe you need to consider passing that data back to the server and letting your hosting handle it (after all, that's why you run a server with lots of RAM and a big CPU, to crunch numbers).
If your javascript draws the graph on a canvas, you can serialize the canvas and then send it to the server using POST.
I don't know if jquery can draw the graph on a canvas, but if the graph is a simple one you could probably code it yourself as canvas has drawing tools already.
Obviously, this only works with browsers supporting canvas.