onenaught.comhttp://www.onenaught.com
A blog on web and software developmentWed, 12 Nov 2014 13:50:41 +0000en-UShourly1http://wordpress.org/?v=4.1.1One Naughthttp://www.onenaught.com/wp-content/themes/onenaught/images/onenaught.pnghttp://www.onenaught.com
116130OneNaught.comExt.NET Ajax Requests: MVC, Web API or ASHX?http://www.onenaught.com/posts/559/ext-net-ajax-requests-mvc-web-api-or-ashx
http://www.onenaught.com/posts/559/ext-net-ajax-requests-mvc-web-api-or-ashx#commentsWed, 12 Nov 2014 12:22:02 +0000http://www.onenaught.com/?p=559book on Ext.NET 2, I often described using ASHX or MVC Controllers (amongst other techniques) for getting data from Ext.NET Stores via AJAX Proxies.
Recently, I've received a few questions -- and wondered myself -- whether to use Web API instead. It has a cleaner method signature, and is intended for this kind of scenario where you want to return data rather than HTML.
I finally got a moment to compare all three (for my scenario). Continue reading →]]>

On this page:

When I wrote the book on Ext.NET 2, I often described using ASHX or MVC Controllers (amongst other techniques) for getting data from Ext.NET Stores via AJAX Proxies.

Recently, I’ve received a few questions — and wondered myself — whether to use Web API instead. It has a cleaner method signature, and is intended for this kind of scenario where you want to return data rather than HTML.

I finally got a moment to compare all three (for my scenario).

TL;DR version

Any of these approaches work

Interestingly, they all perform similarly well

In the long run, Web API seems the cleanest, though have some very minor caveats at the moment

For now, I would initially go for MVC Controllers because Ext.NET 2 has more support baked in for it than Web API so you can reuse a bit more Ext.NET code.

The ASP.NET team is planning to integrate Web API and MVC even more, so I imagine Ext.NET will inevitably support both, minimizing your code changes and making ASP.NET Web API even more likely the preferred option for implementing Ext.NET AjaxProxy handlers.

In more detail

ASP.NET Web API differs from ASP.NET MVC in that while they are both based on Controllers, Web API is intended to share data (e.g. REST or AJAX requests), while MVC is intended to generate web pages (though you can also use it to generate any content just like with Web API).

Web API has a nicer method signature where you define your parameters and the type of response just like any normal method. By comparison, MVC Controllers follow a convention that typically returns an ActionResult, often a View.

In the case of Ext.NET using MVC Controllers for Store/Ajax Proxies, Ext.NET provides extension methods to return StoreResult, which is a JSON object containing data for the stores, the total record count, success, or failure message, etc.

With Web API, you define your own class to represent the response, but your return type does need to include those properties in a similar way to a StoreResult class so that the Ext JS proxy can understand the response from the server. You can’t unfortunately use or inherit StoreResult because it has custom serialization into JSON, rather than simply serializing the relevant properties on the class using default JSON serialization techniques.

With ASHX, you get more bare metal coding with Requests and Responses, etc, and you can serialize your result back to the response manually, which is easy enough. As with Web API, what you serialize has to be understood by the client side Ext JS proxy, so you do need to have properties for the data, total record count, etc.

Compared to ASPX Web Forms (which you could also use to return JSON), ASHX is far more performant as it by-passes the heavy page lifecycle of Web Forms.

I was curious if MVC Controllers, and Web API Controllers could perform as well as ASHX. My guess was that ASHX would be the fastest, followed by Web API controllers, followed by MVC Controllers. I reasoned that ASHX has the least plumbing to do, while MVC Controllers have a bit more than Web API because of the View handling.

Rather than just go with a hunch, I finally had a time to actually test this out. I am glad I did, because (at least for my scenario) it turned out all 3 performed nearly identically (statistically insignificant differences, from what I could tell).

So, go for Web API, right?

Well, not so fast: unfortunately Web API just has the slightest headache to configure correctly – your method signature may need to support a parameter called action which is passed on the querystring by the Ext JS Ajax proxy (maybe a REST Proxy can be used to avoid this – I didn’t try that out).

