część bardziej toretyczna – co z czym jak i po co


WSH

Na przystawkę, żeby pobudzić apetyt, w prosty sposób na sprawdzenie czym się różni cscript od wscript’a oraz czy na prawdę można pisać w dowolnym języku skryptowym:

  • załóż plik z rozszeżeniem .vbs
  • wpisz: WScript.echo "cos tam wpisz - moze standarodwe hello world?"
  • zapisz plik i kliknij na nim z explorera [zakładam, że masz defaultowe ustawienia]

   Powinno pojawić sie na ekranie okienko – message box – z textem
jaki wpisałe[a]ś. Teraz odpal konsolkę [cmd.exe] i ustaw opcję trybu
uruchamiania wscript na konsolowy [wscript //h:cscript]. Jeśli uruchomisz skrypcik jak uprzednio zobaczysz, że na chwilę odpaliło się okno konsoli.
Żeby sprawdzić efekt należy teraz z linii komend uruchomić program –
zupełnie jak normalnego exe’ka – wpisując jego nazwę [może być bez rozszeżenia].
Teraz róznica jest chyba jasna?

Żeby nie ograniczać się tylko do jednego języka – to samo dla JScriptu:

  • załóż plik z rozszeżeniem .js
  • wpisz: WScript.echo ("cos tam wpisz - moze standarodwe hello world?");

   Ponieważ dopiero co wscript był ustwiony na tryb konsolowy lepiej uruchomić plik z linii poleceń. Jeśli nazwałeś plik tak samo jak poprzedni – nie zapomnij dodać rozszeżenia.
To tyle testów na razie. Przejdźmy do tego co i jak działa.

   W słowniczku

znajdują się objaśnienia podstawowych skrótów [polecam zajrzeć], gdzie zawsze można zajrzeć, jesli coś staje się niejasne. Teraz krótko o idei jak to wszystko działa, żeby te definicje ze sobą pokleić.
Idea jest bardzo przyjemna – można ją porównać do klocków lego… albo
lepiej – do małego programu z dużą ilością plug-in’ów [jeśli ktoś
jest purystą językowym to proszę bardzo – wtyczek. ale niech dalej
nie czyta albo się nie czepia… :P ]. Tym programem jest WSH, który ma
swoją specyficzną budowę i dostarcza własnych funkcji. Za wykonanie funkcji
zaczynających się od 'WScript.’ odpowiada właśnie on:

WScript.echo "tą funkcję obsłużył WSH 'sam w sobie'"

Na tym opiera się cały szkielet pisanych skryptów, ale
nie daje w zasadzie żadnych możliwości.

Oczywiście 'echo’ nie jest jedyną funkcją jaką obsługuje WSH! Powninenem zacząć od tego, że WSH ma budowę obiektową, opisaną przez
WSH object Model. Ponieważ WSH to tak na prawde cztery podstawowe obiekty COM, czyli kontrolki activeX, można ten model rozszeżać o własne kontrolki.

Ponieważ jednak nadaliśmy naszemu plikowi konkretne rozszeżenie – standardowo vbs lub js –
mamy pełne mozliwości jakie daje nam wybrany język skryptowy, za pośrednictwem odpowiedniej biblioteki

Dim i
i = 10

za interpretację tego kawałka odpowiedzialny jest parser VBasic
Script Edition
. Jeśli zdecydujemy się pisać w JScripcie deklaracja powinna wyglądać odpowiednio inaczej.
…no dobra trochę oszukałem. Tak na prawdę to nie jest do końca w ten
sposób, ale zrozumienie takiej idei w zupełności wystarczy i nie
jest to zbyt odległe od prawdy.

ADSI (wstęp)

Ciekawsze i tak się dopiero zaczyna. Jeśli chce się sprawdzić jakieś
dane użytkownika w domenie należy odwołać się do Active Directory. Do
tego stworzony jest interface – ADSI, co można porównać do plug-in’a:

Dim oDomain
set oDomain = getObject("LDAP://pjwstk.edu.pl/DC=pjwstk,DC=edu,DC=pl")

W tym momencie utworzony zostaje obiekt, którym będzie można manipulować za
pomocą interface’ów ADSI. Skąd wiedział, że to ma być taki właśnie obiekt? A
napisane jest „LDAP://” ? [więcej będzie w dalszej części]

Do bazy użytkowników w w2k można się dostać za pośrednictwem dwóch
providerów – WinNT oraz LDAP [za chwilę będzie więcej]. Jeśli potrzeba modyfikować userów na
serwerze Novell’owym należy użyć providera NDSu [nie mam takiego servera ani potrzeby, więc nie testowałem].

Proste.

jeszcze trochę o obiektach

W podobny sposób można tworzyć obiekty przeróżnych typów – ich
obsługą zajmą sie odpowiednie biblioteki – czy będzie to plik bazy
danych czy Excel’a. Po to właśnie są interface’y. Oto krótki przykład jak za pośrednictwem ActiveX można działać na plikach
Excel’a:

set oExcel = wscript.CreateObject("Excel.Application")
oExcel.workbooks.open("C:temptest.xls")
WScript.echo oExcel.ActiveSheet.Cells(1,1).Value
oExcel.quit

W powyższym przykładzie WSH za pośrednictwem tzw kontrolek ActiveX –
czyli interface’u ActiveX – otwiera plik przygotowany w Excel’u,
oraz wypisuje wartość pierwszej komórki na ekran. Od razu powiem, że
dzięki podobnej metodzie można stowrzyć całościowy raport w Excelu razem z wykresami itp etc. dzięki czemu można np. pisać skrypty generujące statystyki dotyczące naszej domeny.

ADSI – Schemat Management

Zanim zacznie się pisać skrypty modyfikujące cokolwiek, warto, by
wiedzieć co wogóle można modyfikować. Aby dowiedzieć się jakie
atrybuty posiadają obiekty w ActiveDirectory należy wykonać dwie czynności:

  • – zarejestrować bibliotekę %systemroot%system32schmmgmt.dll [regsvr32 %systemroot%system32schmmgmt.dll]
  • – uruchomić snap-in’a do schemat management’u [%systemroot%system32schmmgmt.msc]

Po krótce co tam widać:
Wypisane są tam wszyskie klasy [Classes] oraz atrybuty [Attributes]
dostępne w schemacie dla danej domeny. Jeśli chcemy zobaczyć co możemy
zrobić z userem należy rozwinąć ’Classes’ i kliknąć sobie
obiekt ’user’. Po prawej stronie wyświetlą się wszystkie
atrybuty dostępne dla danego obiektu.

Każdy atrybut ma pięć cech:

Name: Ni mniej, ni więcej jak nazwa atrybutu
Type: Może być 'Mandatory’ lub 'Optional’. Artybuty typu Mandatory [obligatoryjne] są wymaganym minimum podczas tworzenia obiektu. Np – możemy nie ustawiać imienia usera, ale musimy podać jego samaccountname – czyli nazwe obiektu SAM [Security Account Manager Name].
System: Czy jest atrybutem systemowym czy nie… do końca jeszcze nie wiem co to jest, ale wydaje mi się, że jeśli schemat zostanie
rozszeżony o jakieś klasy to klasy te nie będąc systemowymi będą oferować niesystemowe atrybuty… ale jest to kolejna z zagadkowych nazw 'microsoft tm’.
Descryption: Beznadziejny, niewiele mówiący opis atrybutu
Source Class: Jako, że jest to w pełni obiektowe, klasy mogą implementować inne klasy – to pole pokazuje z jakiej klasy dziedziczony jest dany atrybut.

Aby dowiedzieć się więcej na temat atrybutu możemy go sobie poszukać
w części ’Attribiutes’ i poza jego nazwą i durnym opisem
możemy sprawdzić coś całkiem ciekawego: ’Syntax’, co jak
często się zdarza m$ jest nazwane dość myląco – jest to po prostu typ zmiennej.

WSH nie potrafi sobie radzić ze zmiennymi typu 'Large Integer’. Pomimo, że w dokumentacji jest np. funkcja CLng
konwertująca do Long’a. Jak się okazało po głebszych poszukiwaniach – VBScript nie obsługuje 64bit Integer’ów.
Próba wyświetlenia parametru tego typu spowoduje błąd. Przykład:


    set oUser=("LDAP://moja.domena.com/CN=user,CN=user,DC=moja,DC=domena,DC=com")
    WScript.echo oUser.lastLogon
    

spowoduje błąd:

    [ścieżka do pliku](nr linii, nr wiersza) Microsoft JScript/VBscript runtime error: Type mismatch
    

Zmienne tego typu można wyświetlić pisząc:

    WScript.echo oUser.lastLogon.lowPart&oUser.lastLogon.highPart
    

niestety nie doszedłem do tego jaki to jest zapis (jak to przeliczyć) i
jak to w takim razie zapisać. Żeby to zrobić trzeba albo znaleść jakiś gotowy interface, albo zapomnieć o tym ;).

