July 2005 - Posts

My Blue sky holiday -> KL (Malaysia) trip

Just came back from a _small_ vacation in KL, Malaysia with friends. We drove all the way to KL and drove back... phew...

Nothing much to do there except to eat and drive around..

Please be carefull driving in KL, all the women seem to be F1 trained!

Lovely place, except the killer traffic!

And The Pertronas looks _amazing_ in the night time, so beautifully lit up... worth a second trip...

VS.NET 2005 and VSS 2005 July CTP

VS.NET 2005 and VSS 2005 July CTP were released on 12th of July. Now upgrading my version from June CTP to July CTP.
June CTP has some major changes over its predecessor including the Membership API changes which was pretty scary to fix. But we got all the api differences fixed and now anticipating what changes will the July CTP bring.. Hopefully nothing that breaks the code...

Anyone working with July CTP yet?

Modal Pop-Up window(ASP.NET JavaScript)

--------------------
Note : Ported over entry from my old blog, dated : 23rd - Feb - 2005
--------------------

Problem:
We all require Modal Web Dialogs once in a while, and so came my turn. I used js to pop up a modal dialog like so :

function OpenModalDialog(strUrl,strFeatures,aID,hours)
{
 if (strFeatures == '')
  strFeatures = "resizable=no;dialogWidth:510px;dialogHeight:350px;
                        help:no;maximize:yes;minimize:yes;scrollbars:yes";
 //set the cookie values
 document.cookie = "AID=" + aID + ";path=/";
 document.cookie = "Hours=" + hours + ";path=/";
 var r = window.showModalDialog(strUrl,'',strFeatures);
 if(r == true)
 {
  document.Form1.txhBool.value = '1';
 }
 else
 {
  document.Form1.txhBool.value = '0';
 }
 document.Form1.submit();
}

This function pops-up a modal web dialog. Now you have the modal dialog floating on top of the browser.
I wrote a few lines of code on the modal dialog and put a button in to make it submit. But to my surprise, another window(non-modal) poped up. I was very surprised and tried to get help but was told that modal dialogs cannot do a postback... Well I was very surprised at MS to let a loophole like this exist in IE. But I just continued my work due to lack of time to do some R&D. So now the only option was using js, so I used this function in my popup dialog and called it on the click on a <input> button (not asp button - as using asp button would force a postback!)
function ClosePopUp(val)
{
 window.returnValue = val;
 window.close();
}

What this fn does, is to pass the value val to the parent browser's function that poped this modal dialog up.
Lamentations :
So I process the value that is retrurned by the modal dialog and continued the processing on the parent page. The down side of this way according to me were three-fold.
1)All process had to be done on the page load of the Parent page(becuase the js function does a postback after getting a value from the child modal dialog.
2)A lot of time was wasted due to the fact that processing had to passed to the parent
3)The page modal was not so elegant
Many chances came where I needed to use modal dialogs, and all the way I used this method, thinking all this while that modal dialogs can't postback. Little did I know that I was so wrong!
Resolution :
Earlied when I was helping a person on one of the forums, Eliyahu Goldin, told me so!!
He said all I needed to do is to add this line inside the <head> </head> tag of the modal page :
<base target=_self>
Without wasting a second I opened one of the projects with the former js modal dialog implementation and tested it, and it worked totally!!!
So much time wasted, so much pain suffered just becuase I didn't bother to google for this one little piece of code! :(
I owe this to Eliyahu...Cheers man..

ASP.NET 2.0 Profiles in a Load-Balanced (Web-Farm) Scenario

Then came web-farming issue just when life started to seem smooth sailing :)

I am planning to utilize ASP.NET 2.0 profiles in my project and everything was good, then came the scenario whereby the UI layer in running on a Web-Farm! Hmmm...

Profiles utilize a local database to keep the info and in a Web-Farm it would be kinda impossible to perform that feat! Good thing Profiles are configurable!

Not only ASP.NET profiles but membership, roles, and web-part personalization also support web-farms!

