- GKO, luennot 17.-18.9.
- .NET
- Materiaalia
- .net framework sdk, overview
- Tavoitteet (marketing hypea, kritiikkiä...?)
- Oliopohjainen ympäristö, joka mahdollistaa olioiden varastoinnin ja suorittamisen paikallisesti ja/tai verkossa
- Suoritusympäristö, joka minimoi ohjelmiston levitys- ja versiointikonfliktit
- Assembly-paketit, sisältävät metatietoa versioista
- Turvallinen ja hallittu suoritusympäristö (myös tuntemattomalle tai kolmannen osapuolen koodille)
- "Managed code"==virtuaalikoneen kautta ajettu, muistiviitteitä valvotaan, roskienkeruu
- Skriptattuja tai tulkattuja ympäristöjä parempi suorituskyky
- JIT == Just In Time compiling
- Yhtenäistää erilaisten sovellusten ohjelmointia (esim. windows vs. web-sovellukset)
- ainakin kun käytetään Exploreria...
- Teollisuusstandardien tukeminen, integrointi mihin tahansa koodiin
- Komponentit
- CLR (Common Language Runtime)
- "Managed code", frameworkin alla ajettava koodi
- Mahdollisuus käyttää eri kieliä kehitykseen (esim. C#, C++, J#, Object Pascalin .net-laajennukset), käännetään MSIL (MicroSoft Intermediate language)-välikielelle
- [ http://www.jasonbock.net/dotnetlanguages.html ]
- Esim. Delphi 8 on .NET-tuettu. Windows Formsin ohella voi käyttää VCL-kirjaston .NET-laajennusta, jossa suurin osa luokista on samat kuin aiemmissa versioissa
- Tästä huolimatta Delphi 8 ei ole yhteensopiva aiempien versioiden kanssa eikä sillä voi kirjoittaa Win32-koodia
- Mainosesitteiden mukaan vanhat projektit saisi VCL.NET:n avulla muunnettua "helposti" uuteen muotoon (ei testattu)
- Moniperintää ei tueta .NET-ympäristössä, ei edes kielissä, joissa se muuten olisi (esim. c++)
- Pohdittavaa: 0nko .NET todella kieliriippumaton, vai onko kyseessä Microsoftin "Common Language" eri syntakseilla?
- Esim. miten funktionaalinen ohjelmointi taipuu .net:iin (ainakin ML-kielestä on .net-toteutus)
- CTS (Common type system) yhtenäistää eri kielten tyypit
- luokkia voidaan periä millä tahansa .net-kielellä kirjoitetuista luokista
- Muistinsiivous, osoittimien piilotus (kuten java)
- framework-koodi käännetään aina JIT-kääntäjällä, joten .net koodin pitäisi periaatteessa vastata suorituskyvyltään natiivikoodia (vrt. uudemmat java-virtuaalikoneet)
- Mahdollisuus käyttää myös vanhaa windows-koodia (COM-komponentit ja DLL-kutsut)
- Luokkakirjasto
- Komponentteja sovelluskehitykseen
- Konsolisovellukset
- Windows-käyttöliittymät (.net-terminologiassa Windows Forms)
- [ http://www.windowsforms.net/ ]
- ASP.NET (ASP-sivuja .NET-palvelinympäristössä)
- ADO.NET (ADO-tietokantayhteydet xml-tuella varustettuna)
- .net-tietokantayhteydet käyttävät omia Provider-komponentteja
- Palvelinkohtaisia provider-komponentteja saatavilla esim. MS SQL- ja Oracle-palvelimille
- OleDB- ja ODBC-yhteyksiä varten omat yleiskäyttöiset providerit
- Web-sovelluspalvelut
- Windows-palvelinsovellukset
- Luokat on organisoitu sisäkkäisiin nimiavaruuksiin (kuten javan paketit)
- Yhdennäköisyys Javan luokkakirjaston (sekä nimi- että toimintatasolla) on häkellyttävä (esim. säiliöluokat)...
- .NET sisältyy vakiona Windows Server 2003:een, valinnaisesti Windows XP:en Service Pack 1:sta ja Windows 2000:een SP 3:sta alkaen. Lisäksi ympäristön voi asentaa Windows 98:aan ja myöhempiin.
- .NET frameworkistä kehitteillä myös avoimen lähdekoodin Linux-versio Mono (novellin sponsoroima). Tästä huolimatta .NET on käytännössä Windows-keskeinen.
- [ http://www.mono-project.com/ ]
- .NET-järjestelmät kommunikoivat keskenään (ja muilla arkkitehtuureilla tehtyjen järjestelmien kanssa) ensisijaisesti Web-sovelluspalveluina. Myös yhteydet COM-komponentteihin ovat tuettuja (molempiin suuntiin).
- Web-sovelluspalvelujen ongelmana heikko suorituskyky ja tuhlaileva verkon käyttö
- .NET ei ole suoraan yhteensopiva EJB- tai CORBA-komponenttien kanssa. Integrointijärjstelmiä on kuitenkin saatavilla (esim. Borlandin Janeva, Open Source -puolelta iiop.net)
- [ http://iiop-net.sourceforge.net/ ]
- Ohjelmisto paketoidaan kokoelmaan (Assembly, yleensä exe- tai dll-tiedosto), muistuttaa javan JAR-paketointia
- Kokoelma sisältää kaikki ohjelman tarvitsemat kirjastot, käännetyt kooditiedostot (.netmodule, vrt. javan .class) ja mahdollisesti resursseja (kuvat yms)
- Kokoelman kirjastoja voidaan pitää myös keskitetyssä välimuistissa (Assembly cache), jolloin eri sovellukset voivat jakaa kirjastoja
- Kokoelmien tarkoitus on ratkaista vanhojen windows-sovellusten dll-versiointiongelmat
- Kokoelmia voidaan ladata web-palvelimelta tarvittaessa (vrt. java web start)
- C#
- Materiaali: C# Builderin C# tutorial (löytyy aloitussivulta)
- Ensisijainen kieli .net-ohjelmointiin
- C# vs java
- Yleiseltä semantiikaltaan lähes identtiset kielet (Dare Obasanjo: C# from java developer's perspective. ks. myös googlella java vs c#)
- [ http://www.25hoursaday.com/CsharpVsJava.html ]
- Pieniä syntaktisia eroja (esim. javan paketit ovat c#:ssä nimiavaruuksia
- Oliopohjainen kieli, ei moniperintää, rajapinnat tuettuja (kuten java)
- c#:ssä on standardi Dispose-rajapinta resurssien vapauttamiseen, jota käyttäjä voi tarvittaessa kutsua itse (javan finalizea joustavampi)
- c# sisältää luetellut tyypit (enum, tulevat java 1.5:een)
- c#:ssä mahdollista määritellä tietuetyyppejä, joiden muistinhallinta perustuu pinoon (javassa mahdollista vain primitiivityypeillä)
- c#:ssä on foreach-lause (vastaava mekanismi tulossa java 1.5:een)
- oma syntaksi propertyjen määrittelyyn
- c++:n tapaan operaattorien kuormitus sallittua
- c# tukee funktioiden argumenttien välitystä viitearvoisena (call-by-reference, javassa vain call-by-value)
- c#-koodissa oleva dokumentaatio XML:ää...
- heitettäviä poikkeuksia ei mainita koodissa (javan throws -lause)
- c#:ssä ei ole nimettömiä sisäluokkia
- c#:ssä voi käyttää c-tyylisiä osoittimia, mutta vain, jos lohko on merkitty avainsanalla unsafe
- roskienkeruu ei siirrä unfafe-lohkon alla olevaa koodia
- metodien määritykseen on Delphin tapaan merkittävä erikseen virtuaaliset (virtual), syrjäyttävät (override) ja yliluokan määrityksen piilottavat (new) metodit
- Esimerkki: C#-stream
- C#-komponentit
- Materiaali
- .net framework sdk, component programming, events
- .net framework sdk, windows forms controls, developing
- Komponenttien luonti ja käyttö
- .NET-terminologiassa Component ja Control tarkoittavat suurinpiirtein Delphin vastaavia: Component on IComponent-rajapinnan toteuttava luokka, jota voi käsitellä lomakkeella (RAD-ympäristössä), Controllilla on lisäksi oma käyttöliittymä
- Tapahtumakäsittely
- Tapahtumat ovat luokkia, jotka on peritty EventArgs-luokasta (vrt. Javan java.awt.Event)
- Tapahtumankäsittelijät merkitään tapahtuman lähettävässä luokassa delegaateiksi (vrt. javan tapahtumarajapinnat)
- delegaatit ovat olioita, mutta vastaavat delphin funktio-osoittimia tai C++:n funktoreita
- Delegaatilla määritellään tapahtumankäsittelijän argumentit
- Käytännössä delegaatit ovat 'syntaktista sokeria' Delphin metodiosoitintyypille
- Tapahtumat merkitään event-avainsanalla ja ovat delegaattityyppiä. Kääntäjä lisää luokkaan kuormitetut += ja -= -operaattorit, joilla asiakasluokat voivat rekisteröidä tapahtumakäsittelijöitä (vrt. javan addEventListener)
- event-avainsanan avulla käyttöliittymä "tunnistaa" tapahtuman ja lisää sen object inspectoriin
- Huom. javan tapaan tapahtumalla voi olla useita käsittelijöitä (huom. delphissä ei ole oletuksena vastaavaa käsittelyä, ellei käytetä Windowsin viestejä tai koodata toiminnallisuutta itse Delphin päälle)
- Tapahtuma luodaan ja tapahtumakäsittelijöitä kutsutaan yleensä On-alkuisissa metodeissa (vrt. javan fire-metodit)
- Delphissä suojatut virtuaaliset metodit (esim. Click, KeyPress)
- Esimerkki: C#-autolaskuri
- Web-sovelluspalvelut (WebServices)
- Materiaalia
- XML:n ohella (tai sen takia) yksi eniten hypetetyimpiä käsitteitä viime vuosina
- W3C:n suositus sovellusten väliseen kommunikointiin verkon yli
- Web-sovelluspalvelu on ohjelmisto, joka käsittelee muualta (yleensä HTTP-protokollalla) tulevan XML-dokumentin (yleensä SOAP-muotoinen)
- Web-sovelluspalvelu määrittää rajapinnan, jonka avulla asiakassovellus voi lähettää sille viestejä. Rajapinta määritellään yleensä WSDL-kielellä
- Web-sovelluspalvelu sijaitsee verkossa, joten käyttjän on tiedettävä palvelun osoite ja portti (käytännössä URL)
- Käytännön sovelluksissa välttämätöntä on myös tekniikka, jolla SOAP-viestit muutetaan funktiokutsuiksi ja toisin päin. Esim. Delphi, Java ja C# tarjoavat tähän helppokäyttöiset komponentit.
- Web-sovelluspalvelut eivät ole (ihmisen luettavia) web-sivuja vaan tarkoitettu sovellusten käsittelyyn
- Ei ole komponenttiarkkitehtuuri (vrt. com, corba) eikä ole tarkoittu korvaamaan niitä, mutta mahdollistaa erittäin joustavan ja yksinkertaisen kommunikoinnin heterogeenisten järjestelmien välillä
- Verrattuna "oikeisiin" komponenttiarkkitehtuureihin huomattavasti yksinkertaisempi ja rajoittuneempi järjestelmä (ei olioita, ei nimipalvelua, ei transaktioita ym, jotka CORBA- tai COM+ -komponenteilla saadaan ilmaiseksi)
- Web-sovelluspalveluihin liittyvät standardit ja työkalut eivät ole lähellekään yhtä kehittyneitä kuin komponenttiarkkitehtuureilla
- Aidosti järjestelmä- ja kieliriippumaton (kiitos XML-viestinvälityksen)
- Erityisesti web-palvelua tarjoavalla komponentilla ei ole tilaa! (kuten web-sivut)
- Jokainen HTTP-kysely on erillinen tapahtumansa, jolla ei sellaisenaan ole yhteyttä muihin kyselyihin
- vrt. komponenttiarkkitehtuureissa päästään käsittelemään yksittäistä oliota pysyvän viitteen avulla suoraan asiakassovelluksessa. web-sovelluspalveluissa tämä ei ole suoraan mahdollista.
- Tilatiedon voi web-sovellusten tapaan kuljettaa esim. osana kyselyjen parametreja
- Delphissä palvelinolioiden luontia ja tuhoamista voi hallita manuaalisesti tRemotable-luokan DataContext-propertyn avulla. Lisäksi web-sovelluspalvelua luotaessa voi määritellä (service activation), luodaanko jokaista kyselyä varten uusi olio vai käytetäänkö samaa, globaalia oliota.
- SOAP (Simple Object Access Protocol)
- ks. soap tutorial
- [ http://www.topxml.com/soap/articles/soapservices/default.asp ]
- viestiprotokolla etäproseduurikutsuja (=web-sovelluspalvelujen käyttöä) varten
- Huom. nimestään huolimatta protokollalla ei ole mitään tekemistä _olioiden_ kanssa
- Soap-viestit ovat XML-dokumentteja
- Koska toimii yleensä HTTP:n päällä, läpäisee palomuurit
- Huom. HTTP:n käyttö ei ole pakollista. Periaatteessa SOAP-viestin voi lähettää vaikka sähköpostilla, kunhan vastaanottava sovellus ymmärtää sen
- Formaali määritys olemassa ainakin tominnasta suoraan UDP-protokollan päällä
- Etäproseduurikutsu ja palvelimen vastaus ovat erillisiä SOAP-viestejä
- Ongelmia: protokolla on nimestään huolimatta melko mutkikas ja raskas käyttötarkoitukseensa nähden
- Esim. yhden kokonaisluvun lähetys ja vastaanotto vaatii kaksi yli 100-merkkistä XML-dokumenttia + HTTP-headerit + TCP/IP-paketit!
- Ks. W3schools, soap tutorial -esimerkki
- Valmiit komponentit piilottavat protokollan toteutuksen, joten ohjelmoijan ei tarvitse yleensä ottaa sitä huomioon
- Kilpailevia (yksinkertaisempia, mutta ominaisuuksiltaan rajoittuneempia) tekniikoita: XML-RPC ja REST-arkkitehtuurityyli -sivuutetaan tässä.
- WSDL (Web Service Description Language)
- ks. wsdl tutorial (w3schools)
- Kieli web-sovelluspalveluiden kuvaamiseen
- Määrittelee sovelluspalvelun tuntemat kyselyviestit- ja vastausviestit parametreineen ja tyyppeineen
- datatyypit XML Schema -pohjaisia
- xml-muotoinen "rajapintamääritys" tai kokoelma funktioiden "prototyyppejä"
- huom. delphi pystyy generoimaan web-sovelluspalveluille wsdl-kuvauksen rajapinnasta. asiakassovelluksia varten wsdl-kuvauksesta voi generoida koodin web-sovelluspalvelun kutsumiseen
- tarkempi käsittely sivuutetaan.
- UDDI (Universal Description, Discovery and Integration)
- Standardi palvelujen kuvaamiseen, etsimiseen ja integrointiin
- "keltaiset sivut" internetissä
- sivuutetaan..
- Lyhyesti: termit _web_ service ja simple _object_ access protocol on nimetty kyseenalaisesti, koska sovelluspalvelut eivät tarvitse www:tä eikä niillä ole mitään tekemistä olioiden kanssa
- Käytännössä web-palvelimet tarjoavat helposti käyttöönotettavan infrastruktuurin sovelluspalveluille, joten termi jäänee pysymään
- Esimerkki: "Where in the world is Sven Svensson" (Anders Ohlsson), ks. myös babelfish
- soaplient.com - eräitä julkisia web-sovelluspalveluja
- [ http://soapclient.com/SoapServices.html ]
- Dokumentointiohjelmat
- Idea: kirjoitetaan dokumentaatio osaksi lähdekoodia ja generoidaan esim. html-sivusto
- Soveltuvat erityisesti yleiskäyttöisen kirjaston dokumentointiin (API-dokumentaatiot). Dokumentaatiosta on helppoa tarkistaa, mitä jokin tietty yksittäinen funktio tekee
- Eivät yleensä sovellu laajempien kokonaisuuksien ja olioiden dynaamisen toiminnan ja suhteiden dokumentointiin
- Esim. javadoc generoi luokkahierarkian, mutta ei luokkakaavioita (tähän on olemassa DocLetteja)
- Sekvenssi- tai tilakaavioiden generointi/käsittely onnistuu yleensä vain kaupallisilla CASE-ohjelmilla..
- Yleisiä dokumentointiohjelmia
- JavaDoc (Javan standardi)
- Lienee kaikille tuttu javan dokumentaatiosta
- Dokumentaation sekaan voi laittaa HTML-koodia
- Mahdollistaa omien muotoilijoiden määrittelyn (docletit)
- C#:n XML-kommentit (C#:n standardi)
- Luo XML-muotoisen dokumentaation
- Nopeasti katsottuna vaikuttaa JavaDocia rajoittuneemmalta järjestelmältä (XML:n kirjoittaminen käsin osaksi lähdekoodia on tuskaa.)
- XML-ulostulo mahdollistaa periaatteessa käytön eri formaateissa (XSLT-muunnokset) ja edelleen dokumentaation jälkikäsittelyn
- Huom. XML-formaatti ei tue skeeman tasolla millään tasolla ohjelman rakenteita (esim. skeemassa ei ole luokan tai nimiavaruuden käsitteitä, olennaisesti dokumentaatio on vain kasa "member"-tageja, jotka voivat olla mitä tahansa nimiavaruuksista metodeihin)
- => Jälkikäsittely työlästä!
- Doxygen (C++ ym.)
- Perinteinen ja monipuolinen dokumenttigeneraattori, ei tue valitettavasti Delphiä...
- Luo miellyttäviä selattavia HTML-luokkakaavioita
- DIPasDoc (Delphi)
- Ilmainen ja helppokäyttöinen dokumenttigeneraattori Delphille
- Asennettu IT-luokan koneille
- Kannattaa kokeilla omaan koodiin!
- Testataan pääteohjauksissa...
- Asennusohjelmat
- Delphissä mukana: InstallShield (esimerkki?)
- Huom. asettamalla Delphissä projektin asetusten packages-välilehdellä voi määritellä, liitetäänkö kaikki ohjelman tarvitsemat bpl-kirjastot exe-tiedostoon
- jos build with runtime packages on päällä, bpl-tiedostoja ei liitetä
- bpl-tiedostojen liittäminen helpottaa ohjelman jakamista, mutta vie ylimääräistä tilaa, jos useampi ohjelma tarvitsee samat kirjastot
- yleiset delphi-sovelluksiin liittyvät runtime-kirjastot ovat yleensä windowsin system32-hakemistossa
- useimmat sovellukset tarvitsevat ainakin rtl70.bpl-kirjaston, graafiset myös vcl70.bpl:n tietokantasovellukset myös vcldb70.bpl:n, jne..
- käytännössä tarvittavat kirjastot on aina syytä testata koneella, jossa ei ole Delhpiä (tai bpl-kirjastot siirretty tilapäisesti pois system32-hakemistosta)
- ilmaisia asennusohjelmia myös saatavilla, esim. Inno Setup
- Useimmat nykyään käytössä olevat windows-asennusohjelmat käyttävät sisäisesti Windowsin omaa Install APIa, tuloksena MSI-asennustiedosto, joka paketoidaan EXE-tiedostoon (+mahdollisesti Windowsin oman asennusjärjestelmän uusin versio mukaan)
- Java-puolella omat installointiohjelmansa (runsaasti!), esim. InstallAnywhere
- Käytännössä monet java-ohjelmat saa asennettua ilman erillistä installointiohjelmaa JAR/WAR/EAR-pakkauksena
- Esimerkki: laskuriconfiguration
- Tulevaisuus?
- Web-sovellusten ja desktop-sovellusten käyttöliittymäkehitys yhtenäistyy
- Tämä olisi ainakin toivottavaa kehitystä...
- Nykyiset tavat web-käyttöliittymien tuottamiseen (suora html-koodin generointi esim. servletillä tai ulkoasun ja koodin sekoittaminen PHP/JSP/ASP-tyyliin) eivät ole ylläpidettävä tapa eivätkä tue kunnon käyttöliittymäsuunnittelua
- Puhtaisiin web-käyttöliittymiin saatavilla suunnittelutyökaluja (Dreamweaver ym), mutta ne eivät yleensä toimi yhteen dynaamisesti generoidun koodin kanssa. Lisäksi niiden tuki web-standardeille (validi & saavutettava koodi ym) vaihtelee.
- Jo nyt toimiva esimerkki Delphillä
- Web-autolaskuri
- Perustuu Borlandin IntraWeb-tekniikkaan
- Web-lomakkeita voi suunnitella kuten windows-käyttöliittymiä
- Windows-kontrollien sijaan käytetään IntraWeb (IW) -kontrolleja
- Kontrollien tapahtumakäsittelijät luovat JavaScript-tapahtumakäsittelijöitä
- Web-sovelluksen voi ajaa Delphiin sisäänrakennetulla Intraweb-sovelluspalvelimella tai osana oikeaa web-palvelinta (CGI, Apache-moduuli ym)
- Sovelluspalvelin luo lomakesuunnitelman perusteella "sopivan" web-sivun riippuen käyttäjän selaimesta
- Varoitus: generoitu koodi on varsin sekava lomake/javascript-viritys... Dokumentaation lupauksista huolimatta toimivuus eri selaimilla ja käyttöjärjestelmillä voi olla riskialtista
- Korppi-järjestelmän kehittäjä Kurki oli kehitetty IntraWebiä muistuttavalla järjestelmällä ja siinä oli runsaasti selainten välisistä eroista johtuvia käytettävyysongelmia - tästä huolimatta lupaava tekniikka.
- .NET-frameworkin web forms lupaa kehittyneempää tukea tähän suuntaan (ei testattu, joten tästä ei enempää)
- Win98+IE - integraation myötä Web-pohjaiset käyttöliittymät ovat yleistyneet myös Desktop-sovelluksissa, joten yhtenäistyminen kulkee molempiin suuntiin...
- Web-käyttöliittymän saa helposti sovellukseen mukaan Explorer-selainkomponentin avulla
- "fiksut" asiakassovellukset
- "Return of the rich clients"
- [ http://msdn.microsoft.com/netframework/programming/winforms/richclient.aspx ]
- WWW:n nousun ja vakiintumisen myötä on taas/vihdoin havaittu, että kaikkea ei kannata tehdä web-sovelluksina (microsoftilla on tässä toki myös omat intressinsä...)
- Client/Server-malli uusissa vaatteissa
- Tarkoittaa käytännössä itse itsensä päivittäviä ja riippuvuusongelmat ratkaisevia sovelluksia, jotka ajetaan asiakaskoneella (erityisesti käyttöliittymänä voidaan käyttää tällöin käyttöjärjestelmän natiivikomponentteja)
- Tavoite: vältetään perinteisten client/server-sovellusten päivitys/levitysongelmat, mutta saadaan monipuoliset käyttöliittymäkomponentit ja oikeudet hyödyntää käyttäjän koneen resursseja
- Pohjatekniikkana esim. java web start tai .net-assemblyjen lataus verkosta
- Koska lähes kaikissa uusissa sovelluksissa on jo vähintään automaattiset päivitykset, tämä on hyvin pitkälle jo nykyisyyttä..
- Uusi tekniikka asiakassovelluksiin: skriptatut XML-käyttöliittymät
- Materiaalia:
- Lähtökohta: "Web Applications"?
- Peter Paul Koch: Web Applications, promise or hype?
- [ http://www.quirksmode.org/oddsandends/webapplications.html ]
- Ongelma: standardit web-komponentit (myös javascript-käsittelyn jälkeen) ovat rajoittuneita!
- Esim. vertaa WebMailia lähes mihin tahansa (jopa tekstipohjaiseen) Oikeaan sähköpostiohjelmaan! (tämä on tietysti makuasia... :-)
- "Web applications" tarkoittaa web-sivujen toiminnallisuuden laajentamista enemmän desktop-sovellusten suuntaan
- HTML+javascript+xforms...?
- Mac OSX:n widgetit
- DHTML entistä kehittyneempänä?
- Idea: Miksei myös Desktop-sovelluksia voisi määritellä web-sivujen tapaan?
- Lyhyesti: määritellään käyttöliittymä ja tapahtumakäsittelijöiden kutsuminen web-sivujen tyyliin
- Tapahtumakäsittelijöiden koodi on erillisissä komponenteissa (vrt. JSP-sivut, joista kutsutaan JavaBeaneja)
- Mozilla
- Artikkeli: The Joy of XUL
- [ http://www.mozilla.org/projects/xul/joy-of-xul.html ]
- XUL+JavaScript+XPCOM
- XUL == XML User Interface language, alunperin Mozillan käyttöliittymäkieli, sittemmin yleistynyt tarkoittamaan XML-kieliä, jotka on tarkoitettu käyttöliittymien kuvaamiseen
- XPCOM - Mozillan klooni COM-komponenttiarkkitehtuurista
- Javascriptillä tapahtumakäsittelijöistä kutsuttavia komponentteja!
- "Alkuperäinen" XML-käyttöliittymiä hyödyntävä sovellus
- Aiheuttanut valtaisan Plugin/laajennusryöpyn Mozillaan ja FireFoxiin
- Mozillan C++ -kielisen ytimen koodaaminen on harvojen gurujen toimintaa
- XUL/Javascriptin:n käyttö on huomattavasti helpompaa ja turvallisempaa => enemmän kehittäjiä
- Windows Longhorn
- Artikkeli: Code name Avalon...
- [ http://msdn.microsoft.com/longhorn/understanding/pillars/avalon/default.aspx?pull=/msdnmag/issues/04/01/Avalon/default.aspx ]
- Windows XP:n jo nyt ylihypetetty seuraaja
- WinAPI:n korvaaja: .NET:n päällä pyörivä WinFX
- Tullee saataville myös XP:lle ja Windows 2003:lle
- Avalon: 3d-kiihdytetty esitysjärjestelmä ja käyttöliittymäkirjasto
- XAML (Extensible Application Markup Language): xml-pohjainen kieli sovellusten käyttöliittymän määrittelyyn
- Käyttöliittymäkirjasto sisältää Windows Forms -komponentit, mutta varsinaiset Avalon-komponentit ovat taas uusi kirjastonsa...
- Windows Forms-komponentit voivat sisältää Avalon-komponentteja ja toisinpäin
- Avalon-sovellukset muistuttavat Web-sivustoja: "ikkunoiden" sijaan sovellus koostuu skriptatuista lomakesivuista
- Saman sovelluksen voi ajaa työpöydällä tai WWW:ssä (todennäköisesti vain IE:llä, tosin...)
- Indigo: web-sovelluspalveluihin perustuva viestijärjstelmä, jolla longhorn-sovelluksia voi liittää toisiinsa
- yksityiskohdat hukkuivat markkinointimateriaaliin...
- Huom! Longhornin yksityiskohdat tulevat varmasti vielä muuttumaan. Tämänhetkinen virallinen julkaisupäivä on vuoden 2006 puolella ja uusi tiedostojärjestelmä WinFS päätettiin äskettäin jättää pois julkaisuversiosta.
- Teoriassa voitaisiin määritellä yleinen XML-pohjainen käyttöliittymän kuvausformaatti, jota eri sovelluskehittimet voisivat käyttää
- Käytännössä ei onnistu, koska kaikissa käyttöliittymäkirjastoissa (mukaanlukien "cross-platform"-kirjastot) on oma terminologiansa
- Lisäksi kilpailevia XML-käyttöliittymiä on tällä hetkellä _runsaasti_
- Käytännössä olisi viritetty versio windowsin vanhoista RC-tiedostoista...
- Yksittäisten kehittimien/kirjastojen käyttöliittymät ovat usein jo nyt kuvattu XML:nä
- Mahdollinen malli tulevaisuuden hajautettuihin sovelluksiin: palvelinsovellukset Java-pohjaisia (EJB-komponentit, JSP-käyttöliittymät), asiakassovellukset .NET-pohjaisia (Windows forms, Delphi.NET)
- Varmaa: moninaiset tekniikat, komponenttiarkkitehtuurit, kielet, frameworkit, sovelluspalvelimet ja -kehittimet eivät häviä mihinkään, vaan pysyvät edelleen vähintään 'legacy'-sovelluksissa
- Osaava koodaaja pystyy vaihtamaan joustavasti ympäristöstä toiseen, koska pohjalla olevat periaatteet muuttuvat hitaammin kuin päivän muotisanat
- Pohdittavaa: "How Microsoft lost the APi war" (Joel Spolsky)
- [ http://www.joelonsoftware.com/articles/APIWar.html ]