LDAP czyli ADSI w praktyce

To, co najmniej przyjemne, może
stać się jedną z przyjemniejszych rzeczy. Mówię oczywiście o porównaniu
tych najbardziej repetytywnych czynności administracyjnych jak np.
zkładanie kont, a pisaniu wszelkiego rodzaju skryptów, które zrobią
to za nas. Aby zobaczyć jakim darem jest ADSI zacznę od przykładu związanego z zarządzaniem użytkownikami.
Dostęp do Active Directory można uzyskać za pomocą jednego z dwóch interface’ów ADSI – LDAP oraz zachowany ze względów kompatybilności – WinNT.

Którego providera używać – WinNT czy LDAP? No i to jest jeden z tych
zawikłanych problemów, na który najstarsi górale nie potrafią odpowiedzieć jednoznacznie. Żaden z
interface’ów nie ma pełnej [czyt. 100%] funkcjonalności. Active Directory jest bazą zgodną z LDAP, poza tym interface
LDAP daje więcej możliwości, więc poleciłbym używanie właśnie jego. Jednak pewne
rzeczy, które są bardzo proste za pomocą i. WinNT, wymagaja więcej
wysiłku przy użyciu i. LDAP… No i pozostaje kwestia wydajności – ze względu na pierwotne przeznaczenie LDAP jest
bazą zorientowaną na odczyty. W pewnych przypadkach może okazać się, że WinNT jest sporo szybszy – co może mieć znaczenie, zwłaszcza w rozbudowanej domenie.


