Tech Blog

Jay's Technical blog

The Next TRUIX meeting is October 8th

15 September 2009
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

The next TRUIX meeting is October 8th. We are still finalizing some of the details for the night, but we will definitely be continuing tutorial on building a UI (using our www.TampaUx.net site). We also plan on bringing you some material for the Silverlight 3/Expression 3 launch.

Things will get started at about 7:00pm (with doors opening up at 6:30pm).

Sorry it’s taken us so long to get a next meeting (we’ve had a lot of scheduling conflicts to work through of our core team).

PS. the meeting after this one will be on November 3rd and we’ll have Jim Zimmerman talking to us about a topic that is definitely in the Dev-Signer realm! Stay tuned!


On the Road to iTextFileResult: Getting the Results from System.Web.MVC.WebFormViewEngine

10 September 2009
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

I’m in the process of building a new ActionResult for ASP.NET MVC. This new ActionResult will allow you to transform data into a PDF, RTF, or HTML (it uses iTextSharp behind the scenes, and yes, I have a working prototype right now that isn’t all that useful yet.. and you have to know way too much in order to use it as of this time).

Essentially what I want to do is use any view engine that the programmer chooses and convert the resulting html, xml, or regular string data into a file that gets pushed to the browser. All this works for all of the alternative engines, but the default engines doesn’t work… so, without further adieu

Challenge #1: WebFormViewEngine ignores the TextStream you give it

Actually this might be the only challenge here. I tried numerous solutions.. none of which worked. I finally cracked open the MVC source code and determined that I needed to inherit form their class and do some overriding… In my API I created BufferedViewPage, and BufferedViewPage<T> so I could intercept the RenderView code. Here’s a copy of my current (in progress) version of BufferedViewPage:

  1:publicclass BufferedViewPage : ViewPage, IBufferWebFormView
  2: {
  3:public TextWriter Writer { get; set; }
  4: 
  5:publicoverridevoid RenderView(ViewContext viewContext)
  6:     {
  7:         ViewContext = viewContext;
  8:         InitHelpers();
  9:// Tracing requires Page IDs to be unique.
 10:         ID = Guid.NewGuid().ToString();
 11:         var wfv = viewContext.View as WebFormView;
 12:         var page = (wfv!=null?wfv.ViewPath:""); // View should always be WebFormView
 13: 
 14:if (viewContext.ViewData["____writer"] != null)
 15:         {
 16:             Writer = viewContext.ViewData["____writer"] as TextWriter;
 17:         }
 18:         ProcessRequest(new HttpContext(new simpleWR(page, viewContext.HttpContext, viewContext.HttpContext.Response.Output)));
 19:if (Writer != null)
 20:this.Render(new HtmlTextWriter(Writer));
 21: 
 22:     }
 23: }

You will see that I’m injecting a new writer into the ViewData (I’ll eventuually come up with a better mechanism, but it works for now). My code for the most part copies what the standard WebFormViewPage does except that you’ll see that if the page is a WebFormView it runs Render after running ProcessRequest. I’m not sure if this is problematic or not, but it works! Before I release the actual library I will probably clean this up quite a bit (this is mainly an exercise in helping anyone who wants to use the WebFormViewEngine, but somehow capture the result and do something else with it..

BTW, the part of the code here you don’t see is that before I render I make sure buffering is on and then I clear the response text after generating this (which clearing the response was about the only thing I could do.. that generated data in HttpContext.Current.Response.Output is lost to you… at least I couldn’t find a way to get at it…)


JavaScript for the masses

03 September 2009
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

As you may be aware Scott Hanselman’s 2009 Ultimate Developer and Power Users Tool List for Windows came out yesterday. If you are like me you end up pooling through the list especially the new stuff to see if there is something cool that somehow you missed.

I found an item on the list that answers something I think I have been looking for (but not for me), but before I go on I need to give you some background (as usual).

Kevin D. Wolf (aka ByteMaster) and I have been talking over the last several months on all things Ajax. We’re both pretty deep on the topic of Ajax (Actually Kevin is deep on a number of topics), and we’re both pretty opinionated about a few things (I know you are shocked that I would say that about myself).

One of the things I’ve sort of been looking for is something that makes it easy for someone to write Ajax. The new Blend Skecthflow stuff is a HUGE game changer, but if what I want to write is Ajax then after using Sketchflow I’m back to the drawing board.

Interractions in Ajax.. found!

So yesterday, I was browsing the Hanselman list and I found a side reference to a tool to watch called “IxEdit.” All I can say is WOW! [Personal Note: Diane Leeper download this now! I think you could have some fin with this…] Their video tells it all, but I will tell you what I think is cool about it.

You create a page and add references to jquery, jquery ui, and their ixEdit script as well as a few CSS. Once you do this the page launches with a movable dialog. This new dialog let’s you create Ajax/Web 2.0 (more the latter) interactions with your page all by simply playing in their GUI. Really, really cool! Now they don’t do everything, and in fact from what I saw of the tool you can’t set up to make calls back to the server (but I could see something like that being set up, and am starting to think about it). Once you are satisfied you can “save and reload” which reloads the page and applies your designed interaction (so now you can see how it worked).. something not look right simply edit the interaction to tweak it’s setting.

When you are done it will help you deploy the script, so now you have designed JS code with out actually writing a line of code! Really, really cool, IMO!

[I spent a couple of hours looking for pictures to fancy this up a little.. I run a UI/UX users group for crying out loud.. I need to get better at that, so sorry my post is bland.. I’ll try to follow up with something more graphically pleasing]