From time to time I have to work on projects where I have old versions of libraries, like jQuery, and I can't upgrade them. Yet, I need some features of libraries I like to use, like Bootstrap. This time, I needed a simple wait dialog that would show up, then go away when I needed it to. I'm working with jQuery 1.4.4 and jQueryUI is just too much for what I'm doing.
So, I found a great article on the web for a simple CSS positioned modal dialog.
http://blog.raventools.com/create-a-modal-dialog-using-css-and-javascript/
And my version is below. All I really changed is some styling, added a variable for content, which I'm setting statically, and have the styles inline instead of in a separate style sheet. This is a quick and dirty fix for a dying project. I've done a better version with bootstrap/angular but that's a different post :)
Tuesday, July 22, 2014
Monday, June 30, 2014
MVC - Saving Files AND Json Model
When posting files in MVC using AJAX, Microsoft gives us a great tool, the Request.Files collection. However, when passing files via ajax, MVC ignores your json model that you pass as well. You can see the way around this in the code snippets below.
And in our javascript, using jQuery's ajax() method...
I add the json model to the FormData collection. Once that's done, I can pull it from the Request.Form[] Name Value collection when it posts to the server.
And in our javascript, using jQuery's ajax() method...
I add the json model to the FormData collection. Once that's done, I can pull it from the Request.Form[] Name Value collection when it posts to the server.
WebApi and OData - Without Entity Framework
OData is pretty nice, all said. Makes displaying data in a grid way easier. Microsoft has done some pretty cool things with WebAPI, gotten rid of the last bits of weirdness that remain in MVC (imo). However, their odata implementation adds more typical MS weirdness...
While most oData parameters just "work" and apply directly to your IQueryable, unfortunately $inlinecount isn't one of them.
Fortunately there's a pretty easy workaround.
Add WebApi and oData using NuGet.
Do this to your method.
The key to this is returning the OData PageResult. It's pretty neat that MS' oData implementation will just work on your IQueryable, without modification. It's just that WebAPI won't return a PageResult when it sees the $inlinecount parameter, like it will when you use an oData controller. My issue with the oData controller is that it forces you into exposing your entire model for each object in your graph. I'm not trying to expose all of my data, I'm just trying to get an easy oData endpoint to feed my sites. Rarely do I need to expose my entire object graph to the user, and those queries are way too heavy. I also don't want a lot of JS baggage by filtering and selecting only the properties I need. This solution works much better for me.
While most oData parameters just "work" and apply directly to your IQueryable, unfortunately $inlinecount isn't one of them.
Fortunately there's a pretty easy workaround.
Add WebApi and oData using NuGet.
Do this to your method.
The key to this is returning the OData PageResult. It's pretty neat that MS' oData implementation will just work on your IQueryable, without modification. It's just that WebAPI won't return a PageResult when it sees the $inlinecount parameter, like it will when you use an oData controller. My issue with the oData controller is that it forces you into exposing your entire model for each object in your graph. I'm not trying to expose all of my data, I'm just trying to get an easy oData endpoint to feed my sites. Rarely do I need to expose my entire object graph to the user, and those queries are way too heavy. I also don't want a lot of JS baggage by filtering and selecting only the properties I need. This solution works much better for me.
Tuesday, June 17, 2014
File and JSON Post in MVC
It seems strange to me that MVC doesn't handle posting a file and a model at the same time from AJAX by default. It'd be great if you could just send your data and "poof" it's all there for you. It doesn't seem to be, so I'll put down what I've found that works for me.
You create a javascript FormData object. Add your model (with property "model") and your file('s). Post as normal.
In your action method, remove any model parameter you had. You won't need it. Just look at the Request.Form["model"] and deserialize your json. Get your files in the Request.Form collection.
You create a javascript FormData object. Add your model (with property "model") and your file('s). Post as normal.
In your action method, remove any model parameter you had. You won't need it. Just look at the Request.Form["model"] and deserialize your json. Get your files in the Request.Form collection.
Tuesday, September 10, 2013
MVC 4 Project File Structure
I've been trying to think of a clean way to structure web app folders that keeps things simple and removes clutter.Typically in most web apps, all scripts are thrown willy-nilly into the "Scripts" folder. You end up with tons of js files with no real structure to them. And, think about it... How often do you modify the jQuery source? How about Bootstrap? Modernizr?
Right... Why have them in the most visible place in the folder? The files you modify regularly should be easy to get to. The files that are never modified should be tucked away, only changed when upgrading or removing. We want the most often modified files visible and easily navigated. I came up with the following.
Which works well for a typical non-MS website... However, with MVC, it's not standard practice to have the js for a view/partial in the folder where it resides. Also, you can install and upgrade client libraries using NuGet. Unfortunately you don't get a choice as to where these files are installed. So, you're stuck with a "Content" and "Scripts" folder, and unless you modify your routing, you can't put script files in view folders.
To try and keep upgrade functionality but remove clutter, I came up with this compromise...
The key features here are the Content/App folder, the Scripts/App folder, and the ViewScripts folder. By having special subfolders in Content and Scripts, I get away from having files that I modify from being lost in the files I install through NuGet. Typically these files are modified infrequently anyway, but at least this way they're easy to find. How many times have you found derelict css files lost in the Content folder mess? This helps with that.
The biggest benefit comes from moving view specific files to the ViewScripts folder. This folder follows the directory structure of our Views folder. For views/partials that need a specific javascript folder, you merely create one in the ViewScripts folder. Easy to find, easy to navigate. I'm sure there are a million ways to lay out the directory structure of an MVC app. This one works for me. I'm mainly posting this as a personal reference :)
Right... Why have them in the most visible place in the folder? The files you modify regularly should be easy to get to. The files that are never modified should be tucked away, only changed when upgrading or removing. We want the most often modified files visible and easily navigated. I came up with the following.
Generic Folder Structure
- common
- js
- jQuery
- knockout
- bootstrap
- css
- jQuery
- knockout
- bootstrap
- images
- Any file structure that makes sense. Most image resources for js libraries are contained in their respective folders inside of the css folder
- fx (or framework)
- app.js (global settings specific to this application)
- fx.js (common functions that are a part of the company framework code)
- Any other files that are specific to the company and are used across the site.
- views
- account
- login.html
- login.js
- hearing
- hearingSummary.html
- hearingSummary.js
- hearingResult.html
- hearingResult.js
- hearings.html
- hearings.js
- common
- any control templates that are used elsewhere in the application.
- index.html
- index.js
Which works well for a typical non-MS website... However, with MVC, it's not standard practice to have the js for a view/partial in the folder where it resides. Also, you can install and upgrade client libraries using NuGet. Unfortunately you don't get a choice as to where these files are installed. So, you're stuck with a "Content" and "Scripts" folder, and unless you modify your routing, you can't put script files in view folders.
To try and keep upgrade functionality but remove clutter, I came up with this compromise...
- [] Content
- [] App
- [] img
- any images specific to the application
- site.css
- [] kendo
- [] font
- [] Controllers
- [] Models
- [] Scripts
- [] App
- fx.js
- util.js
- etc...
- [] kendo
- bootstrap.js
- jquery.js
- knockout.js
- etc...
- [] Views
- [] ViewScripts
- [] Blog
- index.js
- editBlog.js
- newBlog.js
- [] Shared
- layout.js
- somePartial.js
- anotherPartial.js
- etc...
- [] Security
- login.js
- users.js
- etc...
The key features here are the Content/App folder, the Scripts/App folder, and the ViewScripts folder. By having special subfolders in Content and Scripts, I get away from having files that I modify from being lost in the files I install through NuGet. Typically these files are modified infrequently anyway, but at least this way they're easy to find. How many times have you found derelict css files lost in the Content folder mess? This helps with that.
The biggest benefit comes from moving view specific files to the ViewScripts folder. This folder follows the directory structure of our Views folder. For views/partials that need a specific javascript folder, you merely create one in the ViewScripts folder. Easy to find, easy to navigate. I'm sure there are a million ways to lay out the directory structure of an MVC app. This one works for me. I'm mainly posting this as a personal reference :)
Wednesday, August 21, 2013
Javascript Phone Number Knockout Binding
Hey, all...
Over the years, I must have written a dozen phone number textboxes. Unfortunately I never save the code. I get to play with Knockoutjs at my new job so I figured I'd give the number textbox another shot.
Over the years, I must have written a dozen phone number textboxes. Unfortunately I never save the code. I get to play with Knockoutjs at my new job so I figured I'd give the number textbox another shot.
ko.bindingHandlers.phoneNumber = { formatNumber: function (box) { var box = $(box); var value = box.data("value"); if (value.length <= 10) { value = value.replace(/(\d\d\d)(\d\d\d)(\d\d\d\d)/, '($1) $2-$3'); } else { value = box.data("value").replace(/(\d\d\d)(\d\d\d)(\d\d\d\d)(\d+)/, '($1) $2-$3 x$4'); } $(box).val(value); }, init: function (element, valueAccessor, allBindingsAccessor, viewModel, bindingContext) { var _this = ko.bindingHandlers.phoneNumber; var textbox = $(element); //function formatNumber(box) { //} textbox.keydown(function (e) { // allow cut/copy/paste if (e.ctrlKey && (e.which === 67 || e.which === 86|| e.which === 88)) { return; } // allow delete and backspace if (e.which === 8 || e.which === 46) { return; } // Ensure that a number was pushed if (e.shiftKey || !((e.which >= 48 && e.which <= 57) || (e.which >= 96 && e.which <= 105))) { e.preventDefault(); } }); textbox.focusin(function (e) { var value = textbox.data("value") || ""; textbox.val(value); }); textbox.focusout(function (e) { var value = textbox.val().replace(/[^0-9]+/g, ''); textbox.data("value", value); _this.formatNumber(this); valueAccessor()(value); }); }, update: function (element, valueAccessor, allBindingsAccessor, viewModel, bindingContext) { var _this = ko.bindingHandlers.phoneNumber; var textbox = $(element); var value = valueAccessor()().replace(/[^0-9]+/g, ''); textbox.data("value", value); _this.formatNumber(textbox); } }
Tuesday, March 19, 2013
Paychex and Horrible Web Applications
Our company recently chose Paychex as our HR portal, benefits management and payroll company. I've gotten paystubs from Paychex before, and thought our move might be a good one. Was I ever wrong.
To view my HR tools, like W2 info, paystubs, Direct Deposit I go to one site. This site takes a username, password and a company ID.
It uses ASP.Net, probably 2.0. When I view the page in Chrome, everything is disabled by default. I have to refresh the page in order to interact with it. The entire site is riddled with slow postbacks, often when choosing a dropdown (instead of a less obtrusive update panel). Despite its looks and poor performance, most of the site actually works, just keep clicking. You might have to click places that make no sense. Some of this is easier in IE, but not much.
To view and enter time and request time off, you go to another site. This site takes a username, a password, and a different company ID. I'm sure this is done for security. (wat).
This site has a completely different look and feel, yet done in that ever-so-quaint ASP.Net 2.0 fashion, again using whole page postbacks to give it that "web 1.1" feel. Navigation here is atrocious. You can "clock in" on the first page, but as salary, I want to manage my time all in one shot. (Don't get me started on why we're having to report our time for each day). There's a different section where you can do this. It uses what looks like a pageable repeater. No styling on it. Just dragged and dropped into the editor, there ya go.
Well, you can select a time type from a dropdown. Of course, changing this dropdown causes a full page postback. Once you enter time and submit, you can't change it. And, of course there is no validation (server or client) so entering 80 hours for one day is perfectly fine.
There's ANOTHER section you have to go to in order to edit time. And you don't "edit" it, you delete it for that day and re-enter.
Well, Paychex has created a "revolutionary" "new" way to manage this! MyPaychex.com! This has a more streamlined look. If you look past the javascript error dialogs that show in IE as soon as you log in.
Trying to register is a complete pain, as changing options forces a postback that of course clears any text you entered before the postback happened.
You have to bind the other accounts you have with this one, as all this site is, is a tab container that holds iframes to the other websites.
Yeah... So Paychex... IMO you need to redo your web infrastructure. And be willing to pay for new technology done right.
To view my HR tools, like W2 info, paystubs, Direct Deposit I go to one site. This site takes a username, password and a company ID.
It uses ASP.Net, probably 2.0. When I view the page in Chrome, everything is disabled by default. I have to refresh the page in order to interact with it. The entire site is riddled with slow postbacks, often when choosing a dropdown (instead of a less obtrusive update panel). Despite its looks and poor performance, most of the site actually works, just keep clicking. You might have to click places that make no sense. Some of this is easier in IE, but not much.
To view and enter time and request time off, you go to another site. This site takes a username, a password, and a different company ID. I'm sure this is done for security. (wat).
This site has a completely different look and feel, yet done in that ever-so-quaint ASP.Net 2.0 fashion, again using whole page postbacks to give it that "web 1.1" feel. Navigation here is atrocious. You can "clock in" on the first page, but as salary, I want to manage my time all in one shot. (Don't get me started on why we're having to report our time for each day). There's a different section where you can do this. It uses what looks like a pageable repeater. No styling on it. Just dragged and dropped into the editor, there ya go.
Well, you can select a time type from a dropdown. Of course, changing this dropdown causes a full page postback. Once you enter time and submit, you can't change it. And, of course there is no validation (server or client) so entering 80 hours for one day is perfectly fine.
There's ANOTHER section you have to go to in order to edit time. And you don't "edit" it, you delete it for that day and re-enter.
Well, Paychex has created a "revolutionary" "new" way to manage this! MyPaychex.com! This has a more streamlined look. If you look past the javascript error dialogs that show in IE as soon as you log in.
Trying to register is a complete pain, as changing options forces a postback that of course clears any text you entered before the postback happened.
You have to bind the other accounts you have with this one, as all this site is, is a tab container that holds iframes to the other websites.
Yeah... So Paychex... IMO you need to redo your web infrastructure. And be willing to pay for new technology done right.
Subscribe to:
Posts (Atom)