Punkt pierwszy nawias okrągły zamykający kropka

Żeby nie odbiegać od przyjętych norm, zacznę od początku. Chcąc
operować jakiegoś usera, trzeba wiedzieć jak go znaleźć, gdzie i jak
się czegoś o nim dowiedzieć… oj. po kolei.
Pierwszą rzeczą, którą trzeba zrobić to odpalić ADUAC. W ’Active Directory Users And Computers’ bardzo ładnie widać całą
strukturę domeny. Osoby, które miały okazję popracować na wNT4.0, w
której cała struktura sprowadza się do idei placka ziemniaczanego, będą
potrafiły w pełni docenić nowy image domeny. W końcu wszystko jest
poukładane logicznie i fizycznie i możemy ten układ w zależności od potrzeb modyfikować.
W Active Directory:

  • są dwa podstawowe rodzaje obiektów – kontenery i … niekontenery. Kontener jest obiektem grupującym.
    • Kontenery dzielą się na: OU [Organizational Units czyli Jednosktki Organizacyjne] oraz CN. Tu pierwsza niespodzianka –
      CN czyli Common Name to oznaczenie zwykłych obiektów. Ale jest rodzaj kontenera, który jest 'po prostu kontenerem’ i ma
      właśnie oznaczenie CN. To nie moja wina.
  • oraz różne inne obiekty róznych klas widoczne pod nazwą CN.

Ja bym nie zrozumiał o co mi chodzi, więc bardzo szybciutko przykładzik, zanim się ktoś załamie:

LDAP://chlewik.com/CN=pysiaczek,CN=users,DC=chlewik,DC=com

