Code Luck

If you don't want to plunk down the money for Microsoft Sharepoint, you can get by with TikiWiki for some quick and easy collaboration among members of a project team. Tiki is an open-source Wiki software that I installed yesterday on my work laptop (A Dell XPS Pentium-M 2.0 GHz machine with 1GB RAM).

Tiki is powered by PHP4 and needs a web server and a database. I went with IIS 6 and MySQL 5.

The installation procedure is similar to something like Wordpress--it is possible to buy Tiki hosting space from an ISP, or install it locally.

First, download and install PHP. You can register PHP with IIS either as an ISAPI extension or as a CGI module. ISAPI is faster and more secure, but I went with CGI (which is simpler to install).

Next, you need to create a database user and a database schema in MySQL for Tiki. I used MySQL Administrator which comes with MySQL 5. You can use phpMyAdmin also if you like administering your MySQL over the web.

Next, extract the Tiki software in a directory on the local file system, and create a virtual directory (I called it "tiki") in IIS that points to the location of your Tiki installation.

Next, point your browser to http://[your web server]/tiki/tiki-install.php and setup of your Wiki will commence.

I loved the features offered by this software. I hesitate to call it simply "Wiki" software because it offers much more out of the box. I am still exploring, but it offers, in addition to the Wiki capabilities:

(1) Blogs, which is a nice touch if a particular member wants a soapbox of his/her own.
(2) Articles (by topic)
(3) Quizzes
(4) Forums (They included a complete forum/BB software??)
(5) Surveys (I have yet to toy with this)
(6) A group calendar
(7) Group chat
(8) FAQs
(9) Newsletters
(10) A workflow engine.

Whew!

The Wiki software allows your site to be customized with themes and menus. And there is mail notification for changes. As if all this wasn't enough, Tiki is extensible with custom modules written in PHP. For example, there is a calculator mod, a world clock mod, a mod for WebDAV access to your Wiki, a mod that imports some cool avatars, etc.

I like.

Here are a few things I learnt about  ViewState, SessionState and ApplicationState today.

ViewState property is used to save data in a hidden field on a page. Because, ViewState stores data on a page, it is limited to items that can be serialized. Complex items have to converted to & from strings.

ViewState info from one webform isunreadable to other webforms
Property
        ICollection ViewState.Values
Method:
       ViewState.Add(string key, object value)

One should limit the access points to Application & Session State and basically create page level variables to store data from these and write back to them at the end.

Maintaining Session state affects performance.

Application state variables are available throughout a current process but not accross processes. If an app is scaled to multiple servers or multiple processors within a server, each process has its own application state.

In Visual C#, be sure to test whether the state variable is null or not before using methods like ToString() on it.

Mechanisms for communication between webforms

