I want to give user the ability to proceed in a common action for many selected (with checkboxes) items that are displayed in a table with pagination.
I wonder how am I going to keep track of the selected items of a previous table page while user navigates to other table pages via pagination links.
I use kaminari for pagination.
Any ideas?
An approach you could use is a hidden field or just a javascript variable that you update with some javascript whenever the user selects/de-selects an item in the table.
If your page navigation links use AJAX to only update your table and nav links, your page will still contain the hidden field or variable of the selected items. On a table update you will also have to set the selected state on your table items based on what is selected in your hidden field or variable.
Yeah, its not pretty.
You may want to consider some of the client side MV* frameworks for SPA (Single Page Applications) as things can and do get messy pretty quickly with ad-hoc javascript.
The MV* frameworks I am referring to are Backbone, Ember, Angular, Knockout, Batman and so on. Your app essentially becomes a single minified javascript asset, a single minified stylesheet, plus images and client/server is just AJAX/JSON api. These framework provide structure for your client side code and support binding of views into object state and synchronisation to the server.
It is this shift in client side architecture and native mobile apps that has seen more minimalist server side frameworks like Sinatra rise in popularity as frameworks like Rails (and yes I mean Rails 4.0) no longer provides the "rails" or conventions for developing modern web and mobile applications.
Checkout TodoMVC for a comparison of MV* client frameworks and choose one that fits your style and requirements. My pragmatic (and opinionated) choice after a considered look at all the major ones is Backbone.js + Backbone.Marionette + Coffeescript because you simply don't get painted into a corner. No disrespect intended to others.
My advice with MV* frameworks is:
be very careful with opinionated frameworks that use declarative view templates or have limited or no ability to put logic in templates, or don't support nested/sub templates. Without such features, view composition is a challenge and rendering views that vary based on say user role, or plan/subscription or have a hierarchical structure becomes difficult if not impossible. I've considered the declarative template ideology and I like the theory but reality bites.
be careful how much control you have over synchronisation with the server. You often need to "side load" related objects and the last thing you want is the old 1 + N SQL query problem being manifested as a 1 + N JSON query problem!
If you are using any form then you can go for multistep form . you can get the idea from
http://railscasts.com/episodes/217-multistep-forms
But please make sure you need to store the form object in session in this approach so if you have let say 500 fields in your form then there is a change of cookie over flow. please take a look on your application and then decide.
Related
I'm building a large hierarchical web application and I need some help deciding on some best practices with leveraging MVC.
The application will have tabs at the top which control a sub page, and a query pane (off to the side).
There will be two templates for query panes, each used by different sub-pages. The sub-pages will be based on the selected tab with settings derived from the query panes.
Clicking on tabs or updating the query pane will update the sub-page section without refreshing the page.
I'm a bit new to MVC and what I don't quite understand is how I can leverage MVC methodologies to help me manage the web application's state (which consists of the selected tab, query options, and other page-specific options).
Currently I'm planning on initially setting up a model which stores the client state parameters (default values, or values obtained from a DB), and using it to load the page, consisting of several partial views. When anything is changed (tab/query/etc), the view will call a corresponding controller, passing back model parameters via post (I'm assuming there's no way to store session-specific client state models on the server-side?).
My question is:
Am I doing it right?
If not, what am I missing; and specifically, is there a way to store these session-specific state models server side so they don't have to be passed back to the server during every single page transaction?
If I understood everything you need Its a SPA (Single Page Application). This will provide a magic user experience, without full page reload, and low data traffic. But, requireds some MVVM framework (AngularJS, KnockoutJs, etc) and a lot of JavaScript coding. But the result is amazing. The guy behind this in MVC is John Papa, take a look in everything on his blog and you will win.
John Papa Blog
Hopes Its Help you
I am just starting a project and the wireframes are ready. But looking at the wireframes it seems that the primary goal was to reduce the number of pages and to include maximum functionality in to a single page.
Taking an example of an organization, the top portion of the page will show the organization details, below that at the left we have an division structure as a tree view, clicking on a division will populate the employee list on the right as a table, and when you click on an employee it will populate the employee details below.
Current wireframe looks something like this:
End user is happy as they can see the entire functionality on a single page and doesn't need to navigate to another page.
But this design reminds me the screen of some old desktop application and I feel that this page is unnecessarily complex- I want to split this in to multiple pages (at least in to three). Also, I am using MVC 4 and splitting this in to multiple pages will definitely help me to reduce the complexities during implementation.
But before arriving at any conclusion and raising any concern, I would like to know what you guys think. Some articles related to User experience are also welcome.
Here's what I think.
Whether the design above is 'right' depends on the target audience and the type of work / business process they need to carry out. There may be a strong business argument for being able to see all the information (org details, divisions, employees and employee details) on one page. It is not unusual to see a lot of information displayed in a page with a lot of interactivity - users expectations have increased because of consumer sites such as Gmail.
The users might find it frustrating if it was broken out into different pages.
To put it another way, I don't think there is a valid technical justification for making the designer change the UI above to split it into different pages.
You would be able to build the UI above in MVC as a single page web application. You will probably need to implement a lot of controller actions to support ajax calls. You're almost certainly going to end up using a lot of JQuery and you are probably also going to end up with a significant amount of JavaScript to write. Also, you'll need to make sure the designer has made good decisions around the sizing of the page. Is it going to be fixed width or dynamic for instance? You'll need to emit well structured HTML in order to achieve that solely using CSS (which I would strongly advise you do).
I'm working on building a mobile application for a client using jQuery Mobile. The question I have is fairly basic and non-technical:
The application can have three different types of users, all with a different menu layout. Some users will have access to some parts of the system that other users will not.
My question is- should I hardcode the menu system in the index.html file or should I dynamically create it when they log in? I'm assuming that there would be a slight performance gain by hardcoding the menu and then just choosing which #page to display as opposed to requiring an ajax call...but keeping the menu builder on the server side processing keeps us more agile if need to change the menu after deployment.
Deep apologies if this has already been asked. Thanks for your help!
Build your pages dynamically. On jQuery mobile, a lot of stuff will be repeated and if you want to respect the DRY principle and want to create easily maintainable code, do it dynamically.
Also, by doing this on a mobile application you will reduce the loading times : instead of loading 3 pages you'll only load one, wich can be crucial in mobile developpement.
Hard coding is bad if it can be done dynamically do it because it saves over head and produces nicer code that is easier maintainable.
If you want to change the menu in the future you can just edit the source of information instead of going through all your code having tons of messy if and else statements saying if this person is logged in don't show this option but show this one etc.
I am a little ashamed for asking so many questions, but I really want to learn.
In Sipke's blog a webshop is created. There is one specific question that boggles my mind when trying to do something similar.
Let me spell out the basic requirements:
User registration form and login, etc. This one is covered by the blog and it works nice.
Creating product parts and so on. This one is covered and no problem there.
Ordering by filling in an order form and making the payment. See down
Having the order page maintainable by customer. See down.
Viewing your own orders and their status. See down
Maintaining customers and orders from backend system. This one is covered by the blog and I need to do some work there yet.
As for items regarding creating orders and viewing your orders. I have followed the approach for creating records and using standard MVC controllers. But then I encountered problems:
Menu for orders page. This I had to do manually after installing the module.
The order page itself. I had to create the view including title and so on. But I can imagine a customer wanting the order page on another menu and with a different title. And maybe add even some own content to the ordering page. This I couldn't achieve by using standard MVC approach. So maybe I am using the wrong approach here. So I was thinking about using contentparts for creating an order and displaying them and using the drivers and handlers for that. But before I go down that road and refactor everything I want to know if that is the right approach. A downside could be that once the module follows that route it can then not so easily be reused with customers that have other cms's capable of hosting an MVC3 module.
So when to use drivers, handlers and contentparts and when to use standard controllers and views.
You should use Drivers and Parts (with Handlers if needed) when you want to create functionality for content items. E.g. if you want to display a custom media with all products, you could create a Part (together with its Driver, etc.) to handle that. Read the docs on Parts.
If the functionality is not tied to content items the most possibly you want to use the standard MVC toolbox, it's fine. Look at the built-in modules how they do that. E.g. the Blog module uses controllers and views to show the admin UI, but has parts to enhance the functionality of for example the Blog content type.
To make things more complicated you can employ ad-hoc content items to build a page that you'd normally do with simple views, but that's an advanced topic :-).
At my work we have an existing ASP.NET web application and are duplicating some of the pages & functionality to better target our mobile users. We are using the jQuery Mobile framework and ASP.NET Web Forms to do this.
Since this is going to target the mobile web I would like it to be fast & lightweight which means turning off the view state, loading lists on demand (when opened), and I'd like to eliminate post backs (annoying & doesn't work well w/ jQuery Mobile). Of course this means doing a lot more work client side.
One of the pages is a bit complex, it allows the user to log items, however it's layout is fully customizable. Prior to logging the user is able to define what fields they wish to track. Some of these fields are system designated but others are created by the user. They can choose from a checkbox, dropdown list, date box, radio button, text box, or list box. Some fields are also tied to other fields meaning the user can select an item in one drop down list which then reloads another drop down list with the associated data. The user also has the ability to add an unlimited amount of additional fields (drop down lists) while on the actual page used to log their item. Once the page is filled out by the user the selected fields values are saved back to the server in a database table.
I figured this would be a great chance to use a JS Framework like Knockout.js, the dependency tracking would come in great for trying to keep things synced up & reload lists as needed based on selections made in other lists. Even though I am a bit concerned about how it would handle the fact that the form layout is dynamic & can be modified once displayed (anyone know if it can handle this?).
So I started looking around for jQuery Mobile & Knockout.js and apparently there are issues, workarounds, limitations, etc. w/ the two working together and I saw the same thing w/ Backbone.js
Does anyone have any suggestions w/ this? Is it worth the hassle to try and use a JS Framework of some sort w/ jQuery Mobile? Can a JS Framework handle the form I am trying to create w/o me having to jump through hoops? Am I better off looking for some sort of dependency tracking plugin and just using that and if so can you suggest any that will wire up to my model object & other controls on the page & work correctly w/ jQuery Mobile?
Overall, knockout should be a good fit for your requirements. I'm currently using it an MVC3 applicaiton to do similar things to what you are describing.
As for your complex page, this is all doable.
Your highly customizable form. This is one area where knockout really shines. It allows a separation be how data is displayed and the data itself. This can be done with different data-bindings types and you can add your own customized bindings. I actually do this a lot when creating a form and experimenting with what the test control type is.
Dynamic Layout - With Knockout there is no direct connection between the DOM and the data. Knockout's data-bind statements allow you to connect new content to it's data at run time. This currently works well in my current app.
For your requirement about unlimited adds, take a look at the Contacts Editor Demo. It seems to have features to do the unlimited requirements
In general with knockout, once I went to using ajax to handle all my data requirements, things became greatly simplified.
As far as using knockout with jQuery mobile, knockout is now part of the new releases of Asp.Net Mvc4, developer preview. It is my understanding that knockout is key to MVC's design on building single page web offline where the data is stored locally, then dynamically added to the displayed page. Cannot find link right know, but I'll keep looking and post edit later.
Hope this helps out. Also, checkout the links on knockoutjs.net home page. -