Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Javascript Best Practices Document v1.0

Reply
Thread Tools

Javascript Best Practices Document v1.0

 
 
Matt Kruse
Guest
Posts: n/a
 
      10-11-2005
http://www.JavascriptToolbox.com/bestpractices/

I started writing this up as a guide for some people who were looking for
general tips on how to do things the 'right way' with Javascript. Their code
was littered with document.all and eval, for example, and I wanted to create
a practical list of best practices that they could easily put to use.

The above URL is version 1.0 (draft) that resulted. IMO, it is not a
replacement for the FAQ, but a more practical guide for fixing some of the
problems that commonly get pushed into web sites.

Any comments?

PS: Ignore the formatting. It's ugly, for now

PPS: I know that there are exceptions to many of the 'best practices' in
very specific situations when approached by an experienced author, but the
goal of this document is to help the average joe developer fix common
problems and write more acceptable code.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com


 
Reply With Quote
 
 
 
 
Gérard Talbot
Guest
Posts: n/a
 
      10-11-2005
Matt Kruse a écrit :
> http://www.JavascriptToolbox.com/bestpractices/
>
> I started writing this up as a guide for some people who were looking for
> general tips on how to do things the 'right way' with Javascript.


Good idea! I support such initiative.

Their code
> was littered with document.all and eval,


You're most likely right. The top nr 1 problem with DHTML/javascript
code on the web is still the recourse to document.all. Still today, in
this very newsgroup, a lot of people are still promoting it in the name
of supporting MSIE 4 ... which I think is just stupid. Less than 0.5% of
internet/web users worldwide are still using MSIE 4 and the chances that
some DHTML/javascript stuff can effectively work on MSIE 4 is very slim.
So, I'd recommend to ditch document.all everywhere... including in this
newsgroup.

for example, and I wanted to create
> a practical list of best practices that they could easily put to use.
>
> The above URL is version 1.0 (draft) that resulted. IMO, it is not a
> replacement for the FAQ, but a more practical guide for fixing some of the
> problems that commonly get pushed into web sites.
>
> Any comments?
>
> PS: Ignore the formatting. It's ugly, for now


The formatting is ok for me.


1- I think you should start with something as basic as explaining that
document.all is bad, wrong, deprecated, obsolete, etc..

2- The web standards way to reference a form input element is:

document.forms.namedItem("formname").elements.name dItem("inputname")

http://www.w3.org/TR/DOM-Level-2-HTM...tml#ID-1689064

http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-21069976

http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-76728479

3- "All forms should have a name attribute. Referencing forms using
indexes, such as document.forms[0] is bad practice."
name attribute for form was dropped in XHTML specification. So you may
want to add such nuance/relativity in there.

4- <form name="myform">
<input type="text" name="val1" value="1">
<input type="text" name="val2" value="2">
</form>
will trigger a validation markup error with a DTD strict.

5- "To fix this problem, Javascript needs a hint to tell it to treat the
values as numbers, rather than strings. Subtracting 0 from the value
will force javascript to consider the value as a number, and then using
the + operator on a number will perform addition, rather than
concatenation."
I think you may be in fact teaching a wrong trick. What's wrong with
offering to use parseInt(strValParam, indexParam) to achieve exactly
what you want to achieve... which is converting a string into an integer
or to use parseFloat(strValParam).

6- "This is why 'return false;' is often included at the end of the code
within an onClick handler."
I would remove that sentence. The sentence does not perfectly make
sense. Also, we have no idea what the doSomething() function does exactly...

7- "Often, links will just contain href="#" for the sake of simplicity,
when you know for sure that your users will have javascript enabled."
This is what a lot of people denounce also as bad coding practices. A
link should be a link. A rose should be a rose. And href="#" is just bad
practice IMO.
Addendum: I see that you later discourage that practice.

8- IMO, you do not sufficiently explain why href="javascript:..." is
bad. May I recommend some of the reasons listed here:
http://developer.mozilla.org/en/docs.....29.22_....3E

