August 2006 - Posts - LA.NET [EN]

Setting the style of the items shown by the AutoCompleteBehavior
Sun, Aug 27 2006 10:06

The AutoCompleteBehavior is not as good as it could be…at least, not in the July CTP version. Many have already asked for a way to change the style of the generated elements which are shown by the list. Most guys try to help by saying that you have to write a new behavior or change the current one so that the items have the desired styles applied to it. Though these solutions do work, you really don’t have to go that far to get the desired results.

First, we need to understand what happens when we use that behavior. The AutoCompleteBehavior is a complex behavior which reuses the PopupBehavior to show the results returned by the web service method used to make the call. By default, it creates a div control which serves as a container (I’ll call it top element to distinguish from the other ones used by the control). As you might expect, the PopupBehavior is attached to this control. Each of the strings returned from the web service method is placed inside a div and then are added to the child nodes collection of the top element control. It’s also important to understand that the several style properties of all the divs are set to some default values (which are adequate to most situations).

What most guys still haven’t seen is that you can specify a control which is used as the top element. To achieve that, you must resort to the completionList property. What are the advantages of specifying your own top element? Well, based on what I’ve told you before, you can surely understand that by explicitly indicating that element you can specify a css rule which might just be enough to get the expected results. To illustrate this, let’s start by saying that I’ve added a div to the page and set its ID to test (btw, you should note that if you’re using the AutoCompleteExtender, this element must have the runat=”server”). You can set it as the top element container by setting the completeList property of the behavior to text (or the DropDownPanelID property, if you’re using the AutoCompleteExtender).

Now I’ve just decided that each element presented by the list should be underlined. I can achieve this by writing the following CSS rule:

What the previous rules says is that the text of all the DIV child nodes of the element whose ID is set to test should be underlined. This will work because the AutoCompletebehavior will use the test element as its top element container where all the items returned from the web service will be shown.

Unfortunately, this doesn’t work in all the situations because the AutoCompleteBehavior initializes several style properties of the DIV elements which are used to present all the items returned by the web service. For instance, let’s say that I want the text to be right aligned (something that might be necessary in some cultures). You can try setting the property with another simple rule, but it’ll be overridden by the Javascript code used to create the element that is going to be shown to the user. The easiest way to get the desired results is to make sure that the CSS rule prevails over the style assignment performed through Javascript code. To achieve this, you add the !important special value in front of your rule. Though you should use this value carefully, it really is applicable in this case. So, if you want to have each item underlined in blue and right aligned, then this should do it:

I’ve tested this with IE7 and Firefox. Since I don’t have IE6, I can’t really say that it doesn’t work there. Let’s assume that it doesn’t (at least, that’s what I expect)…well, there’s still a solution for you: handle the non-compliant onresize event of the top element container (which is only fired by IE) and go through all the child nodes and set the correct style properties. Here’s the code:

function updateStyle(obj)
{
for( var i = 0; i < obj.childNodes.length; i++ )
{
obj.childNodes Idea .style.color = "blue";
obj.childNodes Idea .style.textAlign = "right";
}
}

Hope this helps.

by luisabreu | 5 comment(s)

Filed under: MS AJAX

Review: Applying Domain-Driven Design and Patterns
Mon, Aug 21 2006 10:07

Today I’m starting a new category where I’ll post my reviews about books I’ve read. Last week I’ve finished reading Applying Domain-Driven Design and Patterns, by Jimmy Nilson. Well, what can I say? It’s really an extraordinary book… it can really be considered the best of its kind, if you’re looking for some real stuff and examples on DDD and TDD. Jimmy’s writing is really easy to read (which is always a good thing). The examples are good and do really help you grasp the concepts that are presented in this book.

You may be tempted to compare Jimmy’s book with Eric Evans Domain Driven Design. In my opinion, Jimmy‘s book is more “down-to-earth” while Evan’s book can be considered a little bit more abstract. Nevertheless, it’s a great book also. So, if you’re looking to a head’s start into DDD and TDD go ahead and buy Jimmy’s book. Please note that I’m not saying that you shouldn’t buy Evans book; if you can, then buy both; however, if you want to buy only one, the go for Applying Domain-Driven Design.

by luisabreu | 2 comment(s)

Filed under: Books

Two UpdatePanels on a page…
Wed, Aug 16 2006 11:02

Yep, I’m still in vacations…since I’ve been answering one or two posts in the ATLAS forums, I’ve though that I should document those little hacks that I mention there here. This might make life easy for the others. As you might remember, I’ve started writing about ATLAS. Though I still haven’t presented the UpdatePanel control (I know I’ll talk about it one day ), I think it’s a good idea to present a solution to a known problem: suppose you have two UpdatePanels on a page and a click on a button placed inside one of the panels should only refresh the second (note the only!). You can easily refresh the second panel by creating a trigger (ControlEventTrigger) on the button placed on the first panel. Well, this will refresh the second panel but the client will also get the HTML of the first panel since the button that started the partial postback is placed on the first panel.