Worse, however, it seems that enabling GZip compression for Web API responses is not enabled by default (even if assuming you have enabled the correct IIS features). This is because the mimetype for JSON responses, application/json, is not in the default list of dynamic compression mime types that IIS has which Web API maintains. And it seems you cannot just add it in your own web.config. You have to modfiy applicationHost.config directly, which many people may not be able to do.

Rather than try the various tricks to work around that, I opted for the other option, to modify applicationHost.config for now – which has to be done in a very specific way – just to get the Web API response compressed so I could carry on with comparing this approach with the ASHX and MVC Controller approaches.

I find this a bit off-putting for the moment. I imagine a future version of IIS will enable the application/json mimetype to be compressed for dynamic content, but for now, you have to bear this in mind.

Also, I think session defaults may be opposite for MVC and Web API – for MVC I think they are enabled by default and not for Web API. In my case, I do not want to rely on session for AJAX data requests (as that can hamper scalability as well due to serialized access to session) so you have to be sure it is turned off if you don’t need it.

Ext.NET 2 has great support built in for MVC. Web API is newer, and over time the .NET team are looking to integrate these two into one anyway, so for now for me it is good to reuse the mechanisms and infrastructure that the Ext.NET team have built around MVC – besides their support is so good that this is another bonus to use what they know in order to get even more rapid responses and remain productive!

Test your own scenario

I should add that while I don’t show any code here, it is worth testing this for your particular scenario as different circumstances may lead you to a different conclusion.

Others have found different results, and it really depends on the many things your application needs (session vs no session, routing complexity, and lots of other things), so you really need to compare your own scenarios.

Hope that helps!

]]>http://www.onenaught.com/posts/559/ext-net-ajax-requests-mvc-web-api-or-ashx/feed0SignalR with Ext.NEThttp://www.onenaught.com/posts/521/signalr-with-ext-net
http://www.onenaught.com/posts/521/signalr-with-ext-net#commentsTue, 19 Mar 2013 19:07:17 +0000http://www.onenaught.com/?p=521I've just written a post on the Ext.NET blog site looking at how you can use SignalR with Ext.NET Continue reading →]]>I’ve just published a blog post over at Ext.NET about using SignalR with Ext.NET

What is SignalR? Checkout this great video from Scott Hanselman:

In the video there is an example there of a stock ticker built with SignalR. As that project is on GitHub, I forked it to use the same data but update an Ext.NET GridPanel instead.

Ext JS 4 comes with a plugin for TabPanels to allow reordering tabs using drag and drop. There isn’t an equivalent for Ext JS 3, however.

I came across a useful extension of the Ext JS 3.x TabPanel to re-order tabs via drag and drop. It is implemented as a subclass of Ext.TabPanel, as Ext.ux.panel.DDTabPanel and a version of it includes a useful reorder event that is fired once a tab is dragged to a new position in the TabPanel.

I refactored it from a subclass of Ext.TabPanel to a plugin so the original functionality is unchanged.

Demo

Here’s a simple screenshot of it in action

Or try out the demo. (View the demo source code to grab the code, or continue reading.)

Subclass or Plugin?

The original is a subclass of Ext.TabPanel. So to use for any of your existing subclasses of TabPanels, you have to change them to inherit this one.

However, I see this more as a feature of an Ext.TabPanel so it might be better provided as a plugin, rather than a subclass. Being a plugin means it could be reused in combination with various other plugins and potentially any manner of TabPanel subclasses.

For example, there may be other features you add to the TabPanel (via plugins) such as being able to rename a tab by double-clicking it (like Excel), or inserting an add tab button as the last tab, etc. These could all be plugins so you can choose which one(s) you want for your needs. But if they were all subclasses, trying to use a particular combination would mean you would need a particular subclass to represent the permutations. If you wanted another combination, you’d need another subclass, and so on. As a plugin, you can just pick and choose which other plugins you want as well.

So I attempted to refactor it as a plugin (without changing functionality).

The Code

The code involves 3 parts:

The original subclass refactored into a plugin

The accompanying DropTarget (only the constructor was changed)

Example CSS to show the drop arrow (the blue one in the screenshot)

Original subclass refactored into a plugin

This is where the bulk of the changes are, but the functionality remains as is.