W tym zapisie widać wszystko co trzeba, czyli po rokładzie gramatycznym zdania mamy następujące częsci mowy:

  • LDAP – które pokazuje, że będziemy się posługiwać protokołem LDAP, bo z tego co pamiętam o to mniej-więcej chodziło.
  • :// – oznacza 'to co wcześniej, to była nazwa protokołu’. Chyba dobrze, że wymyślono taki ładny krótki znaczek na tyle skomplikowanych słów.
  • chlewik.com – tą część można pominąć jeśli mamy w ustawieniach TCP/IP odpowiedni sufix domeny.
    Generalnie, czy to dla sportu, czy dla nabrania dobrych nawyków – polecam pisać.
  • / – czyli slash. Po polsku znak dzielenia i to własnie robi – oddziela jedną część zapisu, od innej, która już będzie znaczyć coś innego.
  • CN=pysiaczek – to user o którego nam chodzi. LDAP był protokołem wymyślanym przez kulturę zachodnią, dla tego zapis mamy od lewej do prawej. CN, że pozwolę sobie przypomnieć to Common Name i w tym przypadku oznacza ostateczny liść drzewa. [Oh. dla niewtajemniczonych ta botaniczna metafora jest standardowa i nie jestem jej autorem. W każdym razie AD ma budowę drzewiastą, kontenery są gałęziami, a na końcu najsmaczniejsze, czyli obiekty-liście]
  • , – przecinek. to taki slash tylko troche mniejszy.
  • CN=users – to nazwa kontenera. Tutaj CN pojawia się, jak widać, w innym kontekscie. To niezbyt
    dobre słowo na tą okazję [w tym przypadku CN sam stanowi część context’u] więc może tak: CN w tym przypadku
    oznacza nazwę kontenera
    . Kontener 'Users’ jest standadrowo zakładanym w AD [w ang wersji, żeby nie było niejasności. nigdy nie widziałem polskiej więc nie wiem :P] i będą się tam defaultowo pojawiać konta userów i grup.
  • , – kolejny przecinek.
  • DC=chlewik,DC=com – DC czyli Domain Controler. AD [domena] ma strukturę drzewa i zapis bardzo ładnie się tu przekłada. Jest to nazwa korzenia – czyli nazwa domeny. Ktoś mógłby zapytać, po co trzeba było wcześniej wpisywać 'chlewik.com/’
    skoro jest to tu teraz napisane jak byk. Mógły. I nie uzyskałby odpowiedzi. Nie odemnie.

Jeśli porówna się to co jest wyżej, z tym co widać w ADUAC, to nie powinno być problemu z zapisaniem ścieżki jakiegokolwiek obiektu w AD. Skoro więc już jesteśmy spakowani, można ruszać w dalszą drogę.
Warto byłoby teraz się czegoś o tym obiekcie dowiedzieć:

set oUser=getObject("LDAP://chlewik.com/CN=pysiaczek,CN=users,DC=chlewik,DC=com")
WScript.echo oUser.cn&" "&oUser.name&" "&oUser.email

generalnie w wscripcie nie trzeba pisać 'set’, żeby np. nadać
stringowi jakąś wartość. 'Set’ używa się, kiedy słowo – np. oUser –
ma się stać odniesieniem do obiektu. Funkcja getObject jest na tyle
sprytna, że na podstawie dalej występującego „LDAP:” wie jakich
mechanizmów użyć, żeby się do tego obiektu podbindować [dołączyć].
Następnie można wypisać kilka informacji na temat danego usera. Skąd
wiedzieć jakie dany obiekt ma atrybuty – było trochę wyżej.

Punkt drugi nawias okrągły zamykający kropka

Zanim zaczniemy coś zmieniać jeszcze jeden szczegół, na który warto
zwrócic uwagę – jak to bywa z obiektami, mają swoje atrybuty i
metody. Dla tych, którzy nie mają pojęcia co to znaczy – pola
informacyjne [np. imię] oraz funkcje dla obiektu [np. zmień hasło].
Podstawowymi metodami są 'get’ i 'put’, które można wywołać dla
niemal wszystkich atrybutów. Np. jeśli chce się pobrać lub zmienić imię powinniśmy wykonać:

wscript.echo oUser.get "name"
oUser.put "name", "Zdzichu"
oUser.setInfo
wscript.echo oUser.get "name"
oUser.setPassword "nowehaslo"
oUser.setInfo

Jeśli przewiniesz skrawek w góre, to zobaczysz

WScript.echo oUser.name

Uprzedzając pytanie: taka forma jest również poprawna, a to dla
tego, że w momencie, gdy odwołujemy się do atrybutu tak jak do
metody, niejawnie wywoływana jest metoda 'get’ lub 'put’.

oUser.get "name" to to samo co oUser.name
oUser.put "name","cos" to to samo co oUser.name="cos"

Kilkukrotkie pisząc w VBS dla IISa zdażyło mi się, że oUser.attrib=”t” zwracało błąd, podczas, gdy oUser.put
„attrib”,”t” działało. Nie wiem czy błąd leżał po mojej stronie
czy jest to jakiś 'ficzer baj disajn’. Pozostawię to jako info bez komentarza.