9- In your "Detecting Browser Versions" section, you may want to give
more references:
- Browser identification approach (aka "browser sniffing"): not best,
not reliable approach
http://www.mozilla.org/docs/web-deve...l#BrowserIdent
- Using Object/Feature detection approach: best and overall most reliable
http://www.mozilla.org/docs/web-deve...jectFeatDetect
- Browser detection - No; Object detection - Yes by Peter-Paul Koch
http://www.quirksmode.org/js/support.html
- Browser Detection and Cross Browser Support (in particular, sections 5
and 6):
http://developer.mozilla.org/en/docs...rowser_Support

10-
"The rules for using document.all are
2. Only fall back to using document.all as a last resort
3. Only use it if you need IE 5.0 support or earlier "
but IE 5.0 supports getElementById. The only possible reason to use
document.all is if you absolutely need to code for IE 4.x. And why would
you want to do some DHTML which would (could possibly) work in IE 4.x?
I don't see a reason for using document.all anymore.

Regards,

Gérard
--
remove blah to email me
 
Reply With Quote
 
 
 
 
RobG
Guest
Posts: n/a
 
      10-11-2005
Matt Kruse wrote:
> http://www.JavascriptToolbox.com/bestpractices/
>
> I started writing this up as a guide for some people who were looking for
> general tips on how to do things the 'right way' with Javascript.

[...]

Have you thought of putting it up as a wiki? That way contributors
build your 'best of' site for you - it might get quite extensive though!

It would be good to have some 'best practice' examples or stubs for
various things - form validation, dynamic HTML stuff getting xml files,
calendars and date pickers, etc. - rather than a plethora of sites with
half-baked solutions.

[...]

--
Rob
 
Reply With Quote
 
Michael Winter
Guest
Posts: n/a
 
      10-11-2005
On 11/10/2005 07:02, Gérard Talbot wrote:

[snip]

> 1- I think you should start with something as basic as explaining that
> document.all is bad, wrong, deprecated, obsolete, etc..


But the all collection is neither bad nor wrong. It can be argued that
it is largely redundant, but even in IE5.x is has a useful purpose
(though not IE6).

> 2- The web standards way to reference a form input element is:
>
> document.forms.namedItem("formname").elements.name dItem("inputname")


What Matt wrote is just as 'compliant'. Read the ECMAScript bindings. It
also benefits from better support (so it is better in itself).

> 3- "All forms should have a name attribute. Referencing forms using
> indexes, such as document.forms[0] is bad practice."
> name attribute for form was dropped in XHTML specification.


So? What's that got to do with anything?

If NN4 (and the like) aren't a consideration (and they needn't be for
client-side form validation), then use an id attribute, or pass
references directly and omit an identifier entirely. However, if a name
attribute is necessary, then use it.

> 4- <form name="myform">
> <input type="text" name="val1" value="1">
> <input type="text" name="val2" value="2">
> </form>
> will trigger a validation markup error with a DTD strict.


If you're writing to an XHTML Strict DTD, but that is arguably worse
than reasonable defiance of the DTD.

> 5- "To fix this problem, Javascript needs a hint to tell it to treat the
> values as numbers, rather than strings. Subtracting 0 from the value
> will force javascript to consider the value as a number, and then using
> the + operator on a number will perform addition, rather than
> concatenation."


I would recommend the unary plus (+) operator instead.

> I think you may be in fact teaching a wrong trick. What's wrong with
> offering to use parseInt(strValParam, indexParam) to achieve exactly
> what you want to achieve...


It's overkill in most cases. The value should have been validated
already, so all that's necessary is to convert the value which the unary
plus operator does very well.

The parseInt function can be very useful when using it to simultaneously
strip non-numeric trailing characters and convert, such as with CSS
length values.

> 6- "This is why 'return false;' is often included at the end of the code
> within an onClick handler."
> I would remove that sentence. The sentence does not perfectly make
> sense.


It makes perfect sense when taken in context.

> Also, we have no idea what the doSomething() function does exactly...


You do know that it's just an example, don't you.