To understand what’s going on, you must understand that during a partial postback, the ScriptManager handles the LoadPostData method in a special way: it tries to find the UpdatePanel “responsible” for the partial postback and marks it as requiring an update. Yes, this also happens to panels which are associated to a trigger. So, what we need is a way to “unmark” that panel as requiring an update. Unfortunately, the UpdatePanel only has a method that lets you force a refresh of its content. So, to solve this, you must use reflection and a non-documented approach. Here’s a demo page that shows what you must do in order to only get the HTML of the second panel:

<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">
   void h(object sender, EventArgs args)
   {
            panel1.GetType().InvokeMember(
               "_requiresUpdate",
               System.Reflection.BindingFlags.Instance|System.Reflection.BindingFlags.NonPublic|
               System.Reflection.BindingFlags.SetField,
               null,
               panel1,
               new object[] { false });
   }
</script>
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
   <title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
     <atlas:scriptmanager runat="server" id="manager" enablepartialrendering="true" />
     <atlas:UpdatePanel runat="server" id="panel1" Mode="Conditional">
        <contenttemplate>
            <asp:Button runat="server" ID="bt" Text="Submit" OnClick="h" />
                <%=DateTime.Now.ToString() %>
        </contenttemplate>
     </atlas:UpdatePanel>
     <hr />
     <atlas:UpdatePanel runat="server" id="UpdatePanel1" Mode="Conditional">
        <contenttemplate>
           <%=DateTime.Now.ToString() %>
        </contenttemplate>
        <Triggers>
          <atlas:ControlEventTrigger ControlID="bt" EventName="Click" />
       </Triggers>
     </atlas:UpdatePanel>
</form>
</body>
</html>

Basically, I'm using reflection to change the value of the private _requiresUpdate field of the panel and setting it to false. By doing this, we're saying that the panel doesn't require an udpate and due to this its contents aren't gonna be sent back to the client.

by luisabreu | 3 comment(s)

Filed under: MS AJAX

ATLAS future: more ramblings…
Tue, Aug 8 2006 3:46

Well, it seems like I wasn’t the only one on vacations…after all, Scott didn’t discard my comment as I initially thought. And he even answered! So, maybe I was a little bit harsh in my initial response and maybe an apology is in order: I’m sorry for being a little hard on you.

Now, back to business… I’m really happy to see that finally someone has managed to give us more info on the future directions of ATLAS. It’s real cool to see that you ARE solving the known bugs and are enhancing the internal pieces of the platform. I only think it would be wise to share your plans since most of us (that have been using ATLAS for some time now) would really like to know why weren’t those bugs fixed on all the CTPs that have been released after their detection. Well, now we know! Thanks for sharing that info with us.

Regarding the toolkit, I do have one question: is it ok to use only the client portion of it? Well, I’ve asked it before and at the time the answer was yes… the problem is that to use the client portion I had to extract at least one javascript file which was used by all the client behaviors introduced by the platform and was embedded on the dll which had the controls. Has this changed in the latest versions of the toolkit? If ATLAS supports two approaches and since I think that many of the controls are only server side wrappers of the client Javascript behaviors, then I think it’s fair to ask for client only usage of these behaviors…

Finally, yes, I do agree with you when you say that one of the advantages of ATLAS is that it has rich support for server and client side approaches…what I meant in my previous post is that currently, the UpdatePanel is getting a lot of publicity which only mentions the advantages of its usage. This doesn’t seem fair to me! Since ATLAS really does have a powerful client model, why don’t you also talk about the disadvantages related with the usage of the UpdatePanel (which are easily solved by using a client side approach)? It’s my opinion…

Btw, comments were disabled on that post since I’ve only started that blog last week and I thought they were enabled by default. I think that now everyone will be able to comment since I think I’ve managed to enabled them on the blog configuration (I hope).

Well, let’s wait for the next CTP!

by luisabreu | with no comments

Filed under: MS AJAX

On vacations, but still reading some posts…
Mon, Aug 7 2006 3:00

UPDATE: well, it seems like my comment is now online. thanks Scott.

Well, you can say that I do read my blogs during vacations (even though I’ll read it only once a week)…

