Response title
This is preview!
- Screen name: watusiware
- About Me: Software engineer, mobile/Ruby.
watusiware's Profile
52 Posts
9372 Responses
18
Followers
Activity Trend
Last 30 days
Loading Chart...
Show:
- Expanded view
- List view
- 11-May-2017 10:26 PM
- Forum: Using jQuery Plugins
I need to support touch events for a sketch tool in a hybrid mobile app (Rhomobile Rhodes). I'm interested in what jQuery plugins (or other JS libraries) others are using. I figured this would be of great interest, and didn't really find anything here from a search.I've done the sketch part before in jQuery Mobile - we adapted the venerable sketch.js - fixing the bugs and (horrible) inefficiencies - added a number of new tools, and hooked it into JQM "v" events (vmousedown, vmousemove, etc.). We made a nice silk purse out of a sow's ear, and users (contractors doing energy audits on homes and commercial buildings) have commented it is their favorite feature. (Drawing over photos.)But for a new project I won't be using jQuery Mobile (just Bootstrap, if that). And the sketch code is aged. I'll probably be going with something like paper.js to do the drawing, but still need to find something for touch events. (For now, I am using my tried-and true drawing code, though. Just need to get reliable touch events to trigger it.)I found jquery.touch.events, which seems to be a massaged extract from jQuery Mobile, with events now renamed to tapstart, tapmove, etc.I noticed right off the bat, though, that I never actually get a tapstart. (Put a workaround in my sketch code...) So, started looking around for something else. And anything that is a massaged version of something from jQuery Mobile scares me! ;)hammer.js seems popular, has fairly recent activity (but seems trailing off - perhaps it is "complete"...)I see there is also a 300-msec delay removal library to go with (hammer-time.js). Though I question if that is something that is needed any more. I've used fastclick.js fairly recently, but was really planning on going without on this project, as I think webviews I care about have fixed the problem. (And Financial Times stopped supporting the script.)I've seen some favorable comments about zingtouch:I need the usual start, move, end. And I need to recognize pan and zoom gestures. And probably rotate. I have to say I like the single-finger rotate in zingtouch.I'm hoping to support:- iOS 9 or 10, webview or wkwebview. (maybe just ios10)- Android perhaps as far back as 4.4.2 (many Android devices are locked-in on older versions, and it is for students, so can't be too demanding about devices). In any cases, only versions that use Chrome for webview.- Windows 10, including surface. Unfortunately it will use an edge webview. (Not webkit, that sure would be nice!) No need for Windows phone, though!Would love to hear positive/negative comments about the above plugins/libraries or others.I'm not interested in bloated frameworks that might also include touch and gesture recognition. But others might, so feel free to add comments about frameworks as well.- 14-Apr-2017 03:49 PM
- Forum: Using jQuery Plugins
This morning, I came across a blog post about jsRender:It's a lightweight template renderer that can be used with (or without) jQuery.http://www.jsviews.com/ (try-it demo)Somehow, I hadn't heard of it before.I find it very attractive for my work. I write hybrid mobile apps using the Rhodes platform, and in Rhodes pages are (generally) produced from ERB templates and served by an internal server that takes an MVC approach. So, I have no use for the over-complicated MVC and MVVM javascript libraries like Angular, React, Backbone, etc.But I do have an occasional need to generate small amounts of HTML in JS code and it seems silly to make a round-trip to the server (even though local on the device) to render a template using Ajax. So, I'm afraid I use the tried-and-true but ugly and error-prone method of pasting together some strings.I've found a good rule in software development is the "rule of 3". If you repeat the same code 3 times, time to bundle it up into a function, etc. You can extend that to "if you use the same painful and error-prone construct 3 times..."Well, I definitely do that more than 3 times!jsRender has a long and convoluted history. It came out of an effort to add template support to jQuery. Or jQuery UI. Or something like that... I don't think the blog author above quite got the history right.Wow, that was back in 2011! I'm curious: have the jQuery developers decided to permanently get out of the "template business"? Well, I suppose it makes sense to step back, because their are so many opinions on how to do templates.Interested in hearing comments from anyone using this. While perhaps a "blast from the past", it looks like it is currently-maintained, and there is now also jsViews and jsObservable to go-along with it.Has anyone here used both Mustache (or Handlebars) and jsrender? Which do you prefer? Obviously, Mustache has popularity going for it.I looked at some benchmarks, and almost all of the popular JS template rendering engines have similar performance.Handlebars is about 50% more code (minified) than jsRender. (Though both are fairly small).I am not looking for something to do the heavy lifting for an entire site. Just something to replace the silly paste-together code that I occasionally use client-side.(And, yes, I've been planning on moving to ES5 and then use Babel to generate ES4 for Android apps, because Android users don't update and/or they are blocked from updating by manufacturers and carriers... That at least would allow me to use backticks instead of pasting-together a bunch of strings...)- In my response to the following:https://forum.jquery.com/topic/jquery-calculations-on-run-timeI edited the URL for the jsFiddle so that the end was /3 instead of /1.While the displayed text showed /3, the underlying link remained unchanged - /1!I had to delete the entire line and re-enter it.This is going to cause a great deal of confusion if not fixed. I only noticed because I am a suspicious sort, and clicked on the link to make sure it worked.re: my previous post here: I guess quotes are never going to be fixed? Makes things very difficult in a technical forum!
- 23-Oct-2016 02:44 PM
- Forum: Using jQuery
Surprised there has been no announcement either in these forums or on the jQuery blog about this...Apparently, jQuery Foundation has morphed into (or been absorbed into newly-created... or something like that...) js.foundation. (I learned about the "apparent" equivalence only from a news article - you'd be hard-pressed to glean that from the official js.foundation website.)js.foundation has a broader vision, encompassing a good number of Javascript projects, which do include jQuery, jQuery Mobile, and jQuery UI. From the official website, it appears that the "jQuery" parts are being de-emphasized.I've read some discussion suggesting that jQuery is irrelevant today, as browsers have gradually taken-up support in areas that jQuery has been traditionally used for, and suggesting that today one should be writing to the Javascript APIs. (I think, though, that although browsers do now have close to 100% coverage of what jQuery does, jQuery is a LOT more convenient. And all those benchmarks that are being quoted need to be updated for 3.0.) And/or suggestions that more comprehensive frameworks (typically MVC) will provide for the gaps. I don't find that a very nice choice - between inconvenient-but-fast APIs, and a big, bloated framework.Any idea what impact this change in administration will have on jQuery, jQuery UI, and jQuery Mobile? Maybe JQUI and JQM are ideas whose time has come and went. But I think it would be a huge mistake to leave jQuery by the wayside. (The way JQM has been - encouraging official statements aside, it seems dead in the water.)It seems with deep-pocket sponsors (but hasn't jQuery always had apx. the same list of deep-pocket sponsors) there may be new funding, but at the same time, the foundation is taking on support of additional projects.Are we going to hear something official about how this all affects jQuery?"The JQuery Foundation is morphing into the JS Foundation to provide mentoring and technical governance for a multitude of JavaScript-based open source development projects.The JS Foundation is a project of the Linux Foundation and has backing from organizations, including IBM, Samsung, and Sauce Labs. It will take over current jQuery Foundation projects and add a few more, said Kris Borchers, JS Foundation executive director."- 21-Jul-2016 09:49 AM
- Forum: About the jQuery Forum
Quote highlighting has been broken for about a week.I've taken to start adding quotation marks manually, so that readers have some clue.At least the case for Chrome 51.0.2704.103- 12-Mar-2015 12:08 PM
- Forum: About the jQuery Forum
If you try to delete some very old private conversation, you cannot.You get a pink popup that says:(null)It seems the conversation has gone away, but a reference to the conversation has not, and cannot be removed.- So, I guess we've gotten another lovely Zoho update that has broken something in the editor again.It's some:Font Weirdness
- 04-Feb-2015 11:56 PM
- Forum: Developing jQuery Plugins
In a widget using jQuery UI Widget Factory, sometimes options can be set with data- attributes. It's common in jQuery Mobile.I don't think there is really any standard for this, though?In jquery.mobile.iscrollview, I let the user override options by setting a JSON string in the data-iscroll attribute in the HTML. e.g.:<div data-iscroll='{"scrollbars":false,"useTransform":true}'>I think that the use of a JSON string here is actually either unprecedented or at least uncommon. It's certainly not the way jQuery Mobile widgets typically set options using data attributes. JQM tends to use a hodgepodge of multiple ad-hoc data- attributes, which may or may not actually correspond to actual internal options, but I digress...( In jquery.mobile.scrollview ) I didn't give any consideration at all to passing options as a hash parameter to the widget constructor, because in JQM it isn't normal for the user of the widget ("end-developer") to initialize the widget themselves. (It's done for them in pagecreate - the widget is expected to supply a pagecreate binding). It seems to me now that perhaps they should be permitted to, but that in itself is really a different (JQM-specific) issue.Anyway, I've been working on jquery.iscroll , which is meant for jQuery, JQUI, or JQM. And, certainly when using just jQuery, it is quite common to write call to the constructor (factory function) in one's own JS code. And, of course, you can pass an options hash.Any suggestions as to which should override which, should the user provide both an options hash in the constructor, as well as options as a data- attribute or attributes?Merge the data- attributes into the constructor attributes? Or merge the constructor attributes into the data- attributes?I *think* the proper answer is that the constructor attributes should go first, and then any options supplied in the HTML as data- attributes should then be merged-in. After all, it is _create() which must read any data- options, and from the viewpoint of the developer, it is the constructor that starts the ball rolling. Make sense?But it's possible to merge it either way.BTW, just to drive developers a bit insane, but to also fully flesh-out the possible ways of initializing options, ( I like orthogonality) I do plan to also allow the developer to set individual options with individual data- options, in a more JQM-kind of way.That is, the options set using a JSON string above, might also be set like this:<div data-iscroll-scrollbars='false' data-iscroll-useTransform='true'>I want to make it easy for the developer to set options in the most natural way that makes sense for the particular project. Often, that might be in the HTML, where it self-documents how the widget might be expected to behave, when coming-across the widget in the HTML source. At least for the simple case where a few options are being set statically at initialization, and not being flippped-about later.iScroll doesn't particularly lend itself to messing with options once initialized, though I will try to support that to the extent possible. In jquery.mobile.iscrollview I deal with that fact by re-constructing the widget when calls are made to set an option or options. Yuk! iscroll5 is better at this, though, and quite a few options can be safely changed.Any comments on other issues I mentioned above are appreciated, but mainly I am looking right now for opinions on order of application of options supplied via constructor hash vs data- attributes.(BTW, Keith, just ordered your book which I hadn't known existed, and eagerly awaiting it's arrival!)- 09-Jan-2015 12:58 AM
- Forum: Developing jQuery Plugins
In a jQuery UI Widget Factory widget, is it considered "kosher" to leave option keys undefined? Or must every option key be defined?It would produce different results when you check an option that might have a boolean value. If the key is defined, then it will return false. If the key is not defined, it would return undefined. For a simple boolean test, it would not make any difference. But I do not know what code or common practice may lurk that might test for an explicit value of false.I suppose I just answered my own question - all of the keys should be defined, because you just don't know how the options object might be used by application code.I'm writing a new plugin to replace jquery.mobile.iscrollview, which is getting long in the tooth, and only supports iScroll4 (and that only through 4.2). I'm writing a more modular plugin that will target jQuery, jQuery UI, and jQuery Mobile and wrap IScroll5. (Will need widget.js for use with just jQuery.) It will also work more intimately with the iScroll5 code, patching it, for example, to register and trigger events through jQuery.So, it's basically a wrapper for iscroll5, which is not a jQuery plugin. It has it's own options object, which I reflect back to the widget (merging with additional options that only have meaning to the widget). But iscroll5 omits keys for many options that default to false. (iScroll4 did not do this.) So, I am trying to decide how much I need to massage the iScroll5 options.- How do you inspect Javascript objects, say, in console output?I thought I new the right answer - most browsers will show object values in console output by just passing the object.However, there is a fatal flaw - at least with Safari. The value shown is the CURRENT value of the object, NOT the value at the time it was logged! So, if the object was changed subsequent to logging, when you go to look at the log the object content will not be correct. The only time it can be guaranteed correct is if the debugger is paused immediately after the console.log() call.I've seen suggestions to use JSON.stringify() but that can't deal with cyclic data structures, which are pretty common on Javascript and jQuery.I've just tried something called jquery.inspect, but it has not been updated in 4 years. And it does rather more than I want - for example, it will dump the entire source of any functions in the object.What do you use if you want to log objects, without having to breakpoint? (If I have to breakpoint, I might as well just inspect in the browser tools, rather than logging.)
- 27-Oct-2014 07:12 PM
- Forum: jQuery Mobile
It's been obvious for some time that jsFiddle is not the best way to set-up jQuery Mobile demos. While it is generally an OK way to show a jQuery problem, it falls short for jQuery Mobile, because it is limited (except for "external resources") to a single CSS, HTML, and JS file. While you can include external resources, of course they can't be edited.As well, it's not easy or even possible in many cases to show the use of, say, a REST API. So, another "would be nice" would be the ability to proxy URLs to some other site, making it possible to demo access to an API without cross-domain issues.I'd like to be able to recommend an alternative instead of jsFiddle, and I'd like to solicit input.I'm aware of one site that seems promising, Plunker. (Note the spelling in the URL, though!)I haven't spent much time with it, but it does have one important feature needed to effectively demo/collaborate on jQuery Mobile - you can create and edit multiple files. And, so, it's possible to create multi-page demos without being forced to use a multi-page document.Please comment here if you have used Plunker, or if you have alternative suggestions!- jQuery.com was compromised around Sept 18, with traffic redirected to a site delivering malware, according to this report:http://www.net-security.org/malware_news.php?id=2869jQuery.com, the official website of the popular cross-platform JavaScript library of the same name, had been compromised and had been redirecting visitors to a website hosting the RIG exploit kit and, ultimately, delivering information-stealing malware.The report states that jQuery Foundation has acknowledge the exploit, and since removed the malware form the site.
- 17-Aug-2014 01:00 PM
- Forum: Using jQuery
A bit off topic, but I think a good place to ask...I find jsFiddle pretty limiting for demonstrating anything more than a simple, single document.- If the fiddle needs some assets - images, etc. sure you can include a complete URL, but then you are obligating yourself to host those forever or else the fiddle becomes useless to others.- There is no ability to create a multi-document Fiddle.- There is no way to demonstrate most Ajax, because of cross-domain concerns.When I started thinking about this, my first thought was some open-source product similar to jsFiddle that one can install on ones own server. But then you are obligating yourself to hosting this forever...So, I think a better solution is a smarter third-party service.Asset storage should not be an issue. Storage is cheap today. Maybe the site would have to charge some small fee (like GitHub). I think it could work if they only charge a fee if you want to create some large number of demos, and then anyone can always use and modify for free. So, anyone can create a small number of demos, for a fee you can create a large number, and everybody can always view and modify your demos.Multi-page is a matter of organizing multiple "fiddles" into a single "project" so should be easily done.The last part is the ability for the site to proxy Ajax requests (or maybe other requests) to other sites, to simulate single-site Ajax. Now, here, if you provide some Ajax back-end, yes, now you are obligating yourself... But in many cases, that might be a back-end that exists anyway. (Imagine any site that has a public API showing developers how to use it using this tool.) As well, many public API services exist that represent good stand-ins for generic Ajax problems. (maybe need some permission and/or carefully read terms of service...)Does anything like this exist?(No, I don't want to write one!)- I have a need for a simple SVG editor or "editor framework" that we can use in a native mobile touchscreen app that uses Rhodes (Rails-like server in the app programmed in Ruby, WebView UI using jQuery Mobile).We currently use a simple native signature-capture extension, that only allows very simple bitmap drawing with no edit. That extension is no longer available to us in the latest Rhodes, and anyway it's a bit too basic for our needs. So, we've temporarily replaced it with sketch.js: http://intridea.github.io/sketch.js/ One attraction is that it's super-tiny and pretty easy to understand. (We fixed one bug and tossed out some code we didn't need and discovered it was needlessly redrawing like crazy - which - amazingly - didn't seem to have impacted performance...)While this is simplistic and still just bitmap/canvas, it's way more functional than the signature-capture extension!Now I'm looking for a more complete, vector-based solution for the longer term. Besides making stand-alone drawings, we'd also like to use it for marking-up photographs (editor overlays the photo), and so SVG is a more attractive solution than canvas/bitmap.It would be nice if it's a jQuery plugin or is compatible with jQuery. We'll be using it with jQuery Mobile, but I'm sure I can deal with any JQM-realted issues, so it does not have to be jQuery Mobile-specific.svg-edit:Is impressive, under current development (despite the code.google.com hosting! ;) ), but seems not very well adapted to touch, has way more features than we need, and comes with it's own GUI.And there's part of the rub. I want more than a library, and less than a complete graphics editor. We want to be able to use our own minimal UI. (In the case of phones, just drop-down menus from a header bar., on pads a combination of a single-line palette and drop-down menus.)I'd like it to take care of the necessary UI bits for manipulating objects - selection, drawing "handles" for sizing/rotation/drag, handling drag interactions, etc. But I don't want it to supply any kind of "tool palette" (or if it has one, it should be possible to disable), since we will supply that ourselves. I'd like it to have functions we can call to put to use particular typical drawing tools - freehand line, straight line, square, circle, polygon - and then it should take care of the touch interaction. Not much more than that is needed.I'd like it to build on top of a well-supported, current SVG (and/or canvas) graphics library - e.g. GSAP, d3, Raphael, Snap.I'm thinking Raphael is a bit long in the tooth and supports a bunch of browsers we don't have to support.I find Snap particular intriguing, as it seems purely SVG-oriented, it's newish, backed by Adobe. But haven't been able to find a single example of an interactive editor (other than very specialized ones - like for creating a particular type of diagram) implemented in it. I'm sure it has the capability, but not sure I want to put the effort into writing the editor from scratch!Suggestions?
- I had an odd situation in jQuery Mobile (but JQM is incidental, so posting here). I bound to a vmousedown
event on a page. The purpose is to dismiss any menu shown when the user touches any part of the page.I also have my own "fast button" implementation that uses jQuery Mobile vclick event. It delegates vmousedown, vmouseup, vclick and click to the page.From the latter, I call event.stopPropagation(); The problem is, this prevents the bound vmousedown from being triggered. It's not absolutely clear from the documentation, but I gather that this will prevent propagation to parents that are bound. But it does not prevent propagation to parents if they delegate the same element. (StopImmediatePropagation() would prevent even delegated callbacks.)I solve the problem by changing the "dismissal" callback from binding to delegation. But I am using a selector of *, and wonder if this is a bad idea. (Efficiency?)$page.on('vmousedown', '*', function (event) {var $target = $(event.target);var exempt = $target.closest(closeMenuExemptions);var $saveMenu = $page.find('.save_menu, .save_menu_settings');if ( !exempt.length || !$saveMenu.hasClass('visible') ) {$menus.trigger('close-menu');}});$page.on('vmousedown vmouseup vclick click', '.turbo-btn', function (event) {event.preventDefault();event.stopPropagation();...});This is not a high-frequency event, so don't have to worry too much about execution time unless it exceeds human reaction time. But this seems an odd delegation, and I don't recall seeing this used anywhere else.(Yes, I realize that now that it's a delegation I can change: var $target = $(this); )- 31-Jan-2014 03:51 PM
- Forum: Developing jQuery Mobile
Welcome!The "Developing jQuery Mobile" forum is here for discussions about the development of jQuery Mobile.If you want to discuss using jQuery Mobile to develop your own website, webapp, or native application, you should post on the 'jQuery Mobile" forum. It's the appropriate place for that discussion, and your post will get greater exposure.If you want to report a bug or suggest a feature to the jQuery Mobile team, neither of these forums is the place to do so. The jQuery Mobile developers do not monitor either of these forums for bug reports or feature suggestions.If you wish to file a bug report or make a feature request, you should review the submission requirements here:and then file an Issue on github. You will need to establish a github account if you are not already a github member.Feel free, however, to discuss proposed bug reports here before submission. Realize, though, that github Issues are the only way to insure that your bug report or feature request will be considered.Appropriate topics for this forum:- I'd like to contribute to the jQuery Mobile project. How can I do so?- I'm writing a plugin for jQuery Mobile. What are best practices?- I've forked the jQuery Mobile project and would like to make some modifications for my own use. I'd like some advice on internal details.- I've got a great idea for a new feature. I'd like to discuss it with others before formally submitting it via a github Issue.- I have a question about the coding standards for the jQuery Mobile project, because I'd like to make a contribution to the project.- I think I've found a bug, and I think I have a solution, but I'm not sure. I'd like to discuss it before making a pull request with my changes on github.- The documentation is unclear on some topic, and I'd like to contribute a change. I'd like to discuss it before making an official submission on github.Other issues should be directed to the "jQuery Mobile" forum, which is a self-help forum for developers who use jQuery Mobile. If you have a question or problem with using jQuery Mobile, need to know how to do something that you can't figure out, want some advice on how best to accomplish some task using jQuery Mobile, etc. those issues should be discussed on the "jQuery Mobile" forum.Please note that participants and moderators as well in both forums are individuals volunteering their time, and in most cases have no direct affiliation with the jQuery Mobile project. I often see posts such as "you need to fix this bug", etc. There is no "you" here - only "us". Please keep this in mind when posting to either forum.- I have a native application using Rhodes and jQuery Mobile (but not a JQM-specific question). Rhodes runs a web server in the device. Some JS code sends some simple notifications to the internal web server using $.post(). It simply posts to a URL with no data:$.post("/app/Settings/" + (enable ? "enable" : "disable") + "_form_assistant");These XHRs seem to accumulate. Using Safari Web Inspector (remote-inspecting iPhone simulator or device), they seem to accumulate endlessly. I haven't verified if there is some limit beyond which this will not grow, however.As well, XHRs that are the result of $.mobile.changePage()calls accumulate as well. But the simple posts seem like an easier situation to diagnose.later on, after some navigation:Is this something to be concerned about? Does this represent a memory leak? Or is it just Safari helpfully keeping these around (hopefully, just for a while) for inspection?
- I copied this from a response of mine. I think it deserves it's own post. Here's a little experiment you can to do to understand why using IDs is a problem in jQuery Mobile.I haven't put this in a jsFiddle, etc, because I want to keep it as dead-simple as possible. I want people to create a file locally and experiment with their browser console. (Or, if you prefer, add console.log statements.)------Try the following simple example. You only need a simple page, and jQuery (don't need jQuery Mobile) and your browser's Javascript console for test:Now, go to your Javascript console, and type in this:$("#a")How many items do you see in the result list? Did you expect to see two? Do you see two? What item(s) do you see?Hint: you will see ONE. Which one you see is browser-dependent. In fact, with some browsers, you might not even see any, because this is a invalid condition. What should the browser do with an invalid condition?EVERYBODY READING THIS FORUM SHOULD TRY THIS EXPERIMENT.Then, forgot about using IDs. Or, at least, duplicating them. Keep in mind that JQM always loads at least two pages in the DOM at once, at least if you ever change pages. The old page and the new page. Also, the first page visited always stays in the document. If you are making a website, the user might enter the site from any page, so you really need to make sure you never duplicate an ID on *any* page.If you want to use IDs in your project, have fun making sure you never duplicate one in any pair of pages that might be loaded together. (This might include the *same* page if you ever do a same-page transition...) It's a lot easier not to ever use IDs.For extra credit, try this in the console:$("[id=a]")This time, you will get a list of two elements.So, should you still use IDs, and use this construct instead of $("#a")?Well, you can do that if you are simply stubborn. It is one of the slowest queries - much slower than a class query. You lose any benefit from using IDs.
Extra-extra credit: extend the experiment. Load jQuery Mobile as well, and experiment with IDs duplicated on two or more pages. What happens now?- 28-May-2013 08:49 PM
- Forum: jQuery Mobile
I'd like to hear some opinions on the proper use of jQuery Mobile ns option and jqmData() function and :jqmData selector.
As I understand it, if you set the global option ns, then whatever string you put there will be required to be prepended to all data-attributes.
So, if you set ns to foo-, then, instead of data-role="page", you will have to write data-foo-role="page".
The idea behind this is that it can get you out of situations where the JQM data-attributes conflict with those of some other library you are using.
The question is, where you can use this and where you cannot.
As a plugin author, I think I need to make sure that my plugin plays along with this. But in what context? Only when dealing with widget initialization and options that can be specified in HTML? What about internal data that is stored in the DOM? (e.g. there is no data- attribute in the HTML - only data stored there by the widget.)
When a plugin stores data in the DOM,
- Should it use jqmData()?
- Or should it use .data(), possibly with it's own namespacing? So, for example, should jquery.mobile.iscrollview use .data() with it's own namespace of, perhaps, iscroll-, or follow the JQM convention of no namespace but with an option, and in either case, provide the ability to globally set a namespace for the widget?
What about applications? If your application stores data in the DOM, should you be using jqmData(), or just .data(), again, with the possibility of your own namespacing?
I think the latter is fairly clear. Applications should use their own namespace for data items that they uniquely store. You have no way of knowing what new data- attributes JQM will use in the future. So, you should prefix some string to insure that there can never be a conflict, even if you don't have some conflict between JQM and some other library. So, you probably should consistently use a little helper function like myAppData() in code, and use your namespace in any data- attributes.
On the other hand, if your application references standard jQuery Mobile data- attributes (as data, not as attributes) then you should always use jqmData(), in case you might someday make us of the global ns option.
The reason I ask is that the method for getting a real reference to a widget function has changed in jQuery Mobile 1.3 widget factory.
It used to work like this:
var iscrollview = $page.find(".iscroll-wrapper").jqmData("iscrollview");
But, now with 1.3, it works like this:
var iscrollview = $page.find(".iscroll-wrapper").jqmData("mobileIscrollview");
So, the widget factory has now added a mobile prefix to the key, and capitalized the widget name.
(I'd thought at first that jqmData() wasn't usable for this any more. I was wrong. I just didn't know to look for the right key. Note that jqmData() is missing one functionality of .data() - you cannot call it without parameters to retrieve all of the data for a node.)
Now, if you use ns, setting it, say, it "jqm" this becomes, for example:
jqmData("jqm-mobileIscrollview"), which seems redundant.- Apparently, 1.3 was declared Final this morning. (Though there's some ambiguity on the website, with it referred to as both "Final" and "RC1".)
At the same time, the documentation has switched over to a new format. There is now separate API documentation, which is very rough:
http://api.jquerymobile.com/
Now the demo is just a demo/examples: (no it isn't, see "update" below...)
http://view.jquerymobile.com/1.3.0/#&ui-state=dialog&ui-state=dialog
While the old documentation was hard to navigate, because it couldn't decide if it was a demo or a tutorial or API documentation, and didn't have any kind of index, table of contents, it was vastly more usable than the current documentation.
The tutorial material in the old docs seems to have fallen between the cracks, and now there is nothing to tell us how to initially set-up a JQM project (save for very basic CSS/JS loading setup on the "download" page) nor anything that explains basic principles, such as the page navigation model.
As a practical matter, you will need to refer to the 1.2 documentation if you are just starting out:
http://jquerymobile.com/demos/1.2.0/
In particular, the "Pages and Dialogs" section, which contains a great deal of tutorial/intro material seems missing.
Update: the tutorial material is there, but not very accessible. You will need to click around on links in the Introduction section of the new demos, and guess which ones might be important to read. Alas, there still is not a real separation between demo and documentation, except that there is now a separate API documentation. They've "improved" the tutorial material by burying it behind inline links, where at least before it was nicely organized in a menu.
Basic getting-started info (like what to put in <head> to link to CSS and JS) can be found by going to the Introduction, scroll down to "Pages & Dialogs", then click on the "page" link in the first paragraph of that section.
Not sure what has become of the "old format" docs for 1.3.
IMO, both of the new documents hurt my eyes. It's why I'm wearing sunglasses. ;)
(It's not quite so bad on a Retina device like iPad. On most desktop displays, the font is way too thin and hard to read.)- 20-Nov-2012 11:31 AM
- Forum: jQuery Mobile
I am of the opinion that multi-page documents should almost never be used in jQuery Mobile. Yet, multi-page documents, and ways to "fix" multi-page document linkage to other pages seems to be an ongoing issue with a high level of activity on this forum.
I'd like to keep any discussion of "why" separate. If you are curious, you can find plenty of discussion on that topic elsewhere in this forum.
I am curious, though, as to exactly why so many developers seem to be using multi-page documents. It's not something that is overly-emphasized or pushed in the documentation. I wouldn't come away from the docs thinking "I really ought to use multi-page documents". In fact, a close read would suggest it's a bad idea, unless you are developing a really, really small site. The usage of multi-page documents seems way out of proportion to their intended use or their treatment in the documentation.
I am guessing that developers are getting some bad advice from somewhere. And I'd like to find out where.
I might be wrong, and it's simply a case of developers using the feature "because it is there" or "because it sounded cool".
Please be as specific as possible. If you developed a site, or part of a site, using a multi-page document (or multi-page documents), where did you get the idea that you should do that? Was the something in particular that you read in the docs? A sample or tutorial? When did the lightbulb first come on, "I ought to use a multi-page document"?- 03-Nov-2012 03:56 PM
- Forum: jQuery Mobile
I have a particular page (a map page) that is extensively modified on pagebeforeshow. (probably irrelevant to this problem.) When I reload this page from the browser refresh button, the URL briefly appears with ui-state="dialog" in the URL. The that part is removed from the URL, and the page transitions to whatever page appeared prior to the map page.
The page is linked-to with a parameter in the URL. (?location="me")
That is:
Page A index.html, for example
user navigates to map page (map/index.html?location="me")
user refreshes with browser refresh
Map is drawn, and URL briefly shows &ui-state="dialog" at the end.
Page transitions to Page A (i.e. where-ever the user was prior to transition to maps page)
I do have one dialog page in my site, but in this case it was never visited. The map page is not a dialog - does not have data-role="dialog".
I have another page (todo page) that is similarly linked with parameters in the URL, but this doesn't occur on that page.
The one difference between the two is that the todo page is linked-to from JS code using $.mobile.changePage(), and the parameters are supplied in the data option, while the map page is linked using an <a> tag.
Is JQM assuming that a page that is linked with parameters in the URL is a dialog?- 30-Oct-2012 05:00 PM
- Forum: jQuery Mobile
Is anybody else experiencing strangeness with padding and scrollbars in Dialogs? See the attached screenshot.If I put a data-role="content" <div> surrounding the content, the dialog is shortened and I get a scrollbar. If I leve out the content div the dialog appears correcty. I didn't set a page height for the dialog. Any idea why it is short?As well, unless I add padding to the page <div>, the top of the dialog is cut-off. This is regardless of whether or not I use a data-role="content" section.The two seem that they might be related, since the dimensions seem similar.The first screenshot is with a content div.The second screenshot is without a content div.The third screenshot is without a content div, and with 20px of padding added to the top.
- A question that often comes up is how to pass parameters to some dynamic page. I'm using a rather loose definition of "dynamic page". By that I mean a page that has some content creation done in Javascript (whether or not the page was originally provided by a server).
Typically, parameters are passed in the URL as a query string. Then you have to parse the query string, and it also looks ugly in the URL bar of desktop browsers. Why go to all that trouble?
Such pages usually have a pagebeforeshow event, and this is where content is typically added by Javascript code. It so happens that pagebeforeshow tells you which page was "previous", and so you have access to any data in the previous page.
A good example is when transferring to a dialog page from some detail page. The detail page has some details about some "thing". You have some dialog that needs to do something with that "thing". If you've stored some aspects of the "thing" in data- attributes in previous page, then you can easily transfer them to the new page:- $(document).on("pagebeforeshow", ".my-dialog", function(event, data) {
- var $page = $(this),
- $prevPage = data.prevPage;
- $page.jqmData("section", $prevPage.jqmData("section"));
- $page.jqmData("item", $prevPage.jqmData("item"));
- });
Of course, you can access anything within the previous page, not just jqmData, and, as well, you can stuff the data you extract anywhere you'd like in the new page or the new page's jQuery object. In many cases, it may be sufficient to simply store the reference to the previous page, and then code for the new page can reference anything on the previous page at it's leisure.
In my particular case, I had a popup that didn't work-out as a popup. (Because it has a text entry box, and text entry boxes in popups are pretty broken on iOS.) So, I had to re-do it as a dialog. Since a popup is a part of the page that it pops-up from, the popup code had access to data stored in the page. When I changed it to a dialog, now it is a page on it's own, and doesn't have this data. But by transferring the data as above, I didn't have to re-write code originally meant for the popup.- 20-Oct-2012 02:33 PM
- Forum: jQuery Mobile
It's pretty well-known that Safari (both desktop and mobile) has some issues with transitions that can be helped by using a CSS trick ("null 3D transform") to "hint" the browser that hardware acceleration is wanted on certain elements. This can be useful to improve page transitions and scrolling.
The symptom, for example, with scrolling is that scrolling will be choppy until the user has scrolled all the way to the bottom. Once they have, then scrolling is smooth. The browser has cached the content as the user scrolled. This can be remedied by judiciously applying a null 3D-transform, and then the elements will be cached in advance. You get smooth scrolling (but at the expense of greater up-front setup time.)
Other browsers don't require this (because they handle pre-caching automatically) and, in fact, it can actually degrade performance.
The problem is coming up with a suitable browser test, so that this CSS can be applied only when needed.
Does anyone know of a reliable way to test this "feature" in code? That would be ideal. But it also might be rather complex. Try to measure the "stuttering"? Ugh!
Absent a feature test, then we have to use a user-agent test. But thanks to browser makers, this is a mess! Everybody is spoofing everybody else.
"Safari" is certainly not a reliable test. In fact, in some cases, it isn't even a part of the user-agent string on legitimate Safari browsers. (It's omitted for UIWebView and full-screen.)
I thought AppleWebKit might be good, but, no, Chrome spoofs AppleWebKit if running on OSX!
You can then exclude "Chrome", but then who ELSE is spoofing AppleWebKit? (But it it really IS something built on AppleWebKit, then I want a positive test.)
Is there some specific feature that can distinguish real Apple Webkit from some other WebKit pretending to be Apple WebKit?
My concern here is specifically the need for hardware acceleration hinting. For now, I am just excluding Chrome, since the biggest issue seems to be that this unnecessarily slows-down Android browsers.
© 2013 jQuery Foundation
Sponsored by
and others.