> 7- "Often, links will just contain href="#" for the sake of simplicity,
> when you know for sure that your users will have javascript enabled."
> This is what a lot of people denounce also as bad coding practices.


It's bad practice when that's used outside the scope of a script.
However, if a script generates such a link, then it's not an issue. I
believe that's what Matt was aiming at (notice, 'know for sure'), but
perhaps it should be emphasised as the caveat might not be noticed.

[snip]

I haven't really read the document yet. I'll get around to it at some
point...

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
 
Reply With Quote
 
Dr John Stockton
Guest
Posts: n/a
 
      10-11-2005
JRS: In article <(E-Mail Removed)>, dated Tue, 11 Oct 2005
02:02:23, seen in news:comp.lang.javascript, Gérard Talbot
<(E-Mail Removed)> posted :
>Matt Kruse a écrit :
>> http://www.JavascriptToolbox.com/bestpractices/
>>
>> I started writing this up as a guide for some people who were looking for
>> general tips on how to do things the 'right way' with Javascript.


It will no doubt encourage a bloated programming style.


>5- "To fix this problem, Javascript needs a hint to tell it to treat the
>values as numbers, rather than strings. Subtracting 0 from the value
>will force javascript to consider the value as a number, and then using
>the + operator on a number will perform addition, rather than
>concatenation."
>I think you may be in fact teaching a wrong trick. What's wrong with
>offering to use parseInt(strValParam, indexParam) to achieve exactly
>what you want to achieve... which is converting a string into an integer
>or to use parseFloat(strValParam).


Does unary + not work in the circumstances?

Note that if the actual parameter is a number already, unary + is
essentially a no-op, whereas parseInt will cause a conversion to String
(perhaps 1e+21) and a conversion of that to integer Number, with results
maybe not as intended.

X = 987654321987654321987654321
Z = parseInt(X) // Z = 9

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
 
Reply With Quote
 
Matt Kruse
Guest
Posts: n/a
 
      10-12-2005
Dr John Stockton wrote:
>>> http://www.JavascriptToolbox.com/bestpractices/
>>> I started writing this up as a guide for some people who were
>>> looking for general tips on how to do things the 'right way' with
>>> Javascript.

> It will no doubt encourage a bloated programming style.


Did you read it?

No? I didn't think so.

Your comments are worthless, as usual.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com


 
Reply With Quote
 
Randy Webb
Guest
Posts: n/a
 
      10-12-2005
Matt Kruse said the following on 10/10/2005 11:06 PM:

> http://www.JavascriptToolbox.com/bestpractices/
>
> I started writing this up as a guide for some people who were looking for
> general tips on how to do things the 'right way' with Javascript. Their code
> was littered with document.all and eval, for example, and I wanted to create
> a practical list of best practices that they could easily put to use.
>
> The above URL is version 1.0 (draft) that resulted. IMO, it is not a
> replacement for the FAQ, but a more practical guide for fixing some of the
> problems that commonly get pushed into web sites.
>
> Any comments?


<quote>
Otherwise, it's always a good idea to put a local fall-back page that
will be loaded for users without it disabled
</quote>

"for users with it disabled"

The "What not to do" section on anchors should have a note - or maybe a
seperate page - that explains why you shouldn't do those things.
Including, but not limited, to the negative impacts they can have.

document.all in IE

<quote>
Only use it if you need IE 5.0 support or earlier
</quote>

IE5.0, IIRC, supports gEBI so it should be priort to 5.0

Also, somewhere in there, some type of paragraph or so on innerHTML and
some of it's inherent strength's and weaknesses.

The only major problem with the whole page is the last few lines about
using Libraries which I totally disagree with. A newbe shouldn't be
using tools that they don't understand and the whole page seems to be
geared to some of the newbe mistakes that we were all guilty of
committing at times (and I still do it myself occassionaly).

Libraries are a personal choice and to me people should understand
enough about the language to know when to use a Library not just how to
use it. If all a person ever learns is that if they do this:

DynWrite('someDiv',someHTML);

