Planet Drupal

It seems like we are always trying to stay one step ahead of proposed web standards in an attempt to future-proof our sites and take advantage of emerging technologies. One such proposed standard that is exciting – yet difficult to implement at times in existing frameworks – is the new responsive PICTURE element.

We all know and love the good ol’ IMG element that has been around since the dawn of the web, but in today’s world of mobile devices and varying bandwidth to these devices, the one-size-fits-all IMG tag doesn’t quite cut it. There are several polyfill solutions out there that leverage Javascript to serve up multiple images based on device size, but now you’re piling more code on top of an already bandwidth-limited website. This is where the proposed PICTURE element comes into play, allowing a page to declare a single PICTURE element and multiple images to serve up based on CSS3 media queries. Problem solved, right?

Not so fast… The element is still in the “unofficial draft” state, so it has limited support (some advance versions of newer browsers might have it, but nothing in production to date). However, there are some solutions out there that will serve up the element if the browser supports it, but fallback to the polyfill solution if not. One that is turning out to be incredibly helpful is the combination of the Picture and Breakpoints modules to help future-proof D7 sites that implement responsive themes like Omega.

How does it work? Pretty simple – (once you get the hang of it, after setting a few up):

1. Install the Breakpoints and Picture modules.
2. Define breakpoints for your images (and additionally core image styles for those breakpoints if you don’t already have some you’d like to leverage).
3. Define breakpoint groups that will be used by the Picture module to associate breakpoints to image styles.
4. Map image styles to breakpoints in each group.
5. Under Manage Display for an image field, select the Picture field formatter instead of Image and select the picture group (aka breakpoint group) you want to use for this field.  Other settings are similar to the Image field formatter.
6. Check out your new images!

What you should see on a browser that does not support the PICTURE element yet is a collection of IMG and SCRIPT tags to manage the polyfills leveraging weblinc’s picture library. On a browser that supports the element, you will see a PICTURE element generated using the CSS3 media queries defined by the Breakpoints module and the images being served up from image style paths as mapped by the Picture module. The beauty of this solution in Drupal is that you can apply it to existing image fields with minimal impact since the implementation is encapsulated in a field formatter, with only wrapper-level CSS changes being your biggest hurdle.

Large breakpoint example

Medium breakpoint example

Small breakpoint example

For a more detailed tutorial on setting up and leveraging these incredibly useful modules, check out the tutorial on drupal.org.

Get a high speed and large scope overview of jQuery and it's use within the Drupal ecosystem. Ideal for themers or developers looking to take that next step into the client side. Equal time is spent exploring pure client-side and server-side applications of the AJAX and javascript framework in Drupal.

Every small finding is worth sharing. This blog post is no except for this fact.

Google Plus One Linkedin Share Button Tweet Widget Facebook Like

I've needed to build a regular expression filter for a view I'm working on, so I'm sharing the code here because it might be helpful to other people as well. My specific case is that I am building a Blocks administration VBO.

read more

Lately I’ve been quite busy working on my first Drupal 7 theme that is getting ready to launch. The idea stemmed from my perception that there are not enough responsive themes out there for Drupal.

The following blog post was written by Donna Benjamin of Kattekrab.net, and is also read by Donna Benjamin. You can find the original article which contains all of the links mentioned in the post, at kattekrab.net/twigs-bones-themes-stones. Enjoy!

Tags:  Audioblog, planet-drupal

You can either get on the Drupal 8 bus now, or get run over by it later.

It's true. Drupal 8 is coming, and it will be big. Not just lines of code (that too), but big in the sense that Drupal 8 changes more of Drupal than any major release in the last 10 years. The adoption of so many 3rd party components (from Symfony and otherwise) is only part of that picture. That offers challenges for many, but also enormous opportunity. Drupal 8 will allow Drupal to expand into new types of application and new markets, which is a great thing for those who make their living off of Drupal. But where do you get started with learning about Drupal 8?

At DrupalCon Portland, that's where!

There are many sessions slated for Portland at both DrupalCon and at Symfony Live that deal with Drupal 8, either directly or indirectly. Below is my recommended hitlist for Portland for those wanting to get the lowdown on Drupal 8.

What, you're not already signed up? There's still time! Go register for either DrupalCon or Symfony Live, and be sure to get a Combo Ticket so that you are able to attend both conferences as well as Web Visions! (The combo ticket is the same price either way.)

