Archive for November 2007

In order to provide relevant content to a site visitor, I wanted to find out what time of day it was wherever the visitor was located.  This would be useful to serve different content based on if its morning (“Buy Coffee!!”), lunch (“Eat lunch near you!!”), or evening (“Come rent a movie from us!!”)


Using a similar approach to how viewstate is maintained during postbacks, I added a couple of methods to my base page implementation and a read-only property which returns the value of hidden input.  When the base page’s load method fires, it registers a hidden input and a small script that will set the input’s value equal to the date of the client browser during a postback.



public class ClientTimeBasePage : Page


{


 


    private const string CLIENTTIME_SCRIPT_ID = “__CLIENTTIMEJS”;


    private const string CLIENTTIME_FIELD = “__CLIENTTIME”;


 


    public string ClientTime


    {


        get { return this.Request.Form[CLIENTTIME_FIELD]; }


    }


 


    protected override void OnLoad(EventArgs e)


    {


 


        ClientScript.RegisterHiddenField(CLIENTTIME_FIELD, “”);


        if (!ClientScript.IsOnSubmitStatementRegistered(typeof(string), CLIENTTIME_SCRIPT_ID))


        {


            ClientScript.RegisterOnSubmitStatement(typeof(string), CLIENTTIME_SCRIPT_ID, “document.getElementById(‘” + CLIENTTIME_FIELD + “‘).value=new Date();”);


 


        }   


        base.OnLoad(e);


 


    }


}


At this point, I should mention I have not tested this thoroughly but I’m pretty sure I’ll run into problems when we get into different culture and locale settings across browsers.  A few other considerations that come to mind is using AJAX for a similar implementation and possibly attaching the client date / time to the Request context.  This seems like a more appropriate place for it – perhaps using extension methods in C# 3.0.  Another option is to write some more intricate javascript to perform a little more parsing on the client-side.  We should always be careful when we rely on the client’s browser for input data.

If you’ve been getting involved in any enterprise SOA initatives, you may have come across the term “service virtualization”.  Novice SOA practioners and architects just getting into the SOA mindset are sometimes confused as to what exactly this means.  I think it is best explained by a metaphor to a real-world “virtual” service.


Perhaps the most popular “virtual” service is a stock broker.  Stocks are traded on several different exchanges throughout the world.  Stocks may be traded on NASDAQ, NYSE, London Stock Exchange, and many more around the world.  Each of these exchanges have their own rules governing fee’s, taxes, transactional flows, currency, trading times etc.


We, as consumers of these services, don’t want to concern ourselves with the specific implemenation rules of the different exchanges.  We leave this complexity of buying and selling rules to the virtual service – the stock broker.


In this example, specific exchanges provide concrete implemenations while the stock broker provides a virtual service.  Virtual services provide this level of abstraction and shielding from specific implementations for the end-point consumer.

I found this neat (and free) trash destination for SSIS.  It’s really great as a development aid.  It allows you to quickly terminate a data flow path, and does not require any configuration. It will consume the rows without any side effects, and prevents warnings or errors you may otherwise receive when executing the data flow. 


You can read more and download it from here