That the page changes then they never learn and understand the inherent
problems with DynWrite itself (which it does have) and that function
comes straight from the FAQ itself for this group.

Sidenote: The major problem with innerHTML is when the string being
assigned is plain text. innerHTML has been proven, repeatedly, to be
considerably slower that DOM methods or even the IE proprietary
innerText property.





--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?
 
Reply With Quote
 
Randy Webb
Guest
Posts: n/a
 
      10-12-2005
Dr John Stockton said the following on 10/11/2005 4:09 PM:

> JRS: In article <(E-Mail Removed)>, dated Tue, 11 Oct 2005
> 02:02:23, seen in news:comp.lang.javascript, Gérard Talbot
> <(E-Mail Removed)> posted :
>
>>Matt Kruse a écrit :
>>
>>>http://www.JavascriptToolbox.com/bestpractices/
>>>
>>>I started writing this up as a guide for some people who were looking for
>>>general tips on how to do things the 'right way' with Javascript.

>
>
> It will no doubt encourage a bloated programming style.


Before babbling nonsense like that you should, at minimum, at least read
and be familiar with what you are babbling about.

But, where is *your* guide to best practices?

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
 
Reply With Quote
 
Gérard Talbot
Guest
Posts: n/a
 
      10-12-2005
Michael Winter a écrit :
> On 11/10/2005 07:02, Gérard Talbot wrote:
>
> [snip]
>
>> 1- I think you should start with something as basic as explaining that
>> document.all is bad, wrong, deprecated, obsolete, etc..

>
>
> But the all collection is neither bad nor wrong. It can be argued that
> it is largely redundant, but even in IE5.x is has a useful purpose
> (though not IE6).
>


Useful purpose for IE 5.x? Can you elaborate on this? what do you mean...

>> 2- The web standards way to reference a form input element is:
>>
>> document.forms.namedItem("formname").elements.name dItem("inputname")

>
>
> What Matt wrote is just as 'compliant'. Read the ECMAScript bindings. It
> also benefits from better support (so it is better in itself).
>


Better support? Yes, it's possible. I just mentioned a purely web
standards (DOM 2 HTML) way in there. That's all.

>> 3- "All forms should have a name attribute. Referencing forms using
>> indexes, such as document.forms[0] is bad practice."
>> name attribute for form was dropped in XHTML specification.

>
>
> So? What's that got to do with anything?
>


What I was suggesting here is that one can not declare, just like that,
that document.forms[0] is a bad practice when it is a DOM 2 HTML valid
practice in XHTML
and when what you formally recommend implies an invalid (markup code)
practice in XHTML.

Just compare the following 2 quotes/statements:

"All forms should have a name attribute." Matt K.

"HTML 4 defined the name attribute for the elements a, applet, form,
frame, iframe, img, and map. (...) in XHTML 1.0, the name attribute of
these elements is formally deprecated, and will be removed in a
subsequent version of XHTML."
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.10

> If NN4 (and the like) aren't a consideration (and they needn't be for
> client-side form validation), then use an id attribute, or pass
> references directly and omit an identifier entirely. However, if a name
> attribute is necessary, then use it.
>


Yes, id attribute is another way. name attribute can not be the only way
since it implies invalid markup code in XHTML.

>> 4- <form name="myform">
>> <input type="text" name="val1" value="1">
>> <input type="text" name="val2" value="2">
>> </form>
>> will trigger a validation markup error with a DTD strict.

>
>
> If you're writing to an XHTML Strict DTD, but that is arguably worse
> than reasonable defiance of the DTD.
>


Well, what if I am writing in HTML 4.01 strict then? The above code will
be reported as invalid markup by validators. I am repeating myself here.

>> 5- "To fix this problem, Javascript needs a hint to tell it to treat
>> the values as numbers, rather than strings. Subtracting 0 from the
>> value will force javascript to consider the value as a number, and
>> then using the + operator on a number will perform addition, rather
>> than concatenation."

>
>
> I would recommend the unary plus (+) operator instead.
>
>> I think you may be in fact teaching a wrong trick. What's wrong with
>> offering to use parseInt(strValParam, indexParam) to achieve exactly
>> what you want to achieve...