Yesterday, I was reading through Scott’s posts and I’ve found this post: Atlas July CTP and the Latest ATLAS Control Toolkit. Normally, I wouldn’t comment on this kind of posts, but yesterday I was on a good mood and so I decided to add a comment to Scott’s post. I know that Scott is the owner of the blog, but I really didn’t like to see my comment being discarded just because it doesn’t “praise” the ATLAS toolkit control. So I’ve decided to write this post where I’m going to explain why I completely disagree on the path that is being followed by the ATLAS team (at least here I think that the post is safe).

Before going on, there’s something that I must say: I really enjoy ATLAS and I think that it can be a great framework. Having said this, I really think that the team is not doing a good job with all the feedback that is being given by many people which have been using it and I do also disagree with the way the server controls are presented to programmers.

So, why am I not happy with the new release of the ATLAS? Well, for starters, most of the known bugs haven’t (AGAIN) been fixed. Most of them can be easily solved, but the truth is that they’re still there. In fact, if you look at the bugs description, you’ll see that most of them have code that reproduces the problems and most of them have even suggestions on how to solve them. Since many exist since the March CTP, it really makes us think if we should continue to use CTPS and help the team with the bugs (what’s the purpose if they’re not fixed?).

What I’m saying (and I really think that I’m not alone here) is that we want those bugs to be fixed ASAP! I don’t want more controls on the ATLAS toolkit! What’s the purpose of adding any more controls when the basic ones are still broken (like, for instance, the autocomplete extender control)?

Another thing that bothers me (a lot!) is seeing the way the UpdatePanel is presented to programmers…yeah, at first look, it really looks like it “will save the world”! It’s just a pity that the team doesn’t also warn about the disadvantages related with its usage. Hey, I’m not saying that they’re evil; like everything else, there are advantages and disadvantages related with their usage. However, if when you present it, you only speak about its advantages, you’ll get a lot of guys adding panels to a page so that they can update the content of a label (something which, most of the time, can be done with pure javascript, without even performing a postback or, if you need server info, with the help of a web service call).

I can understand the strategy of the team, which is focused on the server side approach. However, I still believe that this is the wrong approach for most of the cases. I guess that building an AJAX page without knowing anything about Javascript or CSS might be appealing...but not something that will work in the long time or if you’re building a real project (no, I’m not talking about the “hello John” kind of page!).

So, what do I want (and I do believe that there are others out there that think like me): we want a good infrastructure without bugs, and only then we will need the so called “cool atlas toolkit controls”. Until you solve those known bugs, please don’t come telling us that there are new cool controls that will do everything for us. Oh, and while we’re at it, most of us are still wondering why you guys have called these last CTPs as bug-fixes (if you notice, you’ll see that the June CTP introduces a bug fix which really introduce other bugs to previous working code – yep, this is on the unofficial bug list post which has been around for some time on the ATLAS discussion and suggestions forum).

by luisabreu | with no comments

Filed under: MS AJAX

Vacation time
Fri, Aug 4 2006 21:28

Well, sorry for not posting in the last few days…the truth is that I’m on vacations on the next two weeks. Due to that, I won’t be posting a lot (sorry, I really need to spend this two weeks without doing anything ). Ok, meantime, if you live on a distant galaxy and still haven’t heard, then the July CTP of ATLAS is out. You can read the release notes here and get the installer here. Though I still haven’t looked at it, I’d say that most of the bugs are there (this sucks guys!)

Btw, if you know Portuguese, then see my screen casts about ATLAS. You can get them here. Ah…it’s time to go back to my vacations! Have fun!

by luisabreu | with no comments

Filed under: MS AJAX

Writing better OO with ATLAS – part IV
Wed, Aug 2 2006 12:34

Today I’ll write about enums and flags. Enumerations are used to define a data type which has a set of finite identifiers. When we declare a variable and set it to an enumeration, we’re saying that the variable can only contain one of the values defined by the enumeration list. Flags are very similar to enums; however, with flags we can combine several elements of the list by using the operator bitwise or or bitwise and.

Here’s an example of how to create and use an enumeration:

Type.registerNamespace( "LA" );
Type.createEnum( "LA.SexEnum", "Masc", 0, "Fem", 1 );

var man = LA.SexEnum.Masc;
alert( man );

As we can see, we start by creating an enumeration by using the createEnum method. The method expects to receive several parameters (the 1^st is always the name of the enumeration; it is followed by several pairs that define the name and their values).

Flags are created by using the createFlags method:

Type.createFlags( "LA.Hobbies", "Soccer", 1, "Reading", 2, "WatchingTV", 4 );

var hobbies = LA.Hobbies.Soccer | LA.Hobbies.WatchingTV;alert( hobbies );

In this case, I’m creating a new variable and we’re combining two values defined on its enumeration list.

Well, as you might expect, you can also list the values (getValues method), parse the value or convert it to string.

by luisabreu | with no comments

Filed under: MS AJAX