I am impressed by ExtJS Samples/Demos especially the Border Layout examples. Is it feasible using ExtJS or other frameworks/libraries to build a viable web app that dynamically creates (say 10) new panels; something like how Eclipse builds and docks new split panels?.
These container panels would contain tabbed widgets and the panels would need to be maximizable/minimizable and closed completely if the last tab member is closed.
(again like how Eclipse closes it’s non-editor views).
I assume that CSS styles would have to be programatically added to the DOM elements that make up the container panels but think that you could use style sheets for member layout(members could be document content or have their own widgets);
I suspect that performance would be poor and that there would be many problems in faithfully rendering the members style sheets.
I have no interest in writing an IDE in js but I am interested in knowing the limits of this approach for creating a ‘reasonably’ extensible app.
I want to provide additional context to my question.
Currently we have a desktop app in Java Swing which allows us create panels dynamically and has the features I outlined and works as follows.
Consider a simple Explorer panel on the left and an Editor panel on the right.
Editing work can be for 4 different regions and all the work for a single region is grouped in tabs in the one panel. When the user is working on a region then other region editor panels are typically minimized; visually apparent as icons on a docking panel to the right of the Editor panel.
There is total flexibility in letting the user switch working to a different region and in some cases even having 2 Editor panels open so that he/she can compare (and even do limited drag&drop from) work in one region to another. When 2 (or more) Editor panels are open they stack vertically under one another. There is no real need to have more than 2 editors open but it is allowed. We have logic that prevents mixing region views in the same editing container.
The current app performs well, allows multiple tabbed views and permits users to segregate their work. More importantly it has allowed us to introduce and use different view ‘types’ providing the extensibilty I mentioned.
Before I get any responses saying that the design is wrong and that I should consider different layouts (Accordion type panels on the left come to mind) let me reiterate that I am interested in knowing the viability of this approach for a web app. whether or not we pursue this approach.
Trigger-happy dismissals of ‘subjective’ content are something I am willing to absorb.
That's an immensely broad question. Technically, I would say that the answer is yes, but your question suggests that you come from a world where the overwhelming paradigm is desktop applications. Trying to impose that dogma on a web context is possible, but suboptimal. You could probably do much better by embracing this media, which is radically different from the one you are familiar with. That is a tall order though.
Somewhere halfway in between, there are some gui toolkits that will allow you to build applications in a browser context, that in many respects act like traditional desktop applications. Google Web Toolkit might be of interest to you, since you use Java. Or, as you have found out your self, ExtJS also belongs in this end of the spectrum. You will have to learn a bit of Javascript, but the programming model is close to what you know from Swing.
Related
Until now I mainly made web sites suitable for PC (desktop) with help with Javascript, jQuery. Now I need to make some small web site Tabular job time records with menus, popups, dialogs, charts and the ability to input and modify data by click events (mouse or touch device) on table cell, plus additional statistics, math, etc. I started by making separate versions including jQuery mobile) but after some time it was very confusing for me to track all changes and understand such complex coding! Then I decided to apply some kind of responsive technique but after reading a dozen web articles I'm still unable to make conclusion what way is right!? Do I need to start web site as primary for mobile and then add some code for desktop, or opposite? Or is there some way, implemented does score for all three type of devices? Thanks.
This question is a little vague. If this question is only about the javascript interactions your answers will vary with UX requirements and libraries. As far as layout etc is concerned, both bootstrap and foundation recommend you start with a mobile design to have the minimum amount of elements necessary for all the content, then add features and readability as you get more real estate.
Mobile first is simply a way to ensure that you don't end up with too many elements to fit on a smaller screen.
Let me start by saying I have read plenty of questions and blog posts relating to the use of combinations of backbone/jQuery mobile and comparisons of backbone/Sencha, and have actually had my head in this space for some time but still haven't found quite what I'm looking for.
I'm very familiar with Sencha and have used it for wrapped (phonegap etc.) apps in the past, and I really like it. However for a smaller code base for web projects and more control over browser compatibility and various other reasons it's not quite appropriate for certain tasks.
When I start trying to engineer mobile (but also desktop and tablet) backbone webapps from scratch I find I miss three key things
General mobile 'init', filling the screen etc. (although this is the easiest to replicate)
Tabbed, iOS-style, navigation (of course I can roll my own, but it seems silly)
Scrolling - both scrolling a piece of content, but especially the carousel and how the carousel is linked to the tabbed interface
I'm not massively bothered about mimicking each device's native OS style throughout the app, and in fact would prefer to (whilst following some sensible conventions) make them look a bit different.
Ember has flame and I've used that before, that's kind of the thing I'm looking for.
I know I can build up a toolkit of jQuery mobile, custom script, jQ plugins/iSroll, CSS libraries, backbone UI etc. and do like the idea of compiling my own 'stack' but for some reason it just doesn't feel right.
So, to bring this back around to more of an actual question. I guess I'm looking for ideally a single project that isn't specifically linked to a library - and in theory could run on it's own on a statically coded page if needs be (even though that wouldn't be the case for me now). Or perhaps some words from others who have been on a similar journey and perhaps ended up on the mix of libraries I mentioned earlier with why they decided this was the best solution.
I'm not looking to do anything too crazy, say something a bit like the old sencha oreilly example but using some carousels, and I'd cover the multiple devices and browsers with a mix of Responsive CSS and a bit of JS.
I'm going to continue looking at this myself too and report back if I find anything interesting
Cheers
EDIT
While looking into this, I realised its only really the carousel and scrolling that I really wanted from Sencha. I noticed that Cubiq has a nice slideview component that handles the carousel very neatly and with a small footprint. I found a stackoverflow answer about using this with the original iscroll for vertical scrolling. See my answer below for successfully using the two together
How to use iScroll4 with SwipeView?
This would need some tweaking to work appropriately on desktop. and I'd like to control it from a tabbed UI too. Anyway, I'm not near answering my own question but given this has had a couple of upvotes I'd post some of my thinking.
Quick edit
You can attach events for tabs to the slideview https://dl.dropbox.com/u/81328343/scroll/1.html but at the moment, it only animates for next/prev and not direct page (tab) access
Webix
Very big library of components.
I've used Twitter Boostrap with Backbone...
http://twitter.github.com/bootstrap/
Basically, I want to combine a HTML5/CSS3 webpage with the Sencha Touch framework (to make use of it's awesome model/store/AJAX functionality).
What would be the best way of doing this? At the moment I'm thinking of creating a top level container in Sencha and plugging the HTML for the page in as a template. However I'm going to need a few DataView objects and I'm not sure how I'd position them in the page unless the whole design was done using Sencha objects.
Well you've got it pretty much figured out already, you just need to get your feet wet now. ST will let you embed any existing HTML or CSS in pretty much any component. That will let you start to leverage ST's non-visual tools like stores and models.
The minute you want to start including other ST visual components though, you can get stuck. ST components are intrinsically tied to it's layout system. That means if you want to drop in lists or other data views, their size, alignment etc is all tied to their parents' layout and other attributes. If they're just dropped in freeform HTML they probably won't look right.
My advice is that you bite the bullet and re-do the whole site in ST. Remember that you can still re-use a lot of your existing HTML fragments within ST panels and containers of your new mobile site. But the important thing is that ST now forms the 'shell' of your mobile site, and that ensures that any ST components you use will be correctly formatted.
I'm working on a music editor/sequencer app that will be written in JavaScript+HTML5 and will make use of the canvas element and Chrome's Web Audio API (I already have a simple prototype working).
One of the things I'm not so sure about is how to implement the GUI for this. It will need to have many different views, and I'd like to perhaps have each view in a different clickable "tab", with one tab in the foreground at a given time and all the others hidden. I'm just not sure how to go about implementing all these tabs.
Would it be better to implement each tab as a different HTML layer and have buttons control which layer shows up on top? Would it be better instead to (re)generate HTML on the fly when the tab buttons are pressed?
Your advice is appreciated.
Would it be better to implement each tab as a different HTML layer and
have buttons control which layer shows up on top? Would it be better
instead to (re)generate HTML on the fly when the tab buttons are
pressed?
I would lean towards generating the content once and showing/hiding it on demand especially if the majority of work is done in the browser and there are no synchronous requests being made to a server when interacting with elements on the page.See footnote 1
When showing a tab's contents...
Assuming the content of each tab generates quickly, you can make your application more efficient by only creating the content for the tab when it is requested the first time. This way, if the tab is never accessed no resources are used.
When hiding a tab's contents...
When working with multimedia you may need to perform additional actions when you hide content. For example, a video won't stop playing just because you hide it. For your audio application you may need to stop playback of the current sequence.
There are many tab controls available such as jQuery UI tabs (free) and Sliding Tabs (licensed but inexpensive).
Other Scenarios
Tabs should be used for switching between major blocks of content like documents (e.g. browser tabs) and/or regularly used functionality (e.g. a personnel form which has a tab for contact information and another for employment history). Other scenarios may be better suited to a dialog (modal or non-modal).
Using the audio example, if you had a button labeled "tempo", I would expect it to open a small dialog window on top of my current view rather than taking me to a new tab. Roland's workstation keyboards use this paradigm. Major content replaces the current view, but settings/configuration windows usually popup atop the existing view.
jQuery UI also has a dialog plugin for this purpose. If you are JavaScript savvy and targeting newer browsers, it's not that hard to write your own simple dialog.
1 Generating content on the fly may still be perfectly acceptable with an interactive client-server relationship, but it introduces additional considerations, such as the synchronization of what is in the browser with the data model on the server (if any), the submission of unneeded form fields (increasing the size of the request), overall page size, etc.
I would suggest checking out the JQuery UI library. More specifically, the tabs functionality that it provides, http://jqueryui.com/demos/tabs/.
Simple rule of thumb for loading data into your tabs. Small and Simple, load it up front. Large and Complex, load it on demand. When in doubt, load it on demand.
if you're looking for a complex UI, I recommend you check out Dojo or Ext JS. They both provide you with a UI framework closer to Java's Swing framework.
However, if you're looking for tabs, and tabs only, jQuery UI is great.
If you're working on a canvas, do your GUI on your canvas. Seriously. Using divs in front of a canvas is just boring. I tried both, and I prefer using canvas.
The easiest way is to create a "button" class which will take an image and define a clickable zone on your canvas for this image (if you want pixel-detect there is a way which uses offscreen canvas and getpixel to check colors under the mouse and stuff, too long to explain here).
Then once you have your button or whatever gui class, you can put them on your canvas and you won't have to manage multiple html elements.
Also, some html elements in front of a canvas often have weird behaviours. That's why I prefer creating my gui directly on the canvas. Harder at the beginning but proper.
Of and please, make it possible to place multiple squares without having to reclick (just use a mouseDown variable)
I need to build a wysiwyg editor for a project I am working on and need some guidance. Some of my key points of confusion are the following:
iframe docs vs. contenteditable divs: which one should I use and why? I hate iframes, is there a clear advantage to using iframes?
cross browser styling: execCommand seems to apply different styles in different browsers. Are there any tricks to making this cross-browser compatible? Should I not use execCommand at all and instead apply my own styles?.
adding items to the undo chain: how can run my own script, such as inserting an image, and allow cntrl+z (undo) to remove it? Is there an array of undo/redo items for contenteditable that I can push items into?
keeping the text selection: how I can maintain text selection while making operations such as selecting the font style, where the focus will leave and remove my selection. Rangy? Google closure? Are there other range/selection libraries worth looking at?
Any tips on these items or anything else related to building a rich text editor would be greatly appreciated!
From personal experience, I recommend against doing this unless your aim is to provide a very limited amount of functionality. The sheer number of browser differences and the complexity of their workarounds makes this a very tricky and time-consuming task if you want to do it well.
If that hasn't put you off, here's my thoughts on your individual questions:
iframe docs vs. contenteditable divs
I recommend the iframe approach, for two main reasons:
You have complete control over the document type, CSS and script within the iframe. This is essential if you want consistent behaviour and appearance and want to use your editor within different pages.
Firefox in particular is quite buggy with contenteditable elements, which they only introduced relatively recently (version 3.0) while designMode has existed on documents for many years (since pre-1.0; around 0.6, if memory serves) and works pretty well.
cross browser styling
If it's important for you to have uniform results from applying styles in different browsers then in general you will need to write your own styling code. However, doing this will break the built-in undo stack and you will need to implement your own undo/redo system.
adding items to the undo chain
There's no programmatic way to interact with the built-in browser undo stack. You'll need to write your own.
Update November 2012
There is a spec in the works for custom undo/redo so this is likely to be possible eventually. Here are the relevant bugs for Mozilla and WebKit.
keeping the text selection
I have to declare my interests here, since I wrote Rangy. I don't think there's a better library out there that does a similar job; Google Closure does have a range/selection API but I think it uses their own proprietary interface rather than emulating DOM Range and common browser Selection objects. IERange is another library that is similar in idea to Rangy but much less fully realized and seemingly abandoned immediately after release by its author.
Don't, seriously don't.
What you are suggesting is a major undertaking. You really should be looking at TinyMCE, http://tinymce.moxiecode.com/, or CKEditor, http://ckeditor.com/. Getting what you are after is a massive amount of effort to get working for one version of one browser, to make it portable will take man-years of investment.
A better solution is to look at things like TinyMCE's plugins, http://tinymce.moxiecode.com/plugins.php. You can get your basics the basics (and portability for free) and concentrate on adding the specific value-add items you need to.