>
>
> It's overkill in most cases. The value should have been validated
> already, so all that's necessary is to convert the value which the unary
> plus operator does very well.
>


I don't agree with you. parseInt function original purpose (specific
purpose, defined task) is to parse a string and convert it into
integers. Isn't it what Matt Kruse' code wanted to specifically achieve
to begin with?
+ is an overloaded operator; it's not even a function.


> The parseInt function can be very useful when using it to simultaneously
> strip non-numeric trailing characters and convert, such as with CSS
> length values.
>
>> 6- "This is why 'return false;' is often included at the end of the
>> code within an onClick handler."
>> I would remove that sentence. The sentence does not perfectly make sense.

>
>
> It makes perfect sense when taken in context.
>


I disagree. It does not make sense within the context, as written
in the document. We have no idea what doSomething() function actually does.

>> Also, we have no idea what the doSomething() function does exactly...

>
>
> You do know that it's just an example, don't you.
>


The provided code is an abstract example. It's not a defined example.
It's not a concrete example, serving a specified purpose.

This page:
https://bugzilla.mozilla.org/attachment.cgi?id=111215
(from bug 44449 at bugzilla)
is a concrete example showing and testing a precise issue.

This example:
http://developer.mozilla.org/en/docs...Best_practices
is a whole concrete example showing, demontrating, accomplishing a
precise, concrete goal, task.

There is no general rule for returning false in a script, in an onclick
event attribute. It all depends on what a script actually does within a
real-live webapge context. The Matt K. document suggests otherwise.


>> 7- "Often, links will just contain href="#" for the sake of
>> simplicity, when you know for sure that your users will have
>> javascript enabled."
>> This is what a lot of people denounce also as bad coding practices.

>
>
> It's bad practice when that's used outside the scope of a script.


I'm sorry: I disagree. It's *_always_* a bad practice in my opinion.
href="#" should never be used anywhere.
Matt K. discourage href="#" but not to the level I would.

> However, if a script generates such a link, then it's not an issue.


.... then a real button describing the purpose of the script should be
used, not a link. A rose is a rose is a rose. A link should be a real
link should be a real link. And a script modifying a DOM tree or a
document structure should be described as such.

"Links that don't behave as expected undermine users' understanding of
their own system. A link should be a simple hypertext reference that
replaces the current page with new content"
J. Nielsen


> [snip]
>
> I haven't really read the document yet.


Well, then, maybe it would be a good idea to do so.

> I'll get around to it at some
> point...
>
> Mike


Gérard
--
remove blah to email me
 
Reply With Quote
 
Michael Winter
Guest
Posts: n/a
 
      10-12-2005
On 12/10/2005 04:56, Gérard Talbot wrote:

[The all collection]

> Useful purpose for IE 5.x? Can you elaborate on this? what do you
> mean...


The getElementsByTagName method is not implemented properly in IE5.x.
Passing an asterisk (*) will always return an empty collection, rather
than one that contains all descendants of the node. The most reasonable
solution is to detect this failure and use the all collection in place.

[Using the namedItem methods of collections, rather than square brackets]

> Better support? Yes, it's possible.


It's guaranteed.

> I just mentioned a purely web standards (DOM 2 HTML) way in there.
> That's all.


Using square brackets /is/ a 'purely web standards [...] way'.

[The name attribute in XHTML]

> What I was suggesting here is that one can not declare, just like that,
> that document.forms[0] is a bad practice when it is a DOM 2 HTML valid
> practice in XHTML


Unless one is iterating through a collection, using numeric indices is
not a recommended practice as changes to markup mandate a change to the
script, whereas using some form of identifier (or direct reference,
which is what I really recommend) does not.

> and when what you formally recommend implies an invalid (markup code)
> practice in XHTML.