Credits

Help

Let me know if you spot any problems or better practices in the conversion to a plugin. If you have improvements to the actual functionality, please post it to the original thread on the Sencha forums.

Ext.NET 2 released

Ext.NET is promoting my book

Geoffrey McGill, the founder of Ext.NET also asked me to write a blog post on their site about the book. That post has a bit more about the book, sample screenshots of some pages, and chapter summaries.

The book is also being quite heavily promoted on the Ext.NET site:

Discount codes to purchase the book on its own

Finally, if you already have an Ext.NET license or just want to get the book, you can use one of these discount codes when purchasing directly from the publisher:

The reviewers were none other than the Ext.NET team itself. They were excited about and dedicated to this book which would not have amounted to much without their involvement. They are also offering free copies with any purchases of Ext.NET!

The reviewers were none other than the Ext.NET team itself. They were excited about and dedicated to this book which would not have amounted to much without their involvement. They are also offering free copies with any purchases of Ext.NET!

What is Ext.NET?

Ext.NET also includes components not found in Ext JS, extending various Ext JS classes where needed, thus providing its own JavaScript layer on top of Ext JS.

About the book

Update December 4, 2012: I’ve just published a post on the Ext.NET web site describing the book in further detail, including a summary of all the chapters, sample screenshots, and more. The chapter overviews are below, but see the previous post for further info too.

Chapter overviews

Here’s a summary of what each chapter contains:

Chapter 1, Getting Started with Ext.NET, provides an overview of what Ext.NET is and how it is related to Ext JS and ASP.NET. In addition, this chapter covers how you can obtain and set up your development environment ready for Ext.NET development.

Chapter 2, Ext.NET Controls Overview, introduces various types of controls available in Ext.NET. Using the Button control, we introduce many concepts common throughout the Ext.NET control suite. We also look at how client-side and server-side events can be set up. This chapter also introduces other more common components including Panels, Toolbars, Menus, Windows, and Tooltips. We also get a glimpse of some of the complex UIs that are possible by reusing these components.

Chapter 3, Layout with Ext.NET, covers the numerous layout options available in Ext.NET to help you organize your web applications. Topics covered include the Viewport, and specific layouts such as Border, Accordion, Fit, HBox, VBox, and more.

Chapter 4, AJAX with Ext.NET, looks at the powerful AJAX options Ext.NET supports. We cover the powerful DirectEvents and DirectMethods features, as well as AJAX options specific to certain controls. This is a powerful chapter that lays the foundation for slick and usable applications that are responsive to user interactions.

Chapter 5, Working with Data, looks at the powerful data handling techniques available in Ext.NET. We cover XTemplates, which allows you to define HTML templates to bind data to, and we explain the Stores, Models, and Proxies architecture that allows for powerful data-binding reuse across many Ext.NET components. The ComboBox and DataView are introduced as examples of controls that reuse this architecture.

Chapter 6, Introducing GridPanels, covers the popular and highly sophisticated GridPanel control. It is another control that reuses the Stores, Models, and Proxies architecture, but is given its own chapter. We look at various features of the GridPanel such as paging, filtering, sorting, grouping, column summaries, row expanding, and selection models. We also look at how grid editing can be enabled, including in-line grid editing at the row or cell level. As large as this chapter is, there are many other GridPanel capabilities that we have not been able to fit into this book, so many links to further examples and resources are also provided.

Chapter 7, Forms and Validation, looks at the numerous form controls available in Ext. NET, how to lay them out, and how to enable client and remote validation. We also look at how custom validators can be created. Lastly, we also see how Ext.NET’s data-binding capabilities can also be reused with forms.

Chapter 8, Trees and Tabs with Ext.NET, introduces the popular TreePanel and TabPanel controls. Due to limited space in the book, we cannot cover all the sophisticated possibilities that these controls offer, but we do provide an overview of how tree nodes can be loaded asynchronously and how to reuse the Store, Models, and Proxies architecture to bind data to trees. We also look at various ways TabPanels can be configured, including how to load content on-demand using various AJAX techniques supported by Ext.NET.

