I render a page from the server (an admin intranet app) then I want jQuery UI it and keep things consistent with the selected jquery ui theme.
Take for example buttons
<button class="do-something">Logout</button>
The jQuery UI documentation say that one should not apply ui-state-default and 37 other CSS classes manually (at server render time), but on a initial render one should call $(selector).button() where selector maybe just 'button' or '.nice-button' etc..
This seems a bit smelly to me but I suppose the fine grain control make sense given its not intending to be as high-level as ExtJS or Sproutcore etc..
Then I thought what about an icon button I'd thought <button class="do-something ui-icon-arrow-e">Logout</button> when calling .button() it would check for presence of such class and render accordingly. However it seems one has to do button(icons { pri: 'blah'}}). Yikes.
Am I approaching it wrong? it seems like a code smell here mixing a lot JavaScript statements related purely to rendering outside the html? I haven't even considered stuff injected later via ajax etc..
Then I want to have a panel with heading like an accordion, I ended up having to dump about 93 CSS classes onto a div and h3 to get things consistent. I then created my own extension jQuery $ fn extension .crmPanel() which was basically parent.addClass 43 and parent.children('h3:first').addClass() 53 times. Seems messy
How are people using jQuery UI in intranet apps, or are you just purely using the element and doing the others bit manually?
(note divide any quantitative figures related to number of CSS classes by 4)
jQuery UI CSS Framework gives a nice base for some of the UI elements such as Tabs, Dialogs etc. We have found it lacking and therefore would usually add another CSS file to enhance standard CSS with some CSS3 effects, add typography and Grid System.
The result looks like this:
http://agiletoolkit.org/intro/engage
and although it's still based on jQuery UI theme it does not look like that.
When it comes to buttons, we sometimes use the jQuery but sometimes use CSS. In that particular example, CSS is used, in other cases (selector).button() is used:
http://codepad.agiletoolkit.org/buttonpushing.html?b=devel
In regards to panels and layouts, compared to ExtJS, jQuery does almost nothing to help out. Besides, I'm not fan of JS-controlled layouts since they are slow and jittery. I think CSS is a way to go.
Related
wondering how to use BoilerplateJS with Jquery Mobile. Perticulary when it comes to manage url and how to deal with the which is created automatically.
Thanks.
I haven't seen any examples out there so have been doing exactly that myself but haven't yet completed the exercise. You need to add the jQuery Mobile references into the top level index.html and then modify the html (structure, tags) to something that JQM will like to render. You also need to ensure the views correctly trigger enhancement of content changes. It seems straight forward enough although styling might yet be a gotcha so I can't yet say whether it's trivial-but-time-consuming or going to be a mess.
I have many different pages in jquery mobile which utilizing different data-icon, some custom and some are built in, is there a way to preload all of these data-icons, because now its like when a new page loads with a new icon for the first time, it will be blank for a second before it is loaded. which is annoying.
I am using phonegap+backbone+jquery mobile. so its heavy java stuff instead of pure html.
Have you thought about using image sprites? This way, all icons will be cached on the first page load. It's a little extra css upfront, but I think it'd be really worth it!
I'm doing an app with jQuery Mobile and Angular.js. Cause we have some issues using both libs, exists an adapter that do "teh job".
So I'm trying using routeProvider to route my pages. But I still can't render pages using this.
Here plunker if u can help show me the way.
http://plnkr.co/edit/DNGiT83csWMmfYnHXOop
Thanks in advance!
I ran into a similar problem and maybe what I learned might help you. It comes down to the differences in the way angular and jquery go from one page/section to another (routing).
First, the basics: angular routes by inserting a chunk of html into your view, then on whatever click/action/etc, removing that html from the view and adding a new chunk of html. Essentially you're on the same page all the time; it's just the included html is changing. In contrast, think of jqm as loading up all the html into the same page, with those html chunks as divs. Instead of removing html chunks and replacing them (via routing), it's just turning divs off and on. (There are multi-page jqm apps but SPAs really highlight the differences.)
My suggestion is to pick which set of features you really want: angular's minimalistic loading (only as you need it), or jqm's flashy transitions and other built-in features. If you've got a massive app with a lot of data on every page, you might want to bypass jqm and use angular alone, and see what you can do with angular's new animate functions. It'll mean you'll need to build (via CSS or javascript) duplicates of the jqm features -- and from what I've seen, you can get close but it won't quite be as pleasantly streamlined as jqm.
If the jqm built-in features are what you really want, then skip using angular's routing. It'll just introduce all kinds of complications, anyway. Set up your pages using jqm's pattern, and use angular only where you're dealing with data.
What I've found works best is to treat it like it's a jqm app overall, and only add angular into the sections where you need it. After all, you don't have to add ng-app at the html line; you can add it into a single div as needed. Since jqm is happiest as a system-wide kind of thing, while angular is just fine being confined to pieces within a system, so far I've found jqm-whole and angular-parts to be the simplest way to get the best of both worlds.
I'm on the verge of starting a new web application that is likely to have need for both standard, simple dropdowns as well as more feature-rich autocomplete controls for longer lists of values, better type ahead behavior, etc. I'm planning on using the jQuery UI Autocomplete widget along with some combobox behavior as detailed here:
http://jqueryui.com/demos/autocomplete/#combobox
My concern is that "out of the box" the Autocomplete widget looks very different than a standard control. Since is not easy to skin/style, I'm hoping to adjust the Autocomplete to look & feel as close to the as possible, except in the cases where the increased functionality justifies a different L&F.
What is the best way to go about reskinning the Autocomplete to look more like a ? Has this already been done somewhere? Should I use jQuery UI theming? Other options?
The autocomplete control already uses the jQuery UI theming :)
Change the style with the dropdown in the upper right of that page you linked here to see.
Those are the default themes available. but you can of course tweak the theme yourself. All jQuery UI widgets conform to this theming scheme. They provide a tool you can customize the theme with as well, called ThemeRoller. You'll see autocomplete on the right in ThemeRoller, it will be styled live as you make changes to the theme.
I want to have two different jQuery UI accordion menus on the same page, but I want them to have different themes. Is this possible?
Absolutely. The jQuery UI CSS Framework has a robust and complete theming solution. Just give your accordions separate CSS classes - jQuery UI classes are semantic in nature - and off you go! Let me know if you'd like an example.
EDIT: There are many different ways to do this, depending on what your needs are. See the bottom part of this page for more information on how to use theme-ing with the accordion
According to the article Using Multiple jQuery UI Themes on a Single Page from the Filament Group, it is possible to provide a CSS Scope when a theme is downloaded that will allow you to specify use of alternate themes on a single page. There is also a link to a demo page.
Disclaimer: I have not tried doing this myself, but it does look promising.