As you were told in ciwah, validation is not a goal in itself. There can
be justified reasons for writing invalid markup[1], and using the name
attribute is not going to break a browser if you truly understand how
browsers will be treating the markup. After all, they won't be parsing
the document as XHTML anyway, so use that notation is, at most,
superficial use of an XML-based language. You would be better off
abandoning XHTML as an output format for the time being (for several
years, at least) and using HTML. That is a better use of your time than
worrying about a single attribute.

[snip]

>>> 4- <form name="myform">
>>> <input type="text" name="val1" value="1">
>>> <input type="text" name="val2" value="2">
>>> </form>


[snip]

> Well, what if I am writing in HTML 4.01 strict then? The above code
> will be reported as invalid markup by validators.


For a different reason, yes, which has nothing to do with what we've
just been discussing.

There is no reason to omit the action attribute in actual markup, but
again this is an example to illustrate an entirely unrelated concept;
potential conflicts between concatenation and addition.

[snip]

>> [The parseInt function is] overkill in most cases. The value should
>> have been validated already, so all that's necessary is to convert
>> the value which the unary plus operator does very well.

>
> I don't agree with you. parseInt function original purpose (specific
> purpose, defined task) is to parse a string and convert it into
> integers.


If the string has been validated as a number, which it should have been,
then the only operation that is needed is conversion. The sole purpose
of the unary plus operator is to convert its operand to a number. The
parseInt function, on the other hand, parses only to an integer -
totally different and often not as useful.

> Isn't it what Matt Kruse' code wanted to specifically achieve
> to begin with?


No. Matt describes string to number conversion, not string to integer.

> + is an overloaded operator; it's not even a function.


The addition operator and the plus (+) symbol itself is overloaded. The
unary plus operator is not. That the latter isn't a function is utterly
irrelevant.

[snip]

>>> 6- "This is why 'return false;' is often included at the end of the
>>> code within an onClick handler."


[snip]

> I disagree. It does not make sense within the context, as written
> in the document. We have no idea what doSomething() function actually does.


It doesn't matter what that function does. Matt is demonstrating event
cancellation (specifically, cancelling link navigation). Anything could
be placed before the return statement, including a comment like

/* Some code here */

[snip]

> There is no general rule for returning false in a script, in an onclick
> event attribute.


No, there isn't, but Matt isn't defining a general rule. The heading of
the section is "Using onClick in <A> tags", and returning false in that
context is well-defined.

>>> 7- "Often, links will just contain href="#" for the sake of
>>> simplicity, when you know for sure that your users will have
>>> javascript enabled."


[snip]

> I'm sorry: I disagree. It's *_always_* a bad practice in my opinion.


In markup, I agree with you absolutely, and I wouldn't use it in a
script, either; I wouldn't use a link that's not a link.

The reason why a "#" href attribute value is frowned upon is because is
doesn't do anything. If the script cannot act, for whatever reason, the
user is left with a link that doesn't do anything. This is contrary to
what a link implies. If the script generates the link, and the link's
scripted action can be /guaranteed/ to work, then the usability issue
doesn't imply. The argument now is just whether it's appropriate to use
a link at all.

>> I haven't really read the document yet.

>
> Well, then, maybe it would be a good idea to do so.


I had neither the time, nor the inclination last night to read
through that document and possibly draft my own response. However, I
thought your post needed commenting upon as I felt parts of it were
suggesting changes that were misguided.

Mike


[1] I don't believe that structurally invalid markup is acceptable,
but certain minor violations /can/ be justified. However, I do
advocate that authors should learn and practice writing valid
documents whenever possible.

--
Michael Winter
Prefix subject with [News] before replying by e-mail.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Javascript Disabled Web UI Functionality - Best Practices? Schemed ASP .Net 0 04-22-2008 03:54 PM
Best Codeplex sample for showing best coding practices? John Dalberg ASP .Net 3 11-16-2006 12:07 PM
[ANN] Updated Javascript Best Practices document Matt Kruse Javascript 60 06-13-2006 06:17 PM
best practices using procedure attributes Izvra ASP .Net 0 12-23-2003 09:43 PM
Best sample app for learning best practices, OO & asp.net? karim ASP .Net 0 07-13-2003 04:26 AM



Advertisments