Kolejną rzeczą na jaką trzeba zwrócić uwagę to metoda 'setInfo’. Ta
niepozorna metoda to dość znaczący mechanizm. W skrócie mówiąc [pisząc?], ze
względów optymalizacji, wszelkich operacji dokonujemy na zcache’owanej informacji o obiekcie.
Dopiero metoda 'setInfo’ powoduje, że wszelkie zmiany są update’owane w domenie. Dzięki takiej organizacji
ogranicza ilość przypadkowych zmian a co za tym idzie – operacji zapisu do AD.Tu
oczywiscie również nie obejdzie się bez ciekawostek. Gdyby spróbować
założyć konto usera, poustawiać wszystkie atrybuty, zmienić hasło etc,
po czym na końcu wykonać 'setInfo’, konto zostanie utworzone,
ale bez hasła… możliwe, że również bez kilku innych rzeczy ale nie wnikałem aż tak głeboko.
[nie ma to jak żetelna informacja, co?]. A to z tego powodu, że pewne
metody, pomimo, iż wykonywane są na zcache’owanej kopii, coś tam
sobie sprawdzają bezpośrednio w AD. Dokładny mechanizm nie jest
mi znany i nie znalazłem jak do tej pory artykułu, który by to
technicznie wyjaśniał. Pozostaje najstarsza z metod – prób i
błedów – i mam nadzieję, że ją trochę ułatwiłem.

Punkt trzeci nawias okrągły zamykający kropka

Po co się wogóle babrać w tym wszystkim? Przykładowy scenariusz:
tydzień do zajęć a listy kont userów nie ma… dzień do zajęć…
pierwszy dzień zajęć h8:00… 9:00… o h10:00 ktoś w sekretariacie się
budzi, że warto, by chyba przesłać listę nowych użytkowników. Masz
w ciągu 10min pozakładać konta ze wszystkimi danymi*. heh. Masz
dwa wyjścia – jedno to WScript, a drugie przez okno [through windows?].

