Este curso não se destina, de todo, a ensinar a programar em Java. O que nos propomos
é ensinar alguns pormenores relativos à inclusão de applets Java já criados por outras
entidades, para enriquecer um web site desenvolvido por si.
Um exemplo concreto é o applet acima, da OpenCube, uma empresa americana com uma oferta de applets notável
(embora, diga-se, o applet mais amado por estes lados seja o HelpIndex da empresa
britânica PHD Computer Consultants Ltd.).
O applet acima, de distribuição gratuita, é uma pequena aplicação chamada
"Smooth Scroll Up II". Como todos os applets Java, o espaço na página é
definido pela utilização e parametrização de um tag específico, o tag <APPLET>.
No caso concreto, o código que se usou foi o seguinte:
<applet code="OCVscroll" codebase="." height="100"
width="500">
(seguem-se uma série de parâmetros de controlo)
</ applet>
A primeira linha comunica ao browser o seguinte: (a) vai ser definida uma área dentro
do lexia com 500 pixéis de largura (width="500") por 100 de altura
(height="100"); (b) dentro desta área vai ser corrida uma aplicação
desenvolvida em Java (applet; o browser fará com que o interpretador de Java comece a
funcionar); (c) o código desta aplicação Java pode ser encontrado no ficheiro
"OCVscroll.class" (code="OCVscroll"; a extensão .class, própria dos
applets java, subentende-se), que (d) está no próprio directório do ficheiro HTML que
está a chamar o applet (codebase="."; o "." é a notação para
"default directory", "directório por omissão").
Dentro daquela área, dita "embeded", o que corre não é HTML, é a própria
aplicação Java. O que esta faz depende do código Java no ficheiro
"OCVscroll.class" (neste caso) e dos ficheiros associados, que no caso são mais
3. Todos estes ficheiros deverão ser instalados no servidor, para que os browsers os
possam ir lá buscar e instalar nos computadores clientes, sem o que o applet não
correrá.
Normalmente, os ficheiros ".class" deverão estar no mesmo directório onde
reside o código HTML que os chama ou no directório raiz do sistema (atenção ao
"codebase", neste caso), caso contrário, na maior parte dos casos, por
deficiências de programação, os applets não correrão em modo local.
Outro aspecto relevante é o facto de o nome dos applet ser "case
sensitive", o que quer dizer que quando fizer o upload dos ficheiros ".class" para o
servidor por FTP, tem de se assegurar que o nome dos ficheiros se mantém inalterado, em
termos de uso de maiúsculas e minúsculas.
Após esta linha, que comunica ao browser a afectação de uma área a outra finalidade
que não a interpretação de HTML, seguem-se uma série de linhas com os parâmetros que
permitirão ao applet funcionar para a utilização específica de um dado site. Estes
parâmetros dependem de cada applet e a sua parametrização vem explicada nas respectivas
instruções.
(basicamente, não há nada que se possa fazer com um applet Java que não se possa
fazer com um controlo ActiveX, a tecnologia da Microsoft que utilizamos neste trabalho; a
questão com os controlos ActiveX é que se trata de uma tecnologia optimizada claramente
para o ambiente Windows, enquanto o Java é multiplataforma -- pode sugerir-se que num
mundo que é quase totalmente Windows, este é um pormenor irrelevante, mas a verdade é
que os computadores mais importantes para as empresas a partir de certa dimensão, os que
correm todas as aplicações mais críticas, não funcionam sobre o Windows; e nestes
casos, há muitas situações em que o Java é uma verdadeira benção)
N.B.: embora o FrontPage possua facilidades próprias para a introdução e
parametrização de applets Java, normalmente é mais fácil seguir as instruções que
vêm com os próprios applets (ou, em muitos casos, utilizar as aplicações de geração
de código de parametrização de que estes estão dotados), e depois, copiar o código
produzido directamente para dentro do HTML.
|