So what we do is to configure the profiles to read from a central db (in this case, the db that the web farm machines are pointing to). When u modify the state of the profile object, the modifications are saved between visits to the site. So if the request is directed to a different server within the same session (in web-farm scenario), the profile state will be intact, since its stored and accessed out of central db.

So in a web-farm scenario, this is what you should do :

1)Point each machine on the web farm to the same database server to store the profiles. You can set this by changing the connection string on the provider configuration.
   - Since Profiles are API and Schema over database access, there shouldn't be a lot of considerations while shifting the db target from local to the web-farm central db.

2)Now to make profiles use your application's db instead of its own, use the "aspnet_regsql" tool (Window\Microsoft.NET\Framework\[version]) which will let you add the tables utilised by profiles to your own db. Run it without any command line parameters to get the windows wizard that configures all this for you (you can also point to the db used by ur app with this wizard). [OR, run it with the -? option to see all the command line parameter, yea, i know u already know this ;)]

3)So now, the database tables that profiles are using is in ur own application's db (the tables utilized by Profiles, Membership, etc will have a ASP.NET prefix), now go ahead and create relationships between these tables and your own application's tables!

Remember, Adding fields to the tables utilised by profiles is not recomended, unless you write your own provider that can handle these fields!

Cheers!

Major Change - Bloodline

We have been using typed datasets(which are heavy as we all know) for LoneStar. But as we slowly move forward, more and more disadvantages are showing.

So we made a drastic decision. Change the blood line from Typed Data Sets to custom objects...

Considering the existing work that we have done, it will definetly take some time to change the business entity from datasets to custom objects, but there is a good news, we are still using the same typed datasets! Where? inside the custom classes!

We get some advantages here...

1) We still retain the typed tables in our custom classes making the job of the develope a lot easier, compared to classes with untyped datatables or untryped datasets or simple classes or even typed datasets!
2) We make the bloodline of our projects ( the business entities) a lot more leaner compared to typed datasets!!
3) We still have those typed datasets in the project, but they are now arranged logically accroding to the modules and all the dirty work is done by the lean custom entity classes.
4) We still get to enjoy the benefits of Typed DataTables because of custom enties still contains those typed DataTables, but they are more leaner as the objects utilize _only_ the requried tables!

 

I will be posting a skeleton of how the above is done although most of you already get the idea!

Cheers!

LoneStar Framework

LoneStar - which is the codename given to the project that i am working on is finally taking some shape. So after much sweat and blood, this is what is currently being formed in the new .net 2.0 application

UI Layer
calls
UIPC Layer
can call either BusinessFacade or WebService(in case of distributed system) - read from Web.Config
Web-Service layer or BusinessFacade layer.
If Web-Service is called, the web-service will call BusinesFacade in turn.
BusinessFacade will call the BusinessComponents
The job of BusinessFacade is to orchestrate the processings. I am also planning to plug in a Business Rule Repository into the Facade.
BusinessComponents call the DAL
I have kept the DAL in such a way that it is configurable as to which DAL should be used, we have a SQLDAL and a OracleDAL.
And finally DAL talks to the database -> we have a Microsoft.ApplicationBlock.Data dll here which is temporarily being used to to data transactions(as the app is still not in any solid stage)
Typed DataSets are being used as the bloodline of the application, which makes the developers job much easier (yes i did example the pros and cons of typed datasets in .net 2.0 :) )

Sorry, Been quite busy and the didnt post much for the last couple of months..
Cheers!

New Blogger on DotNetJunkies

Helllllloooooo DotNetJunkies.Com....

I am very exited to announce that my blog will soon be moving to dotnetjukies.com.

Have to figure out a way to move my existing blog at 'xtremedotnet.blogspot.com' to dotnetjunkies.com. Does anyone have any idea how to do that?

Anyways, I will be posting my new posts on this blog...

Would appreciate if someone know how to move blog to dotnetjunkies..

Thanks..

P.S : Cheers Donny, for the space!