Chapter 9, Extending Ext.NET Controls – Custom Controls and Plugins, is perhaps the most powerful chapter in this book. It shows you how to extend Ext.NET controls in a variety of ways to support both ASP.NET Web Forms and ASP.NET MVC Razor templates, enabling you to create highly reusable components. Most of the chapter looks at how controls can be extended, but we also look at how you can use the available plugin mechanisms to reuse functionality across different types of components.

Chapter 10, Troubleshooting and Debugging, looks at how to debug your Ext.NET applications. In particular, we look at how to enable debug versions of Ext.NET and Ext JS JavaScript and what tools to use for cross-browser troubleshooting. This chapter also provides important tips on how to request help in the Ext.NET forums in a way that will increase your chances of receiving a quick response.

My personal favorite is chapter 9. Not only did I learn a lot myself when putting it together, I think it is also one of the most important; I wish I knew this about 3 or 4 years ago as it would have helped make my own apps even more reusable. For me it is worth getting the book for this chapter alone!

Samples photos

Update: December 15, 2012: A few days ago I received my author’s copy (a number of days after a work colleague received his, even though mine was sent a lot earlier to me!)

The book on my desk!

Sample page from Chapter 5, Working with Data

Sample page from Chapter 6, Introducing GridPanels

How I ended up writing a book on Ext.NET

I had been using ASP.NET for many years before coming across Ext.NET (when it was known as Coolite). I had been using ASP.NET for some high-profile, public-facing, web sites where the main challenges were CSS-based designs, W3C accessibility, web standards, and using JavaScript to progressively enhance e-commerce web sites.

Shifting focus to highly interactive applications

As I shifted focus to web-based business applications, the technologies to use were the same, but the emphasis was very different: complex interactions (desktop-like), different user types, being able to mandate JavaScript, more support for IE6 (thanks to corporate environments being slow to uptake newer browsers), etc.

Ext.NET enables complex interaction design

From a usability point of view, as Alan Cooper explains in his excellent book About Face 3: The Essentials of Interaction Design, business applications may have beginner or novice users, but those users have incentives to become intermediate or advanced users quite quickly, so they can get their job done. The intermediate user should therefore be the prime target of such apps. This means that more sophisticated UI capabilities are needed with a far greater emphasis on JavaScript and AJAX interactions rather than traditional ASP.NET Post Backs.

Ext.NET and Ext JS cover this really well and saves a lot of time trying to create a sophisticated widget framework letting you concentrate on improving your application with highly reusable components. With Ext.NET’s important enhancements and integration with .NET it is a compelling choice for these types of applications.

Writing about Ext.NET

So around January 2012, when Packt asked me if I wanted to write a book on Ext.NET, despite having no spare time, it was hard to resist! I started around March or April, and had it not been for some some major personal interruptions in between, it might have finished around August. But the release times nicely with the Ext.NET 2.1 release.

It has been a great learning experience for me and I would have certainly liked to know some of the things mentioned in there when I first started out learning Ext.NET!

]]>http://www.onenaught.com/posts/451/book-ext-net-web-application-development/feed9Blog restarthttp://www.onenaught.com/posts/435/blog-restart
http://www.onenaught.com/posts/435/blog-restart#commentsSun, 11 Nov 2012 21:20:44 +0000http://www.onenaught.com/?p=435Apart from a handful of posts in 2010 and 2009 I haven't really blogged much since 2008. Unfortunately it has been a bad combination of a number of personal tragedies, being too busy at work, and lack of spare time.

I am hoping I am through the worst of it now, and might see if I can restart this blog.

Continue reading →]]>Apart from a handful of posts in 2010 and 2009 I haven’t really blogged much since 2008. Unfortunately it has been a bad combination of a number of personal tragedies, being too busy at work, and lack of spare time.

I am hoping I am through the worst of it now, and might see if I can restart this blog. I don’t expect to post frequently, but it may have a subtle change of focus. I’ve reset the theme, as the old one was a bit out of date. I’ve just used one of WordPress’s default themes, plus a few tweaks. I may do a proper theme at some point when I get some spare time.

Around 2007 or 2008 I started to focus a lot more on complex business web-application; really complex forms (200-300 fields for example), complex desktop-like interactions and so on.

