I'm looking to implement drag & drop in MSIE (must be, a bonus for other browsers, but just "nice to have").
I'm looking at a sort of drawing package - let's say flowcharts for example. The user can drag flowchart elements from a palette and position them in the browser. When complete, I will need to know the type and position of each element, probably some other data too.
Can this be done? If so, what's the most powerful technology to do so? HTML 5? Ajax? JS? Something else?
Short version: I would recommend JQuery UI (A javascript framework), this will make your life easier. As for other components, you are free to stack it up from server-side to client-side components depending on your needs and most of the times depending on your preferences.
[update] The long version: Personally, if I would start a useful website with a back-end, I would use Java as my PL of choice since I'm familiar with it, SQL for my persistence, and make it a Web 2.0 site, like what you want to achieve which is a rich internet application (drag and drop, dynamic content, etc). I would normally make use of Java (JSP, Servlets) but use Grails framework (Groovy, GSP, Groovlets), SQL DB (like MySQL, SqlLite, etc), Ajax, HTML, CSS, Javascript (JQuery as my JS framework). Eclipse would be my IDE to program and integrate all of these components.
Some people would prefer to use Python, others PHP, some .NET, Ruby on Rails, etc. Like what I said, it is very subjective. If you already have a field of expertise, then I suggest you stick with it, but if you are starting from scratch, it's basically a choice of the easiest learning curve for you because different Programming Languages can and will satisfy your needs.
For the front-end you have Flash, Applets / JavaFX, Javascript, etc. The problems with Flash, Applets or other embedded media are 1) heavy on resources 2) compatibility, but the clear advantage is that they are more robust because you can do so much more with these technologies in arguably a smaller amount of time. But if you want to use one of these, you have to seriously think about your target audience e.g. for Flash, iPad and iPhones cannot display them at all (except if you installed the unofficial "frash" which supports a bit of flash content).
I believe what you want to do is highly feasible even if you just use Javascript, and again, I will strongly recommend that you use a framework that can readily satisfy your needs (like drag and drop) so that 1) you'd worry less about cross-browser compatibilities, 2) you won't have to reimplement them and 3) fix many unexpected bugs along the way. But this is the general idea if you are developing a software, if the framework or library already exists, use it (just be extra careful with licensing though but this is another topic) :)
disclaimer: rum + coke = awesome
use javascript, that's all you should need to have drag n drop for elements. for example : http://flowchart.com/demo/
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Like, can I write a business strength application in HTML5 that mimics our current system that contains many highly interactive grids, custom trees and so on.
We have a good working system written in C# WinForms with parts done in WPF and have recently embarked on writing a custom app for the iPad that communicates through WCF with our main server hosts. We now have a very fast custom grid written in C# that compiles to Objective C through MonoTouch and also a cool interactive pie chart.
Now my boss wishes to build a version for Android and I am thinking if we shouldn't really be spending time creating a single HTML5 app that can run on both iPad and Android equivalents.
Thing is - take a grid - my grid on the iPad is fast (re-usable cells etc) - how would I create a grid from a 'dataset' type source in html5? Do I really have to go down creating lots of tags and then submitting them to the browser? Are third party widgets like jqwidgets the answer??
Thanks
This is a bit anecdotal, but my experience has been that HTML5/JavaScript are just not fast enough on mobile devices yet (in 2012) particularly if you are displaying lots of data, especially and you want fast response times with interactive features. Give it another year, and I wouldn't be surprised if this statement becomes outdated as mobile devices continue to evolve.
Mobile web development certainly has its uses currently, e.g., if you want to target the most devices with a single codebase; if you don't have enough development resources and are willing to settle for a non-native experience; if you don't have experience in the languages required for native development, etc.
Given that you already have done the work for the iPhone app, my humble opinion is that it's probably better to move forward with a native Android application -- you will get a much more responsive application for about the same amount of work at this point.
how would I create a grid from a 'dataset' type source in html5?
Depending on what the grid contains, you can do it with plain old HTML tables or with a combination of other elements styled with CSS. There are really many more considerations though-- e.g., does it need to work on small screens (e.g., phones) or just larger screens (tablets). Often, you can't really fit a whole grid on a small screen, so you end up with UIs that aren't really grids anymore. You can take a look at a mobile JavaScript framework such as jQuery Mobile to see how they've done it and maybe even consider using the framework for use in your own application.
The various JavaScript frameworks (eg. JQuery and Dojo) have mobile device-specific widgets of quite high quality. Have a look at http://dojotoolkit.org/features/mobile and http://jquerymobile.com/
How close do these get to native apps developed in ObjectiveC and Java? Not perfect but maybe good enough. You can also use a combination of native and HTML in the same app, some pages native some HTML. I'm doing that kind of thing with IBM's Worklight, but then I would, I work for IBM ;-) Irrespective of specific products I do see folks taking that approach.
In addition to portability, anoyther of the benefits of having much of the app in HTML is that updated versions can be delivered without going via an app-store - this increases agility of functional delivery.
As evidence, I'd say that a lot of Windows 8's apps are just wrapped JS/CSS/HTML, with a few APIs which Microsoft supplies to allow access to hardware/the filesystem.
I wouldn't think that they've gone so far as to make Excel 2013 JS-based...
...however, with that said, they have gone so far as to allow developers to extend their programs with applet views of the data -- those applets are all going to be built on "html5" (again with an MS-Office JS API).
It's not an easy road to go down -- people look to jQuery to be their saviour for these types of things.
This is exactly where jQuery would not be what you wanted, if you were looking to hack together a solution.
For example:
$(".table_cell").click(function () { alert(/*whatever*/); });
People think that jQuery is assigning a delegator to listen to any click on any element containing class="table_cell".
That's really not what it's doing.
It's looping through each one, and attaching an event-listener to each one, directly.
It's these little things that people miss -- people like Twitter, who didn't bother caching references to elements, because jQuery is so easy to hack things together with.
So then you have JS touching (or acting on) dozens or hundreds of individual elements, at all times.
That's not good for anyone.
jQuery isn't bad at all -- it's quite helpful, as a low-level construct to help skirt around browser differences.
Some of its plugins are also all right.
I can't guarantee that they're all high-performing answers to all things.
But some of the plugin-creators understand how to maintain a responsive and well-performing program.
Which ones are right for your exact needs? Who knows, other than you.
Will they perform perfectly, and quickly?
That depends on a lot of different things, of course.
Coming from C#, you might do to look at something like AngularJS.
Angular, itself, uses an internal version of jQuery, to tackle some of the low-level stuff that jQuery has made a solved-problem.
But it allows for data-binding, and pretty simple view templating.
Hammer.js is also a very decent gesture-tracking library.
From there, though, I'd suggest building your own framework, if you want it done the way that you want it to be done.
Nobody knows what your needs are but you, and trying to stuff things into a shoebox, because it's available, isn't always the solution, regardless of what various companies may think...
You can leave most of the node-work to Angular, you can leave the gesture-sensing to Hammer, you can pull out some other basics from jQuery-lite (the no-frills jQ installed inside of Angular, if you don't have jQ on your site), or jQ, itself...
But they're just tools and not answers.
The web can be very responsive if you cache references to elements, rather than querying for them over and over, delegate events, do large structure-changes off-DOM (on cloned-nodes, if necessary), and don't try to treat JS as a traditional inheritance-heavy language, and you remain mindful of how and when to use AJAX (number/frequency of calls versus size of data -- favour fewer calls).
The server side is pretty much set up, it's basically
struts 2 / spring security / jpa.
Now I have to decide what to do with the client side (the browser). The client side codebase should be maintainable and should lend itself to automatic regression testing.
So as an example lets say I need a table component having properties such as
sortable/pageable columns
reordering of rows and columns (via drag & drop)
inline editing of table cells
remembers state when customer re-visits page
integrates easily with struts 2
As far as I understand things there're 4 alternatives
DIY using oldschool HTML + JQuery + Ajax
Finding a JQuery plugin that does all this or
plumb together different plug-ins (like Flexigrid + additional plug-in for drag & drop)
Using a JS toolkit
Should I stick with JQuery? Or should I go for fullblown JS toolkits? I have little experience with JQuery and JS toolkits (I'm not a web developer).
Thank you for helping a serverside programmer cross the messy world of web-ui-programmming ;)
My experience is that Dojo's support for programming-in-the-large is great if you have a large-scale app that will benefit from the build system, class system, widgeting system and integrated widgeting library. It also of course brings all the standard stuff with it, like cross-browser support and event system.
If you just need some widgets and animations then any library will work. I'd stick with the one you/your team knows best. jQuery definitely has the greatest number of people with that skillset.
Our team wasted 6 months trying to give the client what they wanted with JQuery/UI, and we switched to ExtJS 4, and the client is happy after 2 months. This is an app with 50+ models.
JQuery/UI is NOT designed for web applications. It is designed for web SITES. Sure, it has some good plugins, but you'll spend countless hours learning their apis and switching your thought process between them all. JQuery/UI lacks the following:
a graphical designer (see Sencha Designer 2), ie graphical layout GUI program
complicated layouts (in ext you can switch a layout of a container to accordion, tabs, wizard, anchors with one setting)
a grid (ext grid supports paging, sorting, filtering, grouping, summaries, editing out of the box)
real comboboxes
a model view controller system
templating
good html editor control
a whole ton of other stuff
do yourself a favour and spend the money on ext, and save yourself countless hours.
regarding the grid you mentioned, ext's is far superior to anyone else's. you can do what you listed in about 20 nicely-formatted lines. i am not kidding.
regarding client-side unit testing, use jasmine with ext.
The short answer is yes. Frameworks like Ext.js take care of a whole lot code that you would end up writing yourself if you were to write everything from scratch. These frameworks take care of models, events, views, communication with servers/APIs, etc.
This isn't really an answerable question. It all depends.
ExtJS is great for very specific things. If you want those very specific things, it's likely the most efficient option for you.
If jQuery UI meets your needs, then that's your answer.
If you have jQuery dev's, maybe stick with jQuery.
If you have ExtJS folks, consider ExtJS
etc, etc.
This question has a discussion of progressive enhancement. My question is about the alternative type of web application. If you have a web app in which the UI is constructed almost entirely in Javascript, won't gracefully degrade, has a desktop feel, etc., what is that kind of web application called?
Do you mean this type or the opposite of this type:
"Rich Internet Application" where you could have an application that runs on for example AIR.
to me, what you describe seems to be a JavaScript based fat client ... i see nothing wrong in that ...
the thing is, that everyone forgets is that HTML means hypertext markup language ... it is a format for describing documents and was never designed to capture the functionality that some HTML-based apps offer nowadays ...
the answer "RIA" seems the best to me ... of course that includes flash and silverlight ... but your choice of HTML+JS is completely arbitrary in this case, because you manipulate the HTML DocumentObjectModel with JavaScript as a flash developer would manipulate the flash DisplayObjectModel with ActionScript ...
there are simply web apps, that are document and form based ... they have a CRUD infrastructure for some type of data, that is accessed in a RESTful, or at least RESTish way ... this type of apps can employ progressive enhancement, using HTML to capture its semantics and plain HTTP for all client<->server communication... i'd tend to simply call this kind of web app a web site ... having a bit of funky AJAX won't change that really ... i mean, from a simple guest book, to a forum, to stackoverflow, the basic idea never changes ... and a guest book does not make a web application, does it?
there are web apps, where the state is fully maintained by a much richer client, because these apps do a lot of granular data manipulation, as opposed to the document based CRUD web apps, and to me, this is the type of web application actually deserving the name, but i'd call them RIAs, to emphasize the difference ... in some cases this solution is faster, more lightweight, scalable, usable, easier and faster to develop/maintain/extend, and simply more natural ... this choice is often based on the type of data they deal with, as well as the functionality exposed for manipulating that data ... for example, if you were to implement a game like tetris, progressive enhancement wouldn't be the way to go ... instead, in order to create such apps, willful misuse of HTML is required ... so what? :-D
so, yeah, RIA is the right word, i'd say ... and opposed to others, i think first of all, it is a great, easy and powerful way of deploying functionality ... i mean i get the whole "inaccessible" and "incrawlable" thing ... but the latter is often pointless, and the first one is a problem you can't address properly, unless for example screen readers read whatever is in the DOM, instead of spitting out the original page ... but that's the problem you face with "real", i.e. desktop like, apps ...
greetz
back2dos
Monolithic?
Well, really the opposite of "progressive enhancement" is "graceful degradation", even though they basically achieve the same thing.
Progressive enhancement means you start off with plain old HTML for older browsers, then enhance it in stages, with cross-browser CSS, additional CSS (e.g. CSS3 styles), Javascript and AJAX.
Graceful degradation means you rush headlong into creating a Rich Internet Experience, then tack on alternatives for people without Javascript/CSS.
Anyway to answer your question, I'd probably call it "ungraceful degradation". Alternatives:
Badly designed
Uncrawlable (from search engine perspective)
Inaccessible (credit: Chuck)
Inaccessible.
It just doesn't degrade well.
I'm not sure I'd categorise applications as progessively enhanced, because that inferrs that there is some sort of baseline. How far back should an app degrade before it's considered as 'progressively enhanced'?
At a push, I'd say the app is dependant on certain features of the browser - maybe it is 'edge dependant' or 'modern browser only'?
UI is constructed almost entirely in Javascript, won't gracefully degrade
Arrogant. Presumptive. Illegal (depending on specifics of application and jurisdiction).
Why HTML/JavaScript/CSS are not becoming compiled languages (or maybe even merge into a single compiled language)? What if browsers were running "Browser Virtual Machine" and html/javascript/css sources could by compiled to a "browser bytecode". Wouldn't it help developers and users a lot?
I can see a few challenges:
What to do with zillions of existing pages? Make this compilation optional, so if you want you can use plain old html. If you want to feed a browser with a compiled page just use .chtml for example.
How search providers would index pages? Make a decompiler that would decompile bytecode into exact original sources (for example like flash can be decompiled). Or search providers can use the same virtual machine and get data they need from there.
How to make it compatible with all browsers? Have one centralized developer (lets say w3c) to develop this virtual machine and then each browser would embed it.
But what about benefits:
Speed.
Size.
No more "loose" and "half-correct" html. It is either correct or won't compile.
Looks the same in every (supported) browser.
If not a bytecode then at least have some native compression going on, html probably is not the most efficient way of data storing. I know there is gzip but why to compress pages every time on a server and decompress in a browser if we can compress it once and feed it to a browser?
So what stops us from taking this road (well, besides a huge amount of effort to make it all happen)?
Ah, but Javascript IS becoming a compiled language. Check out Firefox 3.5 with TraceMonkey. It's insanely fast compared to um you-know-who's browser. It's true that JS will never be C, but it's a much more dynamic language than C is, and in many ways that makes it more expressive and powerful.
As far as HTML goes, I don't think that the lack of validity of HTML is a huge detriment to speed. I think the engines that put together the visual representation and manipulate the DOM need to get a lot better (um, IE, I'm looking in your general direction...). CSS compliance needs to get better, and CSS itself needs to get more powerful. (Get on the bus with CSS 3 people!)
But I do think that speed is going to get better on Firefox and Chrome to such an extent that people really ARE going to start using it for mainstream application development. It's funny. Adobe seems to be selling Flash as their platform for dynamic web content, MSFT is selling Silverlight for dynamic web content, and Google just wants to really improve HTML and Javascript to display dynamic web content. And Google's doing pretty well at it so far, I must say...
Your ideas have validity when they are applied to JavaScript. As others have noted, to one degree or another several vendors are trying to apply those principles to JS even now. Another big step in this area will likely be the Chrome OS Google has announced. However, when it comes to (X)HTML and CSS I think your ideas may be missing the point.
The world wide web is not a buggy and inconsistent application platform but a massive and unprecedented collection of interconnected documents. The power of the web is in the abstraction of the data from the often rigid (and breakable) visual layouts and increasingly complex in-page functionality largely provided via JavaScript. Encoding these pages in (X)HTML is ideal for making them accessible to the widest possible audience both in terms of browsers and in terms of technical knowledge required to author a page.
More and more the web is being used as an application platform - which is a powerful and exciting use of this technology - but we cannot lose sight of the fact that these Ajax-driven "web 2.0" apps are merely documents with extended functionality. Compilation doesn't make sense for a document and compression is already happening (via gzip and the like).
On a more practical note, the W3C moves at a glacier's pace and browser vendors take turns between jumping-the-gun supporting experimental features in unfinished specs and taking their sweet time supporting other specs which have been on the table and in common usage for years. The whole processes is like herding cats. I wouldn't hold my breath for them to make the kind of radical changes you're proposing any time soon.
Since HTML and CSS aren't code they can't be compiled. Google Chrome's V8 engine does actually convert JS into byte code, expect other rendering engines to follow suit!
http://code.google.com/apis/v8/design.html
We recently reworked a php template system I've helped create to use minify to compress multiple JS and CSS into one file each, seeing our file sizes drop to about 20% of the origial combined sizes. Minify also does gzip and caching so it's really amazing for speeding up websites.
http://code.google.com/p/minify/
In short you can't compile non-code, which HTML and CSS are. JS can be compiled and is starting to be, but all depends on what browsers feel like doing.
Browsers just need to be on the ball regarding supporting web standards. The more browsers do this, the less headache us web developers have. I was quite happy with YouTube's very public drop of support for IE6. We need more action like that for the web to move forward.
The V8 javascript engine (also embedded in Google Chrome, but it's open-source and liberally licensed so you're welcome to use it in the next browser you write!) does compile Javascript to native machine code -- of course, it does it "just in time" (like most modern compilers -- Java, C#, etc!), not "ahead of time" (like Fortran did in 1954 when computers were just too weak to handle compilation in the midst of execution). I'd be surprised if other good JS engines, like those in the very latest Firefox and Safari, didn't do the same.
Looks like you're not advocating "javascript as a compiled language" (since it obviously already IS compiled, if you're using a good JS engine), but rather "ahead-of-time" compilation for it (just when most modern languages are essentially abandoning ahead-of-time compilation). Pushing machine code rather than compilable code down the wire sounds like a mostly horrible idea -- much larger size, difficulties in supporting one CPU vs another, security nightmares in properly sandboxing it, etc, etc) with not much in term of compensating benefits.
That said, if you're really keen on pushing machine code to the client, try out nativeclient (as long as the client is an x86 machine - forget every smart phone on the planet, many netbooks, good old macs, etc) -- at least it promises a fix to the security nightmares. If and when you're happy with nativeclient, transforming a just-in-time compiler into an ahead-of-time one is a far easier technical challenge (if you want to keep using Javascript for the sources rather than other languages, of course).
See here for a previous discussion on the matter
Not all of the reasons given are necessarily valid, but one important one is that, unless you're Google, server-side CPU cycles are a lot more valuable than client-side cycles: so it's easier to have the client compile/optimize what is quite often dynamically generated HTML/JavaScript, rather than the server.
Ken
Speed.
You're assuming that it takes significant time to parse HTML. However it might be that that time is insignificant compared to the time required for something else, e.g. the time required to layout the text on the end-user's window.
No more "loose" and "half-correct" html. It is either correct or won't compile.
You already get that, using [X]HTML.
Looks the same in every (supported) browser.
You seem to be saying that there should only be one browser, or that all browsers would support it equally.
Internet standards don't happen by having a single body (the w3c) implementing something and declaring it a standard. Instead, internet standards happen by having multiple independent bodies creating multiple implementations. A consequence is:
Some people have developed something that isn't standard yet (i.e. they're ahead of the standard)
Some people haven't yet developed something that is standard (i.e. they're behind of the standard)
I think your idea is sound, however there's still no way to enforce a standard. Thus if there was a non-supported feature, there's a good chance the entire page would simply not display anything. In the current setup, critical information can still be passed.
Google V8, which is one of many new-generation javascript engines 'compiles' javascript into pseudocode, much like .NET 'compiles' c# on the fly. Nothing magical here. Expect more of it esp. as webapps get heavier and more demanding
HTML
HTML is pretty much XML. DTD'd exist for various versions and developers can check against that at any time.
CSS
CSS is not a programming language, however I do agree that "compiled" CSS could work seeing as compilation would compress it. However with the support that CSS has and with the number of essential hacks any CSS needs to have, you'd never manage to compile it without errors.
JS
As others have mentioned, JS IS becoming a compiled language except the browser compiles it for you and not you yourself.
Summary for the impatient:
What I want to know is what you want to have in a new gui language. About the short answers mentioning $your_favorite_one; I assume you mean that, such a language should look like $your_favorite_one. These are not helpful. Resist the temptation.
I'm thinking on the user friendliness of XML based languages such as XHTML (or HTML, although not XML they are very similar), XUL, MXML and others ("others" in this context means that, I am aware of the existence of other languages and their implementations alternative to their original ones, and the purpose of the mentioning only these languages by name is, to give an idea of what I am talking about and I don't feel like mentioning any others and also, I see no point in trying to make a comprehensive list anyway.). I have some opinions about what features should such a language have;
The language should be "human writable" such that, an average developer should be able to code a good amount without constantly referring which tags have which properties, what is allowed inside what. XHTML/HTML is the best one in this regard.
There should be good collection of controls built-in for common tasks. XHTML/HTML just sucks here.
It should be able to be styled with css-like language (with respect to functionality). It should be easy to separate concerns about the structure and eye-candy. Layout algorithm of this combined whole should be simple and intuitive. Why the hell float removes the element from the layout? Why there is not a layout:not-included or something similar instead?
I know that I don't even mention very important design considerations like interaction with rendering engine and other general purpose languages, data binding, strict XML compliance (ability to define new tags? without namespaces?) but these are the points that I would like to ask what you consider important for such a language?
There will always be a tradeoff between ability and simplicity.
Personally I'm happy with the features of WPF (which uses XAML) for MS development. I dont find its complexity to be a barrier to developement at all.
However if your going to target your toolkit/language to a demographic that requires a higher degree of simplicity, you could possibly get away with leveraging an existing framework and provide the end user with a DSL specific to their needs.
Writing a new framework for the dev community as a whole is a mammoth undertaking though, and I suspect you will find that due to the wide range of features required that you will have to deal with a large degree of complexity at some point. Best of luck.
Most recent XML GUI language (not only for GUI actually) is called XAML. It has all that candies: styles, layout definition, objects initialization, etc. But it's a pain to write more or less large XAML files. Auto-completion helps but the core problem - forest of angle brackets - is not solved. Another problem with advanced XML-based GUI langs - they try to serve to several purposes at once, but XML syntax is not suitable for all situations. For example XAML supports data-binding, but why the hell I should write it in attribute string? It's first class feature and should have proper support.
IMO all modern XML-based langs suck terribly. Language intended for humans must not force it's users to write tons of brackets or do deep tags nesting. It must be user friendly, not computer friendly. My dream it to have GUI language with Python-like syntax.
In conclusion I want to say:
Dear XML-based langs authors, please be humane, don't create another language based on XML. Read some good book on Domain Specific Languages and please, don't make me type < and > symbols ever again.
You should have specified whether you mean web or rich client, but either way take a look at XAML/WPF. If you're anti-MS, then look at Moonlight, the Mono implementation of SilverLight.
I would like it to be easy to connect to any database, perform queries that return a recordset, and be able to parse and iterate easily said recordset to display its data in graphic controls, for example pie-charts, bar-charts, timeline charts (stock options like), node graphs with animation effects, all this at run time.
Easy mouse events catching, to implement any action on rollovers, mouseins, mouseouts, clicks, drag and drops, clipboard management, etc. A good infinite zooming capability would be great too.
I don't want to set a "datasource" that establishes a fixed connection between some column in my SQL query and some displayable element at design time, I want to perform any query that I want and show elements tied to any query field, anytime, in run time. I don't want to be only able to bind a datasource and displayable elements at design time.
css style capability for everything. Or something as simple and easy.
resize and layout taken care of automatically. Easy access to local files, to parse, play, display. Easy classes for image management, supporting transparency, resizing, etc. Basic and advanced classes for drawing in the screen: lineTo, rectangle, circle, animations. Even 3D.
Embedded fonts functionality. I don't want to worry about "will the user have this font installed?" Also I don't want to worry about DPI or screen resolutions.
Basic widgets: treeviews, etc.
A good designer. I don't want to add widgets writing the code. I want to place them visually in the screen.
Also, it would be good if it could connect to dlls made in C++ or COM objects in general.