I would like to have an upload control on an intranet website, which needs to support multiple file upload. Drag and drop is not required, I just want to select a lot of files (in hundreds, possibly) for processing on the server. After the uploads are complete the user will be redirected to another page where he'll be able to process the results.
I'd also like to support other browsers, but IE is the most important as most of the customers use it as per their IT policy and it cannot be changed. Their computers are restricted enough and Silverlight might be the way as it's official Microsoft plugin, compared with Flash.
I would like to have a form with a “Browse” button which allows the user to pick files, then the file names are added to a list and “Upload” button that starts the upload to a server side code that saves the file somewhere and redirects the user to the next page.
I think that I should use Silverlight for IE7/8/9 and HTML5 for Firefox, Safari, Chrome and Opera (and IE10, eventually). That would mean coding two separate (html5+silverlight) front-ends and one common back-end on the server.
I know that Telerik has something exactly like this and works, but it's too expensive as I need only one control of their library.
Is there something open-source that works this way? Or is there a better and simpler way to support IE and HTML5 file-compliant browsers?
Silverlight will work in all the browsers, so that's the way to go (right now). After IE 10 comes out, then HTML-5 might be a better choice.
flash is the solution, as flash 7 was shipped by default in windows xp.
but in the end something's got to give, it professionals will have to say no to corporations that have operating systems older than 10 years.
Look at this jquery plugin http://blueimp.github.com/jQuery-File-Upload/
I know this post is a bit older, but have you looked at pulpload or even uploadify? Both provide HTML5 and Flash versions.
Pulpload is somewhat more versatile, it seems, but I have implemented uploadify a few times, and the docs are ... good enough (I think version 3 of uploadify is much better, but I don't have experience implementing it, yet).
Related
I'm trying to create a map viewer for an existing C# WinForms application. I've installed and hooked up the GreatMaps (GMap.net) controls no problem and that's all working fine. The quirk in this is that it needs to work offline (as it's an application that gets used by users who aren't always in locations where there's a mobile signal).
The offline cache mode works fine for GMap but, we've got to build the cache beforehand which we can do but, as we need the whole of the UK, will be a pain (especially as we have to go down to street level).
Does anybody know if there any existing cache files that we can download and use? I've looked at downloading OSM files but haven't got the faintest idea how to use them, convert them (into the gmdb format that GMap seems to use).
Any ideas?
Check out VectorTileRenderer (https://github.com/AliFlux/VectorTileRenderer) which has a demo for Gmap.net. All you need is an MBTiles file which you can download for free at OpenMapTiles.org (https://openmaptiles.com/downloads/europe/british-isles/)
I've been tasked with developing an application for internal use in our company, the end-users being the operators of the call center and their superviser.
There would be therefore be two types of users: operator & supervisor.
The operator view would be purely passive: ability to see their monthly goals (calls taken, calls answered etc) as well as those of their "cell"(group of operators+supervisor) and other "cells" and that's it.
The supervisor one however would be able active: they need to be able to set monthly goals for their subordinates as well as view them.
The application needs to live in the browser, and that browser is...sigh, either IE6 or IE7. So my question is, should I use something client-side like backbone.js, or something server-side like, say, Code Igniter?
I need to be able to develop it in a short time frame and add features as requested.
Any advice is greatly appreciated.
Thanks.
Firstly, IE6 is very old. It is still supported but support will end fairly soon (about a year, I think), so your company needs to have an upgrade plan in place. IE7 has a bit longer to run, but will also fall out of support at some point. Your company must make plans for an upgrade process. And you need to make sure that anything you write today will continue working on upgraded browser versions when they come.
Okay, that aside, today you need to support these browsers.
The first advice I would give is to use jQuery for all your Javascript needs. It is specifically targeted at being compatible with IE6 and above, and it hides a lot of the complexities with cross-browser and old-browser support from the developer, but also works well with newer browsers too.
IE6/7 do have a number of serious bugs and omissions in their Javascript support, but these can generally be worked around. Using jQuery will mean you can forget about most of them.
In the main, I would recommend against using a client-side framework like Backbone. Stick with server-driven simple HTML pages. Maybe a bit of ajax using jQuery, but nothing too much more than that. IE6 and IE7 are very very slow browsers, so the less work you make them do, the happier they'll be. Put too much Javascript on the front end and you could wind up with a system that is too slow to be usable. Also, a lot of modern JS libraries don't support IE6 at all. I'm not sure about Backbone, but even if it works now, you can't be sure that later versions will continue supporting it. (even with jQuery, some developers are starting to push for IE6 to be dropped. I don't think it'll happen just yet though)
Make sure you specify a valid <!DOCTYPE> for all your pages. Without it, IE will drop into quirks mode. This will make it very difficult to upgrade your site to a newer browser later on. There are many valid doctypes, but it doesn't really matter which one you use, as long as it's valid. Therefore, I suggest using the HTML5 doctype, simply because it's valid and it's short and simple: <!DOCTYPE html> -- that's all there is to it.
CSS is where you'll really have some pain if you're used to working with modern browsers. IE6 in particular has terrible CSS support. For IE6/7 CSS compatibility, I recommend using the Quirksmode.org compatibility charts to find out what does and does not work in those browsers.
Finally, make sure you read up on the well known IE6 bugs. There are a lot of them, and they often cause weird and wonderful rendering errors on perfectly valid code. Knowing about them in advance will help you avoid them, and help you recognise them when you (inevitably) hit them.
Hope that helps.
Oh, and good luck -- it sounds like you'll need it! ;-)
Developing websites or web applications for Internet Explorer 6 is possible as long as you do not use things such as HTML5 Javascript functions.
As for the live part, maybe you could use AJAX long polling or something similar. Example: http://techoctave.com/c7/posts/60-simple-long-polling-example-with-javascript-and-jquery
Hope this helps!
I am researching best practices for developing 'classic' style mobile sites, i.e., mobile sites that are delivered and experienced as mobile HTML pages vs. small JavaScript applications (jQuery Mobile, Sencha, etc.).
There are two prevailing approaches:
Deliver the same page structure (HTML) to all mobile devices, then use CSS media queries or JavaScript to improve the experience for more capable devices.
Deliver an entirely different page structure (and possibly content) to devices with enhanced capabilities.
I'm specifically interested in best practices for the second approach. Two good examples are:
MIT's mobile site: different for Blackberries and feature(less) phones than for iOS & Android devices, but available at the same URLs -- http://m.mit.edu/
CNN's mobile site: ditto -- http://m.cnn.com/
I'd like to hear from people here at SO have actually worked on something like this, and can explain what the best practices are for delivering this type of device-dependent structure/content/experience.
I don't need a primer on mobile user-agent detection, or WURFL, or any of the concepts covered in other (great) SO threads like this one. I've used jQuery Mobile and Sencha Touch and I'm familiar with most approaches for delivering the final mobile experience, so no pointers required there either thanks.
What I really would like to understand is: how these specific types of experiences are delivered in terms of server-side detection and delivery based on user-agent groups -- where there's one stripped down page structure (different HTML) delivered to one group of devices, and another richer type of HTML document delivered to newer devices, but both at the same sub-domain / URLs.
Hope that all makes sense. Many thanks in advance.
At NPR, we use a server side 'application' to serve up the correct html/css/etc depending on if the user is on a high-end device or a lower-tier phone.
So, when a mobile device pings an npr.org page, our servers use a user-agent detection method to point them to the corresponding m.npr.org. Once directed to the m.npr.org URL, the web app - which is written in groovy, but I think could potentially be a number of things - sends back either the touch version of the site or the more simple, stripped down content. The choice of the web app is made based at least somewhat on the WURFL data.
I don't have enough rep points to post a comparison with screenshots, so I'll have to point you to the sites themselves.
You can see this in your desktop browser by typing in m.npr.org to see the stripped down site. And you can override the default device detection by adding the parameter ?devicegate.client=iPhone_3_0 to see the touch version you would see if you just went to npr.org on your smartphone. If you view the source, you can see how different html & css is being served at the same subdomain.
Hope it helps seeing something like this in the wild. Does that make sense?
A common way to detect which format a mobile device needs is the accept header:
application/xhtml+xml > xhtml
text/vnd.wap.wml > Old wml wap pages
.
.
.
On newer devices which can handle all the desktop html formats, you can use the user agent.
Then you have to ask yourself what you want to do:
Switch to another Stylesheet (only works with newer devices).
Switch to another view logic, like building wml page templates.
Switch to a complete other page.
I think the second approach is the best one. Many web frameworks make it easy to switch to another view logic without rewriting the rest (the mvc pattern in its glory).
I have two examples for you.
Read up on how facebook achieves this using XHP to give abstract different output for different markups: One Mobile Site to Serve Thousands of Phones
There will be a lot of good stuff in their actual implementation which I wish was available.
I use a framework called HawHaw, which let's you write your app once (in PHP Objects or XML files) and it outputs the correct markup to the device based on a few checks (accept header, agent string etc).
I have to deliver 2-ish GB media files to customers (zipped up) after purchase. Any advice on how to deliver such big files to the general population (translated: novice internet users who will not be savvy enough to use FTP or something).
We can build a download manager for Windows users, but I doubt we'll be able to get one for Mac/Linux. Is there a standard solution I don't know about?
Thanks!
For most users on a high speed internet connection, novice or not, a direct HTTP download link is likely sufficient. Just be sure that your HTTP responses for both HEAD and GET return the Content-Length header so that users get an accurate progress bar for their download.
In my opinion, the only other reasonable option for novices is probably a download manager. You could of course build your own (possibly using a product like Real Basic to quickly code for all 3 platforms)
There are a number of companies out there that have off the shelf "download assistants" as well. May want to take a look at what companies like Adobe are using for their software downloads.
EDIT: Turns out Adobe uses a custom AIR application for their "download assistant" which is a cross platform option as well.
I'd say have them as a .torrent file. That way people can continue where they left off, and don't have to start over. You can divide the file into a bunch of rar's or .r01-.r20 and it'll help with distribution. THe bottom line is you don't want people to keep having to start over, this can be frustrating. With a .torrent is viable, especially if you don't want to use FTP.
Windows doesn't have a built in .torrent handler, but I'm sure Linux does. OS X I'm not sure about either.
I have an ASP.NET app in which I've used Vertigo's SlideShow 2 silverlight image gallery component. All was working well and the app went through testing and suddenly, after a recent deployment I get an alert box that says:
IMPORTANT: Remove this line from json2.js before deployment.
This pops up after the Silverlight component loads but then the SlideShow2 xap file seems to work fine after that.
Anyone have any ideas on why this would just start happening? I've done some research and can't come up with much and it's pretty mysterious that it just started happening. I've not directly used json2.js in this application nor have I customized the Slideshow 2 component in any way.
It also happens both in my dev and production environments.
-Kevin
Something like this?
From http://tech.groups.yahoo.com/group/json/message/1413:
Thu Dec 10, 2009 5:23 am
The server at JSON.org is getting
hammered. It turns out that there are
some sites that are linking directly
to json2.js instead of dispensing it
from their own servers. By far the
heaviest impact is from
onlinebootycall.com. My intention was
to provide the world with a free
implementation, but the world can buy
its own bandwidth.
So I have added this line as the first
line in the json2.js file:
alert('IMPORTANT: Remove this line
from json2.js before deployment.');
It will not break anything, but it
should help get a message to the
onlinebootycalls that you should not
load code from strange third party
servers. It is not safe.
- "Douglas Crockford" <douglas#...>
Don't link to json.js OR json2.js directly from json.org. It is bad etiquette, it uses their bandwidth for your site.
Copy the file to your own server, remove the line, and redeploy.
p.s. what are you using silverlight for at onlinebootycall.com? Curious... ;)
In doing more research (and taking a step back to evaluate my environment), the implementation of SlideShow2 I am using is a modified one from an opensource CodePlex project. This particular version supports streaming images and albums from Picasa's web albums. The version I'm using is located here: http://slideshow2picasa.codeplex.com/. In checking out their online dmeos they exhibit the same behavior so obviously this implementation is linking to the json2.js file on your servers as a means to interact with Picasa web.
Today I'll take at their code and see if I can rely on a local copy fo json2.js.
Thanks for helping me out.