«

Ok, so I see the value in extending the native JavaScript types via the Ajax
Library. And I see the benefit from addins a client side framework
accessible through namespaces as well. This all seems to gvie JavaScript
much more utility than before. Great.

But, as far as the ablility to simulate inheritance and interfaces, the
question that keeps popping up in my mind is: "Why would I want to create
objects and instances in my UI?" Every example I look at shows these
features being used to create a business object, but that goes against good
nTier design.

Can someone shed light on a good use for these OO features?

-Scott

the ajax toolkit was designed to be a control extender. to allow control
from multiple vendors a namespace was required. creating symmetry with
..net probably seemed like a good idea (when the project was started
there were several oo toolkits). for writing client code, other then
webservice calls and standardized event hooksups there little there.

this is probably why jQuery has become so popular with MS (at least the
mvc and dynamic data teams). its makes use of javascript features and
concentrates on dom modifications (what you typically do in javascript).

if severside controls are spewing your javascript, the ajax kit is
great, if you are writing client script, then look at jQuery.

-- bruce (sqlwork.com)

Scott M. wrote:
> Ok, so I see the value in extending the native JavaScript types via the Ajax
> Library. And I see the benefit from addins a client side framework
> accessible through namespaces as well. This all seems to gvie JavaScript
> much more utility than before. Great.
>
> But, as far as the ablility to simulate inheritance and interfaces, the
> question that keeps popping up in my mind is: "Why would I want to create
> objects and instances in my UI?" Every example I look at shows these
> features being used to create a business object, but that goes against good
> nTier design.
>
> Can someone shed light on a good use for these OO features?
>
> -Scott
>
>

Hi Bruce,

Are you saying that the OOP facade the the Ajax Library provides was/is
intended primarially for control developers to be able to have their
controls emit code/data to the client and then the client would have OOP
capabilities to deal with that inbound data/code?

If so, that's great, but it does seem to me that, if this is the case, then
most folks misunderstand the proper use for the client libary, as every
example I see shows how to use it to make business objects in the UI, which
isn't good nTier design.

Am I off base with this assesment?

Thanks,

-Scott


"bruce barker" <> wrote in message
news:%...
> the ajax toolkit was designed to be a control extender. to allow control
> from multiple vendors a namespace was required. creating symmetry with
> .net probably seemed like a good idea (when the project was started there
> were several oo toolkits). for writing client code, other then webservice
> calls and standardized event hooksups there little there.
>
> this is probably why jQuery has become so popular with MS (at least the
> mvc and dynamic data teams). its makes use of javascript features and
> concentrates on dom modifications (what you typically do in javascript).
>
> if severside controls are spewing your javascript, the ajax kit is great,
> if you are writing client script, then look at jQuery.
>
> -- bruce (sqlwork.com)
>
> Scott M. wrote:
>> Ok, so I see the value in extending the native JavaScript types via the
>> Ajax Library. And I see the benefit from addins a client side framework
>> accessible through namespaces as well. This all seems to gvie JavaScript
>> much more utility than before. Great.
>>
>> But, as far as the ablility to simulate inheritance and interfaces, the
>> question that keeps popping up in my mind is: "Why would I want to create
>> objects and instances in my UI?" Every example I look at shows these
>> features being used to create a business object, but that goes against
>> good nTier design.
>>
>> Can someone shed light on a good use for these OO features?
>>
>> -Scott