XML scriplet v. ASP includes
Martin
scriplet capability? I haven't experimented yet but was curious about this
point. Clearly the scriplets can be used by non-ASP programs. Anything
else?
Robert Edgar
Firstly just because scriptlets can be used for asp and non-asp stuff doesnt
mean that the SAME scriptlet can be used in both situations, in fact it
cant! A scriptlet that implements the asp interface CANNOT be called outside
of IIS enviroment.
ASP includes are easy to construct and dont need to be registered like a
scriptlet so why would you use a scriptlet, what would it give you that you
dont have in an ASP include.
Rob
Martin wrote in message ...
David Pollitt
because
1. the scriptlet author can:-
1.1 expose public members and hide helpers and other intermediates
1.2 control how the client uses or extends the functionality through
callbacks
2. the object syntax provides namespace partitioning so:-
2.1 there is no danger of side effects caused by name collisions
2.2 it's simple to find where the code lives - it's in the scriptlet not
in a nested include
In addition it's a useful intermediate evolutionary stage to coding up
components in a compiled language.
Robert Edgar wrote in message ...
Lee Wexler
insure that our
basic architecture can be scaled up to compiled components when we need to.
While ASP includes are great (and we use them alot)
I think its hard to write them in a disciplined enough way to clearly
encapsulate logic and functionality.
Lee Wexler
EF Multimedia
www.englishtown.com
David Pollitt wrote in message ...
Robert Edgar
from an ASP include.
A scriplet is simply a text file with a bunch of methods in it which has a
declaration section at the top. Its only difference to an ASP include is in
fact the declaration section.
You can be as ill disciplined or not with a scriptlet as you can an asp
include.
As to scalability an asp include is exactly as scalable as your web server
as each request being processed will have its own thread to run the script
in it can make no difference wether that scripts runs in the script page or
in a seperate scriptlet. In fact the scriptlet will present more overhead
not less and as such is theoretically less scalable.
I am interested to hear yours or any one else's views on this as I have been
using scriptlets myself quite extensively for just this purpose but I have
now been instructed to drop all scriptlets and transfer them to asp includes
for the above reasons.
Rob
Lee Wexler wrote in message
<#qWLyAMP#GA....@uppssnewspub04.moswest.msn.net>...
Peter Torr
Robert Edgar wrote in message ...
>I am interested to under stand in what way a scriptlet would be different
>from an ASP include.
Quite different. When ASP sees an #include, it gets the complete text of the
#include-ed file and inserts it verbatim into the original file. It is as if
you had selected all the text from the #include, copied it to the clipboard,
and pasted it into the original source file.
Scriptlets, on the other hand, are COM components. When you say
'Server.CreateObject("bla..")', the scriptlet is instantiated as a component
and you use it exactly as you would use other components or built-in
objects, such as "Request" or "Server". No source code is inserted into your
ASP file; you simply get a reference to a COM object. ASP doesn't know - or
care - what language that code was written in. One good thing about
scriptlets is that, if you need better performance in the future, you can
re-implement the scriptlet in another language (such as C++ or VB) and as
long as you keep the ProgIDs, the GUIDs, and the method names the same, you
make NO changes to any of your ASP code. A component is a component.
A big plus for scriptlets is that you can store scriptlet objects in the
Session or Application object, and they will work across calls. Although you
can store #include-ed ASP JavaScript objects in the Application or Session
object, you cannot call any of their methods, because the script that
contains those methods has been freed. This alone was impetus enough for me
to use scriptlets.
>A scriplet is simply a text file with a bunch of methods in it which has a
>declaration section at the top. Its only difference to an ASP include is in
>fact the declaration section.
You do not do a scriptlet justice. *ANY* bit of source code for virtually
any language can be defined as "a text file with a bunch of stuff in it",
because that's what they are. From a source-level perspective, you are
right. Inside the <script> element of the scriptlet you place stock-standard
JavaScript of VBScript, just as you would with ASP (with, of course, the
surrounding CDATA declaration). But this is not a source-level issue.
One major difference between ASP #includes and scriptlets are that ASP
#includes, by their very nature, can only be used by other ASP files.
Scriptlets, on the other hand, can be used by any COM consumer, such as
Visual Basic, Visual C++, and so on. So, for example, if you develop a
useful scriptlet for your web site, and decide you'd like those features
available from Microsoft Word, you can do that using VBA. No such option
with #includes.
One of the reason scriptlets have those declarations is to determine what is
public and what is private. With an ASP #include, everything in that file
becomes public, and so authors can mis-use private "helper" functions that
are only to be called under specific circumstances or with specific
parameters, etc. With a scriptlet, the only methods / properties you can use
are those that are exposed via the COM interface. Everything else is
private, meaning you get proper data encapsulation (a key OOP concept).
Also, you can have property functions in a scriptlet - something you can't
do in straight ASP. So if you want a property to be read-only, or to be
calculated, you simply create relevant property get and / or put functions
for it in a scriptlet. In ASP, you have to rely on the user to not write to
a read-only property, or else over-complicate the syntax by using methods
(eg, "foo.getName()" instead of just "foo.name").
>You can be as ill disciplined or not with a scriptlet as you can an asp
>include.
This statement is neither here nor there. Anyone can be ill-disciplined with
anything! At least with Scriptlets, by using CreateObject() you get
statement completion, etc. with Visual InterDev 6. No such luck with ASP
#includes, so your coding should be cleaner.
>As to scalability an asp include is exactly as scalable as your web server
>as each request being processed will have its own thread to run the script
>in it can make no difference wether that scripts runs in the script page or
>in a seperate scriptlet. In fact the scriptlet will present more overhead
>not less and as such is theoretically less scalable.
I think this is a dubious position, although here I am not so sure of the
exact situation. Server-side #includes can be troublesome because the server
has to do just that - read in one (or more) additional source files and
parse them each time you request a page (although I'm sure there is some
form of compiled script caching going on). With a scriptlet, once it has
been loaded, the code is immediately available for use by any client,
including multiple concurrent web requests. Sure there are some overheads
involved in the COM IDispatch mechanism, but I don't think this is such a
big deal. The same overheads would apply every time you called any other
kind of component, such as ADO and maybe built-in objects as well (or
perhaps they are optimised?). If scriptlets are managed by MTS (I don't know
if they are) you should get good scalability benefits from component
instance reuse and so on.
>I am interested to hear yours or any one else's views on this as I have
been
>using scriptlets myself quite extensively for just this purpose but I have
>now been instructed to drop all scriptlets and transfer them to asp
includes
>for the above reasons.
There are horses for courses, obviously. For me, scriptlets beat #includes
hands-down because I simply can't do what I want to with #includes.
Eventually, I hope to move most (if not all) my common ASP #includes to
scriptlets (unless someone here convinces me otherwise, of course!).
Please feel free to contradict / correct me here if I am wrong or you
disagree with my opinion.
Peter
--
Peter Torr, Developer / Webmaster, Vantage Systems Australia.
mailto:pt...@vantsys.com.au - http://www.vantagesystems.com.au/
Peter Torr
>Robert Edgar wrote in message ...
>>
>>Firstly just because scriptlets can be used for asp and non-asp stuff
>doesnt
>>mean that the SAME scriptlet can be used in both situations, in fact it
>>cant! A scriptlet that implements the asp interface CANNOT be called
>outside of IIS enviroment.
That just means you are not taking a broad enough view of your component. If
you want your component to be re-usable, you should make the minumum number
of assumptions about its client as possible (none at all, if possible). If
you code your scriptlet to implement the ASP interface, then yes you have
shot yourself in the foot as regards to re-usability outside of IIS.
The solution is not to require ASP objects in your scriptlet. For example,
have any required information (eg, from Request.ServerVariables) passed in
as parameters to methods, and return all results as strings rather than
saying "Response.Write(...)" inside the scriptlet.
Or, you could utilise call-back objects that provided this functionality on
any number of clients, provided they had suitably named properties /
methods.