1. Context.Handler object (Use this object to retrieve public members of one webform's class from a subsequently displayed web form.
   
2. Query strings
3. Cookies
4. ViewState
5. Session state
6. Application State

Here are the arguments
From: http://www.theserverside.net/news/thread.tss?thread_id=29919

Unsuspecting programmers, it is claimed, will use the SqlDataSource control and unknowingly commit the unforgivable architectural sin of mixing their user interface, business logic, and data access layers.

The SqlDataSource control enables you to represent a database connection, and common database commands, declaratively. Simply by declaring an instance of the SqlDataSource control in a page, you can represent SELECT, INSERT, UPDATE, and DELETE commands which can be executed against a database.

SqlDataSource control is considered "really, really bad" is that it encourages programmers to flatten what should be many into one. The SqlDataSource control mixes business logic and data access layers into the user interface layer.
 
Mixing the data layer with the UI is a BAD idea, period. Sure there may be times when you can get away with it, but the eventual unmanageability of it will greatly outweigh the short-term productivity gain. Creating logical layers of abstraction doesn't require physical separation of layers. Just moving the DAL into a separate class is a good idea because it gives you a single place to look for code dealing with the database. In the SqlDataSource scenario, if you change a stored procedure that is used on more than one page, you have to track down every page to make the change. This is bad design incarnate.

Behind the scenes the SqlDataSource control generates the ADO.NET classes (Datasets, SqlCommand, etc.) that is necessary to access the data defined in the control's markup. But what about reuse? If I'm calling a stored procedure with several parameters through a series of page requests, it would be nice to get some reuse from the parameter collection ala Data Access Application Block's parameter caching.

The ObjectDataSource control however does provide an architecturally sound way to bind web page controls to a middle-tier (logical, not necessarily physical) layer. So, for those web developers out there who want the ease of use that comes with declarative data binding, I recommend they use the ObjectDataSource control and forego the SqlDataSource control altogether.

I think as a best practice, one should always use ObjectDataSource since it allows us to seperate the business layer logic from the UI and follows the MVC.

I came accross this because I wanted to sort a GridView. I was assigning a DataTable returned by a method to the GridView's datasource. If we create a explicit DataSource object and bind the GridView to it then the gridview is able to talk to the datasource and takes care of the sorting/paging.

The object datasource helped me to grab data from a stored procedure and hence with zero sql code in the UI and kep it clean.

Perl is a powerful language. And it can be terribly concise. I believe there are competitions that award prizes for the most concise (and most illegible, of course) Perl programs.

Perl also fits a niche. If you are a sysadmin-type scripting sort of person, it is the tool for you. The core language has powerful text-processing facilities; and packages exist for everything else such as database access, XML parsing, whathaveyou.

But if you thinking of programming-in-the-large, forget about it. Object oriented support is available from Perl 5, but the syntax is clumsy and looks tacked on as an afterthought. CGI programming? You are probably better off with PHP.

But I digress.

I recently saw and played with HTML::Embperl, which is a Perl package that lets you insert Perl code snippets in your HTML. Think JSP, but with Perl instead of Java. On the surface, seems like a good thing. The power of Perl directly from your Web pages, without having to worry about having to explicitly program to a CGI interface. But "the surface" often misleads.

Quite frankly, the philosophy (not to mention the syntax) of Embperl made me cringe. Over the years, I have come to appreciate the good things that happen when you separate concerns. Embperl--not unlike carelessly programmed JSP--throws seperation of concerns out the window.

Frameworks are often derided. Frameworks like Struts or Wicket try to separate concerns and this leads to a steep and complex learning curve. Embperl goes in the opposite direction and this makes it tempting for some, especially for smaller projects. But if there is one thing that I have learned, it is this: There *are* no small projects. Even the smallest project has a way of growing and bloating past its original intent.

I would personally put my money on the frameworks.

Any idea about how to implement the autoclose Session timeout windows that some bank websites imlement?

I have been playing with giving the user an alert before a session timeout in a secure website.Here is a basic method that I found.
/*************************************************************************/

int int_MilliSecondsTimeOut = (this.Session.Timeout * 60000) - 120000;
string str_Script = @"
function Reconnect()
{
alert('Session is about to Timeout in 2 minutes.\n Please complete work and submit');
}
window.setInterval('Reconnect()'," + int_MilliSecondsTimeOut.ToString() + @");
";
Page.RegisterClientScriptBlock("Reconnect", str_Script);

/*************************************************************************/

This javascript method gets called 2 minutes before a Session timeout but it needs user attention and doesn't autoclose (render useless after timeout period expires) and log the user out.

One way could be using Form Authentication in Asp.Net.

Ideas welcome.

P.S.

javascript Script tages seems to be banned in blogger, while yahoo 360 blogs allow it. ;)

I think applying HtmlEncode() solves the security and page beaking issue. I think that what nneeds to be done whenever projects which use FCKeditor have to do in order to allow users to create text with html tags in it.

I came across this article about ASP.NET custom error pages while trying to trap exceptions before the user sees them. I needed to implement a global exception handler plus a way to redirect the user to a generic error page in case of uncaught exceptions.

http://www.aspnetresources.com/articles/CustomErrorPages.aspx

This helped in trapping uncaught application, Page exceptions

Point to Note
ctx.Server.ClearError();

should be commented in
global.asax
OnError event of base page

in case we want the user to be redirected to a custom error page as set in web.config

Test Post. Nothing here to see.