read more

Hi! Welcome to the very first Audioblog sponsored by Modules Unraveled. This is Brian Lewis, and if you're listening to this, it probably means that you prefer to digest your content audibly, rather than reading long blog posts. Well, I'm the same way, and I kept coming across blog posts that I wouldn't normally read, but something about them would catch my eye, and I'd dive in. Almost without fail, I'd come away glad I did decide to read the post. The problem is, I don't have time to read everything that I think looks interesting. But I do have a lot of time to listen to things in my car.

Tags:  Audioblog, planet-drupal

There are a myriad of books about pretty much every open-source editor/IDE on the market today, but it seems like most people try to avoid writing about commercial IDEs. There has long been a need for a good book about commercial IDEs, and PhpStorm in particular. Today, I have been invited to review Włodzimierz Gajda's new book, Instant PhpStorm Starter.

As a 1/4 Mexican, I feel gifted with a birthday on Cinco de Mayo

(for you gringos, that's May 5th)

Even better to share a photo of Drupal creator and curator Dries Buytaert in a sombrero (while a student at Ghent University, where Drupal originated)

photo via Forest Mars

Try my vegetarian recipes:Bean burritos y arroz con frijolesPro Bowl GuacamoleThis remains the 10th most popular post on my blog, up from 8709 views a year ago to 15,037 now

We tested Views in Drupal 8 at BADCamp 2012 and this uncovered a large number of usability issues. Since then we have been hard at work resolving them.

We resolved over 20 identified usability issues. Most of the issues revolve around the following fundamental issues:

• What can views do? People are overwhelmed by the plethora of options and often don't quickly find the right approach.
• Handler listings are overwhelming, and this causes people to miss the right handler.
• People occasionally miss the "save" button, making them move off the page before saving.
• On the detail level a lot of copywriting is overly descriptive, this makes people miss important help text.

Major

We have a number of major issues that we encountered. Most of these revolve around workflow and scan ability of listing pages:

• Users feel overwhelmed by handler listings
• Users miss "save" button and can't distinguish "editable" and "preview" areas
• Add “place block in region’ to the Views wizard to help workflow

Moderate

These issues will distract but not keep people from using the Views interface:

• The views UI should display "All Displays" option only when there are more 1 displays.
• In the Views UI, the interaction pattern of “All displays”/ “Override this display” is confusing
• Remove the "More" area from the bottom of handler configuration
• "Create a label" should be off by default, with an opt-in for style plugins

Normal

Finally, we have dozens of minor issues that often require little coding but have quite an impact on making individual forms better:
Edit + "Field" Views (table, grid, etc.)
Revamp descriptions of items in handler listings
Views UI gives no indication that you are editing a disabled view
Title setting in views UI does not indicate when the title might be overridden
The views UI should display "All Displays" option only when there are more 1 displays.
Let users set the block instance title for Views blocks in the Block UI
Add some settings on the block display to allow overrides on the block instance configuration
Provide helpful editing links on "admin/structure/block" for different blocks (menu, views etc.)

We have been working hard at solving many of these issues starting with the copywriting. However we are currently running up against a few issues that will need some serious help in the PHP department.

You can track views issues by following the tags Usability + VDC.

We look forward to your help, feel free to drop by #durpal-usability or #drupal-vdc if you have any questions.

Guest blogger Robb Neumann and trainer Steve "Denver Dataman" Kessler share their observations on March's Global Training Day in Denver, Colorado. Don't miss the link to Steve's free training resources toward the end of the post!

Personal blog tags: Drupal Global Training Dayguest blog

Knowledge Language English Steps to reproduce really do help in issue summariesCathy Theys05/03/2013 - 15:57

I was working with new contributors tonight. They had worked on 2-4 issues before. They wanted to test a patch in dealing with a Drupal 8 multilingual issue. Sure, testing d8mi issues is a bit more tricky than regular core issues. Because a module usually needs to be enabled first, like Language or Content translation. But I think the lessons learned from this experience apply to any core issue.

Steps to reproduce in a comment are nice. Putting them in the issue summary is even better.

This issue had Steps to reproduce in comment 3 out of 25, which is really great. Some issues do not have any steps to reproduce. Even though this issue had Steps to reproduce, I saw these two contributors spend 15 minutes wondering how to get to the settings page that needed testing. And then they wondered how to get the translation bits to show there. Once I pointed out the comment that had the steps, they were on their way. One did the testing... and the other updated the issue summary and put the Steps to reproduce right there in the issue summary. They wanted to make sure that the next person to come across the issue had an easier time testing than they did.

In this episode, we have Greg Dunlap (heyrocker) join Addi to talk about being a Drupal 8 initiative lead, not from the perspective of the software, but as someone who needs to pay rent. We talk about Greg's efforts to raise funding for his work as the Drupal 8 Configuration Management Initiative (CMI) lead, why he needed to go knocking on doors, and what that means going forward. What is money's role in a sustainable future for Drupal core development?

• Working with Entities in Drupal 7 Series
• PSD to Theme Workshop at Portland
• Artifact Conference
• Greg's Drupal.org Contact Form
• Greg's Twitter Feed

Sustainable Drupal core development requires money

Many people have asked how COD, otherwise known as the Conference Organizing Distribution, is going. Currently its a community supported project, with lots of great new features going into the 7.x branch!

This weekend, Acquia was at Linuxfest Northwest (LFNW, http://www.linuxfestnorthwest.org), a regional conference of about 1500 open source enthusiasts, and COD was running behind the scenes to help make the fest run as smoothly as possible.

"I woke up this morning and all my shrimps was dead and gone. Someone's been fishing in my pond…" -- Robert Johnson

A few days ago I woke up to the latest version of D8 core, only to find that "everything" in my freshly ported fully operational D8 module was broken. While getting to the root course, I couldn't help grumbling the above words by the late great bluesman in his wonderful Dead Shrimp Blues. Replace "shrimps" by "hooks" and think of that "someone" as the D8 core team and you have a wonderful analogy.

One by one the hard-working core team are killing off our trusted hooks, replacing them by equivalent Symfony classes and their magic annotations. Your implementations won't be called any more. Say sayonara to your hooks.

It's all for the greater good, of course.
But initially the mind boggled.

To get a grip and make my module work again, I went back to basics. I wrote a minimum code base to programmatically create a field with associated widget and formatter. It has become my "field+widget starter pack" when implementing fields in D8.

The commented code is attached as a fully functional module and we posted it to drupal.org, as well.

At the time of writing, hooks still required to create the basics of a field are:

• hook_field_schema() implementation in the /modules/modulename.install file
• hook_field_info() and hook_field_is_empty() implementations in the /modules/modulename.module file

All the widget and formatter hooks have been retired. Here's what you'll have to add to re-instate the D7 functionality provided by your widget and formatter hook implementations.
In the /modules directory you need to create the following files, each holding a class and its essential annotations.

• modulename/lib/Drupal/modulename/Type/ModuleNameItem.php
• modulename/lib/Drupal/modulename/Plugin/field/widget/ModuleNameDefaultWidget.php
• modulename/lib/Drupal/modulename/Plugin/field/formatter/ModuleNameDefaultFormatter.php

Tips to avoid the Dead Hook Blues:
o Don't have superfluous trailing comma's in your annotations -- the effect is calamitous.
o Implement hook_field_is_empty() correctly or you may find that submitted form values don't save!
o Once you've mastered the starter pack, have a look at the source of core's Telephone and Link modules for a step up in complexity and in becoming a D8 pro!

File under:  Planet Drupal Attachment  geostore.tgz

We are as excited as everyone about heading to Portland in a few short weeks.  I'm convinced it is going to be one of the most significant DrupalCons yet.

However, I was a bit disappointed when I learned that so many of our favorite tools have no session coverage at all.  These aren't some niche modules, either.  These modules have been used in almost all of our projects in the last few years.

Search API, Apache Solr, or "search" at all!

At first, I searched for "search api" on the DrupalCon Portland website hoping to find a session or two on the most powerful module system since Views.  Nothing accepted.  

I thought there was not even one proposed session on Search API after using their seach page for the proposed sessions, but then I found Beginners Guide to Solr Search and Search API and Solr and Search API: Get Better Results Now via other means.  There might be something wrong with their search pages.  

There are at least 8 sessions I found that have something to do with Apache Solr that were rejected.

Then, with a bad feeling about it, I searched for "search".  Only 2 accepted sessions even mention the word search: one is called "Case Studies and Optimizing Content" and the other is about the Multilingual system.  The only accepted session that mentions "solr" was a mapping session!

There is literally not one official session that focuses on the topic of search!  This is almost mind-boggling, since for years, search has been one of Drupal's strong points.

By the way, in case you were wondering, search_api has 17,358 reported installs. apachesolr has 12,675. 

Migrate

The next big shocker was a search for the word "migrate".  We have used migrate.module for almost every project we've worked on for the last few years, and find it indispensible tool in moving data into Drupal.

Migrate.module has 18,220 reported installs, and was used and sponsored by some of the biggest Drupal sites in the world, like MarthaStewart, Examiner, and the Economist.

There isn't one accepted session that mentions the word "migrate". Three sessions mention the word "migration", one of them is about moving to Drupal 8, and there is no mention of the migrate.module in any of them.  There was only one session that I could find that specifically mentioned migrate module, Managing Big Data with Drupal.

Aegir

There were three sessions proposed on our favorite Drupal hosting management too, Aegir.  None were accepted. (One does mention aegir in passing.

There are no good statistics on reported installs for aegir, because hostmaster doesn't enable update.module by default which is required to report statistics back to drupal.org.  There have, however, been 9,165 downloads since they started counting downloads.

Aegir is the only tool of its kind in the Drupal universe. It's popularity is growing all the time. It's a shame that it has gotten so little coverage, at the upcoming DrupalCon and ones in the past.

MongoDB

8 proposed sessions with something to do with MongoDB.  0 accepted. 

Making Lemonade

I can't speak to the selection process, and I know it is an incredible challenge to sort through the hundreds and hundreds of submissions the Drupal Association gets for DrupalCon. 

At least now I know what BOF's I am going to propose.  So if you are going to DrupalCon and are interested in these systems, keep an eye out for the BOF schedule.

We will make sure that these topics get covered, somewhere!

Tags: Planet DrupalDrupalCon

For those of you attending Drupalcon this month - you have good taste! Show exactly how good it is by joining us for a special event to benefit the trust of Aaron Winborn, a long time Drupal contributor who has been fighting ALS for some time now.

read more

The Omega Drupal 7 Base Theme is a highly configurable HTML5/960 grid base theme that uses built-in media queries to make the site responsive. Each zone, or group of regions, can be configured for content-driven layouts that reformat depending on the device’s screen size.

Mediacurrent recently partnered with Acquia to record this webinar. In it Kendall explains the theory behind Omega's mobile-first approach, helping achieve best results whether on desktop, tablet or smartphone.

Topics covered:

Thank you for attending my webinar - Building Rich Internet Apps with Drupal & HTML5. I really appreciate the support and the amount of interest in this topic that you guys have shown! This blog post is dedicated to answering the questions that were asked during the webinar; unfortunately I couldn't get to all the questions but please feel free to leave any more in the comments and perhaps there will be a Part 2 of this Q&A.

Q1: What type of applications would you recommend to develop using these technologies together?

Applications like the one I’ve shown in the demo are the perfect example. And for good reason, I have shown a reader app, not because I want to promote Kobo, but to demonstrate the effectiveness of HTML5, CSS3, and JavaScript (which is what Sproutcore is about) in creating a web-app. A reader app ties in with the concept of Hybrid Model perfectly. The Kobo server not only serves data for this HTML5 Reader app but for their native iOS, and Android app, which follows our model – the server-side is separated from the client-side.

Facebook apps are good candidates to use these technologies. Facebook gives you a Canvas to work with, which essentially loads your website into an iframe, however, performance is not that great when working with traditional-style websites. For every page request, Facebook has to load the webpage first, and then show it to the user. Facebook is acting as a middle-man. So if you can eliminate the need for Facebook to fetch pages then your app will perform so much better.

In a nutshell, if you foresee that your application is going to have a content repository with workflows and needs to be highly interactive then a JavaScript HTML5 UI coupled with Drupal is best choice.

Q2: How could we introduce and streamline this hybrid model into a development environment?

As mentioned before the Hybrid Model demands a deeper consideration in deciding on how to separate business logics or requirements for client-side and server-side. It‘s architecture that is not too well adopted for websites, but for web applications it’s second nature. To start off, Business Analyst will need to gather as many requirements as possible so that the Solution Architect or Lead Developer can draw the line between what business requirements can be accomplished on client-side and what on server-side. Once that is established, we should focus our attention to designing the JSON REST API. Front-end and Back-end developers must agree upon the API before any work can begin. In this case, both front-end and back-end can work in parallel.

Q3: What do we do with the themes and templates on Drupal and is the UI going to be on the same server or somewhere else?

Since external users are not interacting with Drupal directly, we don’t need Drupal to do any themes and templates. Now our JavaScript HTML5 UI is external to Drupal, meaning it is not a Drupal theme. We may view the UI as a standalone app that talks to Drupal. So the UI doesn’t need to be living on the same server, in fact, performance-wise, the UI would ideally be hosted somewhere like on a CDN (Content Delivery Network). However, it can be on the same server with Drupal just not within the Drupal directory.

Q4: Can you please define assets briefly?

In our context, “assets” refer to anything that enriches the UI, or adds “life” to it. These are, but not limited to: images, video and audio files, Flash (SWF) objects, CSS, and JavaScripts.

Q5: This might get answered later on... but I thought one of the great strengths of Drupal was its theming! If Drupal becomes SaaS, where is the theming motor going to come from?

I agree that one of the great strengths of Drupal, besides content managing, is the theming/template engine. When we drop that part from Drupal and attach our external UI crafted from the HTML5 and JavaScript, the template motor is coming from the JavaScript framework that we are using. I highly recommend using a strong framework such as Backbone.JS, Sproutcore, or Ext JS. For the theme, you may want to combine the templates with a CSS framework like Compass and/or Foundation 4.

Q6: It seems like "thickening" the client is a good choice for sites that are frequently used. What are some best practices for sites that may be visited infrequently and aren't likely to create app interest in users/viewers?

As you’ve termed it “thickening” the client is good for sites that are frequently used, but that’s not all. Websites that want to respond well to users, say, the user clicks a button or a menu pops up or the page would flip and content is already there, and with no wait time between the interactions, thickening the client is a reasonable thing to do.

Now for sites that are infrequently visited, the best practices for deciding whether or not to go the web-app route:

1. If your current websites are mainly displaying static content, don’t require a lot of user interaction and it’s fine to have users waiting for page load, then stick with traditional websites.
2. Benchmark your website; find out what is your general audience. Some users have no problem with plain-old websites, but some users love fancy and quick-n-snappy UI in websites.
3. If you foresee or plan for your current website to have increased functionalities and it’s going to become like an application, this is the great opportunity to “thicken” the client.

 

Q7: What happened to "don't store state" in the browser? Is this old-fashioned advice that's not needed anymore?

The statement, “don’t store state” in the browser, is typically referring to the stateless model that the World Wide Web and the HTTP protocol is based upon. Because state is not preserved in the underlying protocol, it would make sense to not have the browser remember the state. Now that we are moving toward web-apps and HTML5 is meant to accelerate the process, stateless design is becoming outdated. If you look closely at the HTML5 features list, we have Local Storage, WebSQL, IndexedDB, and Application Cache, these essentially break the stateless design pattern. Now, let’s take a step back and look at how we implement a website before HTML5, we use cookies/sessions and URL to allow the browser to be state-full. In a sense, we’ve already broken the stateless design pattern. One thing to remember is that the HTTP protocol is always stateless, so we are always communicating in a stateless world. What we’ve done is altered how the app behaves but not the communication.

Q8: Drupal seems to be using Backbone.JS how does this compare with Sproutcore?

In a nutshell, Sproutcore and Backbone work in the same way. Sproutcore is heavily on the client-side MVC structure while Backbone is a bit more relaxed. Backbone is super light weight in comparison to Sproutcore. One reason that Sproutcore is more suited for web-app is the Statechart feature which only not organizes views but also drives the application. Statecharts can be seen as the Finite State Machine in Computer Science. Backbone.JS and Underscore.JS are being added to core because they need to provide the foundation for the inline editing feature in the coming release of Drupal 8, and because Drupal 8 is headed toward SaaS, Backbone.JS would really benefit Drupal.

Q9: Is there a recommended IDE for Sproutcore?

Any IDE that can keep track of JavaScript functions and files is great. Sublime Text 2 is a good choice because you will run into cases where you must search through files to look for function names. I personally use Komodo just because I do PHP and JavaScript.

Q10: How much PHP programming is involved in your Hybrid Solution based on Drupal? Can you implement serverside business logic in JavaScript? Can Sproutcore be used server-side?

PHP programming would be the same amount as it is when creating your own modules. It really depends on the business logics you planned to implement on the server. However, if all the business logics can be achieved with contributed modules, then no code writing is needed.

Implementing server-side business logic in JavaScript is not a good idea because of security issues. Keep in mind that JavaScript is not safe; anyone can download the script and look at it. So it is not wise to implement server-side logic there. So in the Hybrid Model, I advised that the client-side only implement that logic which is closely related to display, for that reason.

Can Sproutcore be used on server-side? No. Sproutcore is for the client, if you want server-side JS, use Node.JS instead.

Q11: How can you access the MySQL DB in Drupal? Do you need PHP to do so or can JavaScript on the server be used for this?

Drupal database abstraction layer provides the API to read/write to the MySQL DB. Your JavaScript client will call to the JSON REST services Drupal provides to get data, and Drupal using the DB abstraction layer will handle getting data from the DB.

Q12: What is the preferred IDE for PHP/Drupal?

I use Komodo personally.

Q13: Using the hybrid model, how does one configure the Drupal appearance / theme aspects? What are the ways in which I have to tailor Drupal so that it acts as a content repository and not a UI driver?

In the Hybrid Model, we have dropped the appearance/theme portion in Drupal for external users, meaning visitors will interact with the JavaScript HTML5 UI instead, and only administers would log into Drupal directly. Essentially, if you do a fresh install of Drupal it is already a content repository. The remaining piece is to provide a JSON REST API for the UI to connect to Drupal. Say, we have 'example.com/' pointing to your UI, and 'admin.example.com/' is your Drupal instance, you can create a landing page to allow Admin to login.

Q14: What type of app is good for HTML5 only?

This is a very open-ended question as any app can benefit from HTML5. There's not really an app that is only good for HTML5. So if your app utilized at least 2 or 3 HTML5 components then it is a good app for HTML5. Games, for example, use the Canvas component and WebGL (on Chrome) to render graphics. Reader applications, like Kobo, use Local Storage, Application Cache, History, and IndexedDB.

Q15: Do I have to develop the web-app from start to finish in Drupal to be able to use all of the Drupal features or can I just incorporate it into my existing website?

Honestly, it is best to design the web-app from start to finish in Drupal and in JavaScript UI, because it’s much better to layout where client-side and server-side business logic would belong in the beginning. But you can start anywhere in between, all you have to do is build that JSON API and make sure that API hooks into all the Drupal features you need, so when the UI calls, everything is there.

Q16: Also, Is it a must to use PHP MVC or framework to be able to use it?

No, the Hybrid Model is really an architectural layout to structure your application. You don’t need to limit yourself to MVC frameworks on server-side and client-side. In fact, Drupal is not a MVC framework, it is still a PAC, and yet I recommend using Drupal for server-side.

Q17: If a web-app/website has some interactive content as well as some more static content, can Drupal serve up static pages while the client-side JS serves up dynamic content? (a hybrid-hybrid model?)

Yes. You can do that, as long as you have set aside which URL points to the web-app and Drupal, they can work simultaneously. For example, Drupal site only serves static node pages, and all your Views are outputting JSON instead. Calling those Views will split out JSON and not the actual page.

Q18: It looks like SproutCore uses Ruby and RubyGems somehow - can you please explain how that fits with JavaScript?

Sproutcore is JavaScript. Sproutcore uses Ruby and RubyGems to build and compile your JavaScripts into an app package.

Q19: How would you benefit from Drupal-HTML5-CSS3-JS vs.Node.JS-HTML5-CSS3-JS? i.e. What is the benefit of doing server side Drupal versus 100% JS using Node.JS?

Drupal gives you the benefits of having a CMS, and Node.JS doesn’t. It only gives you the structure to build an application. The question is why build a CMS yourself when you already have it, and all you really need to do is add the JSON REST API component. There is no real benefit in the underlying technology, in terms of, mixture of PHP with JS and pure 100% JS. Even if you implement 100% JS on both sides, you still need to build REST component for the client and server to communicate.

Thanks for reading along; I hope this Q&A has proved helpful! 

Blog Tags: html5drupalDrupal 6Drupal 7servicesViewsjsonrest apirestsproutcorebackbone.jsarchitectureback-endfront-enddevelopmentmaintenancecostSection: Cross-PlatformDrupalHTML5Mobile ApplicationsAndroidBlackBerryiOSiPadiPhoneWindow MobileMobility SolutionsPhoneGapSproutCore