*wszelkie zdarzenia i osoby są przypadkowe (;

Oto źródło pliczku, którego stworzenie zajmuje nieco więcej niż
10min – ale da się zmieścić w 30min.
Lista studentów wygląda mniej więcej tak.
Skrypcik ten powinien być w pełni zrozumiały dla osoby, która zna
trochę VB oraz pilnie przestudiowała cały text. Z ważniejszych rzeczy, na które warto zwrócić uwagę, to
obsługa błedów. W tym skrypcie ona nieco kuleje, ale przypominam, że ma on być zrobiony 'na szybko’.

set ouser=odomain.getobject("user","CN="&es)
if err.number = 0 then

Przed założeniem usera warto sprawdzić czy już takowy nie istnieje, i ewentualnie tylko uaktualnić jego dane. Jeśli próba
podbindowania zwróci nam '0′ – znaczy to, że iście taki użytkownik już jest. Nie dodanie na początku programu linijki
ON ERROR RESUME NEXT’ spowoduje, że jeśli takiego użytkownika nie będzie, błąd będzie różny od '0′,
więc wykonanie programu zostanie wstrzymane.

Podczas obsługi błędów nie wolno również zapominać o ’err.clear’,
ponieważ nie jest w żadnym razie robione automatycznie, co spowoduje propagację błędu. Przykład:

ouser.name="kaźmiesz"
if err.number <>0 then wscript.echo "błąd nadawania imienia"
ouser.setPassword "masło"
if err.number <>0 then wscript.echo "błąd ustalania hasła"
ouser.setinfo

Ten krótki skrypcik pokazuje dwa podstawowe błędy:

  • po pierwsze w razie, jeśli błąd powstanie podczas nadawania imienia,
    zostanie wypisany komunikat zarówno o źle nadanym imieniu, jak i haśle. Błąd jest obsłużony nieprawidłowo, ponieważ powinna się
    pojawić zaraz potem linijka ’err.clear’ aby zapobiec propagacji błędu.
  • Drugi błąd to taki, iż informacja o błędzie pojawi się
    najprawdopodobniej po wykonaniu 'setInfo’, ponieważ dopiero wtedy informacja jest tak na prawdę zapisywana w AD,
    i to tam powinna się pojawić obsługa błędu.

I jeszcze dwa tipsy:

  1. jeśli chcesz znaleść opis błędu w MSDNie to raczej przyda ci się wyświetlanie go w postaci hex(err.number)
  2. pomimo operacji xlsf.quit proces excel’a nie zostaje zamknięty pomimo, że tak jest w dokumentacji. To pewnie tak, dla urozmaicenia – świat pełen tajemnic jest piękniejszy.

IIS, ASP i VBS

   Po krótkiej zabawie skryptami dochodzi się do wniosku – 'no fajne. ale ma swoje braki… przedwszystkim brakuje interface’u’. Istnieje rozwiązanie, które nie tylko dostarcza interface dla skryptów, ale daje możliwość korzystania z nich zdalnie – co jest niezwykle przydatne zwłaszcza dla 'mobilnych’ administratorów.
W tym właśnie tkwi największa potęga skryptów WSH – iż można z nich
korzystać zdalnie, przez www i to bez większych problemów – jeśli się już trochę zna WSH. Preferowana konfiguracja to IIS z obsługą ASP. Można oczywiście zainstalować support do PHP dla IIS’a, czy postawić server Apache’a, ale takie zabawy polecam wyłącznie osobom zaawansowanym – zarówno w programowaniu webowym, a zarazem dobrze rozeznanym w systemie operacyjnym.

Jeden malutki przykładzik, który mam nadzieję otworzy wrota waszej wyobraźni:

napisaliście mały skrypcik do sprawdzania danych o użytkowniku.
Fajnie. Umieszczamy go gdzieś w dostępnym miejscu na serwerze domeny
i jak się gdzieś zalogujemy, zawsze można odpalić 'cmd’ i sobie
sprawdzić co trzeba. Fajnie. na pewno? IMHO średnio wygodne – co jeśli jesteśmy poza firmą, powiedzmy na wakacjach, i dzwoni szef, że coś trzeba na gwałt poprawić? można odpowiedzieć, że teraz to się wygrzewam na słońcu, ale to nie należy spodziewać się podwyżki.
A gdyby tak ten skrypt był dostępny poprzez www? Możemy go odpalić z każdego miejsca na świecie, bez mapowań dysków, nie dbając o to w jakiej jesteśmy domenie etc itd… wystarczy przeglądarka.

No i jeszcze jedno: WScript, a zwłaszcza jego czysto 'komandlajnowa’
wersja CScript nie dają możliwości stworzenia żadnego interface’u,
innymi słowy albo będziemy pisać skrypty do skryptów, albo i tak
będziemy musieli się naklepać w klawierkę – bo dobry skrypt ma zazwyczaj tyle parametrów, że cięzko je spamiętać.HTML jest
wyśmienitym kandydatem na uniwersalny, prosty w tworzeniu i obsłudze mechanizm do tworzenie front-end’ów dla skryptów.
Dodajmy do tego możliwości jakie wnosi mechanizm WMI i LDAP i możemy
zrobić wszystko. Dosłownie wszystko – sprawdzać konfigurację kompów w sieci, shutdownować je, zakładać userów etc.

Są to możliwości oczywiście potencjalne, wystarczy tylko je sobie oprogramować…
Hahaha. Ale wysiliłem się na żart, co?

Teraz trochę poważniej:
Oczywiście można oprogramować samemu, ale przynajmniej część można
znaleść jako gotowe przykłady. Ponieważ jednak każdy skrypt trzeba
trochę dostosować do własnych warunków, powinno się wiedzieć
podstawowe rzeczy – co i jak – z tym co w środku – w innym wypadku modyfikowanie 'na ślepo’ najprawdopodobniej nie da pożądanych efektów.

Pierwsza strona w ASP

   Pierwszą rzeczą, którą należy zrobić
jest instalacja i konfiguracja IIS’a. Ponieważ niniejsze paginy poświęcone są skryptom, pozostawię tą kwestię czytelnikowi.

Jeśli ktoś ma już za sobą pisanie pierwszych skryptów w WSH –
powiedzmy potrafi sobie napisać skrypcik wyświetlający jakieś dane o
użytkowniku – to nie ma nic prostrzego niż wystawienie takiego
skryptu via www. Tworzymy pliczek z rozszeżeniem .asp i projektujemy
wygląd strony – czysty HTML – co również nie jest tematem pracy,
którą właśnie czytasz, więc szybciutko prześlizgnę się do części o asp:

<%@ Language = VBScript %>

Wystarczy umieścić takąż włąśnie króciutką linijkę, i już nasz
serwer będzie wiedział, że będziemy na stronie umieszczać kod pisany w VBScript’cie. Oczywiście można zastąpić to tak:

<%@ Language = JavaScript %>
Myślę, że to dobry moment na to, aby spróbować odpowiedzieć na pytanie: ’w jakim języku najlpiej pisać skrypty: w
Javascript’cie, VBScript’cie a może w perlu?
’ Otóż zależy to
wyłącznie od preferencji piszącego. Trzeba jednak pamiętać, iż
poszukując informacji pośród stron w globalnej pajęczynie,
najłatwiej znaleść przykłady napisane w VBscipt’cie. Oczywiście nie
jest problemem przepisanie skryptu z jednego języka na drugi –
mechanizmy pozostają wciąż te same – ale nie każdy musi umieć,
lubić czy po prostu chcieć się w takie rzeczy bawić [łatwiej zrobić ctrl-c, ctrl-v]. Zaletą
pisania w VBS jest jeszcze to, iż jeśli pracujemy nad stroną w asp
zawierającą JS, powiedzmy obsługujący formularz – czyli po stronie
klienta [Client-Side Script]- to od razu widać co jest częścią wykonywaną
po stronie servera [Server-Side Script] a częścią client-side, ponieważ kod S-Ss będzie w VBS a
kod C-Ss będzie w JS. Dzięki temu dużo łatwiej połapać się jaka jest funkcjonalność poszczególnych fragmentów kodu na stronie.

Żeby prosto pokazać różnice pomiędzy skryptem czysto WSH’owym a kodem ASP posłużę się przykładem przedstawionym wcześniej:

<html>
<head>
</head>
<body>
<%@ Language = VBScript %>
<h1>Informacje u userze:</h1>
<%
set oUser=getObject("LDAP://chlewik.com/CN=pysiaczek,CN=users,DC=chlewik,DC=com")
Response.write oUser.cn&" "&oUser.name&" "&oUser.email&vbCrLf
set oUser=nothing
%>

</body>
</html>

Co się zmieniło:

  • po pierwsze jest html. To tak, jakby ktoś nie zauważył :P
  • dodana jest linijka informująca server, że będą skrypty, i że będą one w VBS’ie
  • ponieważ server musi wiedzieć co jest częścią HTML’a a co jest skryptem który ma obsłużyć, kod skryptu oddziela się znakami '<%' i '%>'.
  • zamiast WScript’owego 'wscript.echo' jest teraz AeSPeowe 'response.write'. Zmienił się mechanizm wykonujący skrypt, zmieniła się komenda.
  • na koniec dodałem komendę niszczącą obiekt. Nie jest to wymagane – jest to pedanteria i dobra maniera.

Jak widać trzon skryptu pozostał ten sam.
Będąc uzbrojonym w tak podstawową wiedzę, spokojnie można już zacząć pisać swoje pierwsze strony asp.


   W co jeszcze trzeba się uzbroić?

  • Po pierwsze w cierpliwość. Ta prawie zawsze jest jednym z elementów niezbędnych do osiągnięcia sukcesu.
  • Trochę wiedzy na temat technologii server-side i client-side.
    Wiele osób ma na początku potężny probrem z załapaniem który kod
    co generuje i ogólnym objęciem tematu. Najlepszym zadaniem jest
    napisanie sobie skryptu S-Ss, który generuje skrypt C-Ss. Jeśli ktoś
    coś takiego zrobił i rozumie jak to działa, to chyba pełnia sukcesu.
  • Trochę więcej wiedzy o asp. Jedna komenda to trochę mało (; Ale
    na pocieszenie – dosłownie kilka podstawowych komend pozawala na
    zrobienie większości rzeczy. 95% ASP to tak na prawdę WSH. Dodatkowo są komendy związane z obsługa HTTP, które nie zawsze nas insteresują – w każdym razie nie na początku. Kursów on-line o asp jest dostatek, więc podam tylko link do strony microsoftu a resztę można sobie wyszukać wedle własnej woli i upodobań.
  • Umiejętność konfiguracji IIS’a. Jeśli stronka ma być ogólnie
    dostępna, to trzeba pamiętać, że standardowa konfiguracja IIS’a
    przypomina ser szwajcarski. Zanim udostępnimy swoje skrypty światu warto chociaż odrobinę poczytać o zabezpieczaniu IIS’a.

Dużo?

-o((:: sprEad the l0ve ::))o-