I’ve shifted slightly from jquery/XSLT etc to heavy JavaScript/Ext.NET/Ext JS/AJAX etc. I still really like jQuery and XSLT and continue to use it, but as my focus has shifted to complex business apps, I am quite excited about Ext.NET, interaction design for complex desktop-like apps, and related technologies.

In fact, about a year ago I was asked to write a book about Ext.NET, which I started a few months after that… A follow-up post will talk about that a bit more, shortly…!

]]>http://www.onenaught.com/posts/435/blog-restart/feed0SEOMoz’s intro to SEOhttp://www.onenaught.com/posts/405/seomozs-intro-to-seo
http://www.onenaught.com/posts/405/seomozs-intro-to-seo#commentsSun, 22 Aug 2010 09:35:19 +0000http://www.onenaught.com/?p=405Continue reading →]]>This is a great intro to SEO from SEOMoz:

Example

What does W3C spec say?

When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where “name” is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively.

The previous quote implies name=value should not be sent for input type=image

That implies the name should be submitted too, even for input type=image (and assuming that, then the value of the input should be submitted too, which seems to be confirmed by section 17.13.2 Successful controls in the spec, which notes: A successful control is “valid” for submission. Every successful control has its control name paired with its current value as part of the submitted form data set.)

So, I think Firefox 4 has introduced a bug…?

Update: not a bug

The bug I raised has been updated and turns out that this is per HTML 5 spec, while I was comparing what I saw with the implementations in earlier versions of Firefox and with the HTML 4.01 spec…

IE (and Opera) also only send .x and .y, so I guess they settled on that given most sites are probably still catered for/assume IE as the predominant browser…

Workarounds

One possible workaround is this, but ugly:

Detect the browsers to do this for (feature detection would be better…)

Capture the form submit event and find the button that caused this, or capture the button click event

Append a hidden input like this (jQuery example, assuming button is the button you have captured):

What kind of savings do you get?

The savings will differ for many reasons (the XML document size, the structure of the XML, the types of transformation being done etc etc), so it is hard to give a definitive savings. But here’s an illustrative example:

A few weeks back, a colleague at work was having trouble with an XSLT that was taking a long time to transform.

We started to have a look; I was expecting to find inefficient XPath, or an XML document structure that wasn’t conducive to decent transformation speed, or something like that.

However, I noticed the first thing was his output was set to be indented, and the XML input was HUGE.

So, the first thing we did was turn it off.

That alone reduced a 12 minute transform (on a 300MB document) to just 1 minute!

In another scenario, a 70K XML document was taking about 0.25 seconds to transform. Turning off indenting shaved a few more milliseconds (can’t remember exact amount now) — and saved about 2K in the output HTML that it generated.

Why can this make such a difference?

I think the specifics may vary depending on the XSLT parser you are using, but I believe it is basically this:

Each newline/white space/tab(s) created for the indent requires an extra text node to contain these characters which requires extra memory (though at this point may not add that much time to the transformation).

When the transform is then saved to a file, or written out to an output stream strings are often involved. String processing can be expensive in many programming languages, so each of these indented text nodes needs handling. For very large documents (as above) this can require a lot of unnecessary processing.

But doesn’t this make the output harder to read?

The consumer of a transformation result is likely to be another process such as another XSLT in a pipeline, another process, or even a web browser.

None of these typically care about the extra white space, which also would require more processing when loading.

If you need to view the XML, it may be worth keeping the indent off and manually opening it in a text editor that has the ability to “pretty print” it for you. (Warning: some editors and IDEs, e.g. Visual Studio, can do automatically pretty print an XML document for you when you open it, making you think the XML itself had the indented output!)

Other savings are still possible

Turning off the indent is just one of many things you can look into. Other things include the following (though your mileage may vary):

Use attributes instead of elements (where possible; usually this is for simple values, such as numbers, dates, and very limited strings, and where the element is not expected to be indented)

Look at the XML structure to see if can be improved to make XSLT processing easier

Since this article was originally written back in 2009, the solution presented at the time (applying border-radius to some of the inner elements) no longer seems to apply, and has therefore been removed.

Note, you may also be able to get rid of the -moz and -webkit prefixes in your CSS depending on what support level you are aiming for.