A'ight, usually after a long night flipping pages in SDK references and typing all sorts of word combos into Google, writing, re-writing code and more, I resolve to whimpishly crying out for help. This time I have more than one question, though all in the same context: scripting components.
Okay, sorry for posting these off beat questions. I know they aren't the usual 'Help, my ASP page won't run' and I have posted similar questions on some appropriate mailing lists - so I shall keep this thread updated as answers (hopefully) come my way
- There are basically 2 component types in the MS scripting world relevant for server-side processing, these being .sct, and .wsc. For one, I cannot find any information on their difference or intended difference? For another matter, I accidentally registered the .sct extension with HomeSite editor - now I lost the document types binding for its context menu where I could easilly register/unregister etc. the component. Does anyone know how I can set those context menu bindings again?
- On my Win 2000 Pro machine, I have the latest SDK's installed on just about any ASP complimentary technology. So too, I have the Windows Scripting 5.6. However, although all reference documentation and un/official websites showcase the use of script components using following XML compliant code
Yet, I haven't been able to call an instance of such a component or been able to register it. Following error is always raised upon trying to register the WSC: No scriptlet defined in file. Pretty annoying I think as the old <scriptlet> definition is not XML compliant but works perfectly as shown here:Code:<?XML version="1.0"?> <component id="Error"> <registration progid="Framework.Utility.Error.1.0" classid="{2154c700-9253-11d1-a3ac-0aa0044eb5f}" description="Error Component" version="1.00" /> <public> <method name="getErrLang" /> </public> <implements type="ASP" /> <script language="JScript"> <![CDATA[ /* JScript code here... */ ]]> </script> </component>
Does anyone have a clue what is going on there? I find it pretty annoying knowing that I have the propper script engine running and haven't made any mistakes in the markup. I merely want to use the revised and showcased usage of XML compliant component definitions as they allow more freedom and are more concise IMO (packaging, resources etc.).Code:<scriptlet> <registration progid="Framework.Utility.Error.1.0" classid="{2154c700-9253-11d1-a3ac-0aa0044eb5f}" description="Error Component" version="1.00" /> <implements id="Automation" type="Automation"> <method name="getErrLang" /> </implements> <script language="JScript"> /* JScript code here... */ </script> </scriptlet>- As some alert follower of my rambling might have noticed, the first code example implemented the ASP interface handler so the component has access to ASP objects such as Response, Request et al. The second example, the model I am forced to use currently, implements the Automation handler which does not expose ASP objects. If I try and implement the ASP handler there, following error is returned upon registration: Cannot create interface handler : ASP. Grrrr... I know that the MS documentation is quirky and shows things you sometimes cannot practically do, but hey, this many problems are too much methinks. Anyone know howcome this is (and no, the problem doesn't relate to the former buggy and leaking interface handler implementation for ASP in scripting components that has been fixed with 5.6)? And yes, I know binding the component to one interface handler sort of defies the purpose of COM reusability - also, passing ASP objects as a reference to the component seems to perform better on first tests I have done. Still, I am curious...
- To quote MS reference docs:
Well blimey, but I cannot seem to find out how I can define @transaction directive in my script components. I have virtually seeked all the web for script component implemenation with COM+ transaction services to no avail. All I can find is the same line from MS in a different docs (Scripting 5.6 docs, IIS 5 docs et al). I assume, though I haven't given it a try yet as I just came back home, I could declare my ASP page to be transactional as usual and make handle the OnTransactionAbort, and OnTransactionCommit events as well as oContext.setAbort and oContext.SetComplete methods within the scripting component. However, that looks extremely messy to me (what if I forget to include the @transaction directive in one of my ASP pages that instanciates a transactional component? I could also try whether script components can be adminstered using the component services admin tool where I could set the transaction support. Hmm... Well either way, any pointers or experiences will be much appreciated.Using script components, you can create COM components for a variety of tasks, such as performing middle-tier business logic, accessing and manipulating database data, adding transaction processing to applications, and adding interactive effects to a Web page using DHTML Behaviors.- On a somewhat different matter now, is anyone aware of what is happening to WSH.NET? I only know of DSH 1.1, but would prefer a MS solution even if in beta status. The thought behind using a .NET WSH implementation is that VB.NET supports object pooling and I would love to dabble around to see whether .NET scripts can be pooled too.
p.s. following up on my previous thread and WSC performance: if anyone is interested to know: includes run faster no matter what; VBScript classes or JScript objects instanciated from include libs run a tad slower than sub/function calls and faster than WSC instanciated objects; passing ASP objects to WSC's performs better than implementing the ASP interface handler in your script component; WSC's implementing the ASP interface handler and used as a DAO perform negligably less well than VB6 COM components (only on Win 2000 though).
I started moving my include libs collection to script components some 2 months ago. After some hassle and yet unresolved questions (see above questions), I have concluded - for myself that is - that script components do have substantial advantages over defacto most commonly used include model. While these advantages do not necessarilly compensate for the performance loss incurred by instanciating script component objects, they definately outway the ease of use and potentially offer great advantages for highly configurable frameworks. The idea is, using script components you can construct your web application framework using a true MVC or pull MVC design pattern and virtually achieve the same code reuse and separation from the presentation layer as in .NET. As for the website itself, I do not know many large sites that do not rely on a multi-level caching mechanism or even distributed fragment caching - let's face it, all that is dynamic about dynamic websites is that little static fragments get merged from all over (or the complete HTML page chunck) prior to serving. So I don't have any second thoughts about employing script components as my applications also rely on caching for unbeatable performace. I wouldn't use large include libs, script components or compiled COM's on the live site except if absolutely necessary. Thus, a small site that need not worry too much about performance and scalability, the script components offer a neat way to introduce the site developers to OO/pattern based architectures and n-tier models while leaving all doors open to easilly upgrading their app to compiled COM's or moving it to .NET once .NET matures. For large sites, script components still remain favorable for the framework itself e.g. the content aggregation framework, the asset abstraction classes, the publishing framework etc. All that with good ol' ASP classic which was and still is labeled as a messy scripting solution - I for one love it! Another considerable advantage is that you can create type libraries for your script components and use these for binding WSC events to VB6 apps or, if nothing else, having IntelliSense et al enabled for your script libs in Visual Studio... nifty
Cheers,
.
Bookmarks