Bibliotheken möglich?

poeth

Mitglied
Dabei seit
15.07.02
Beiträge
728
Trophäen
[!!!!(!)(!)][**]
#1
Eine Frage an die Scripting-Profis: Ich stelle beim Testen derzeit fest, dass ich immer wieder denselben Code in verschiedene Scripts kopieren muss. Gibt es die Möglichkeit sich Code-Bibliotheken anzulegen, um einzelne Funktionen wiederverwenden zu können.

Grüße
#Poeth
 
Dabei seit
02.12.02
Beiträge
1.546
Standort
Lübeck
#2
Gibt es nicht, selbst Klassen musst Du in den Code kopieren. Allerdings kannst Du eine Art COM-Objekte kompilieren, habe ich aber noch nicht gemacht. Die Dinger müssen registriert werden. Und wir wollen doch nicht den grusligsten Anfängerfehler, den MS je gemacht hat - die Registry - in Anspruch nehmen, das führt das Scripting ad absurdum, da Du dann Installationsroutinen für die Scripte brauchst oder von Hand registrieren lassen musst. Sobald in ein paar Jahren die DotNet-CLR auf allen Rechnern ist, sieht die Sache besser aus.

Gruß Jochen
 

poeth

Mitglied
Dabei seit
15.07.02
Beiträge
728
Trophäen
[!!!!(!)(!)][**]
#3
:( Das ist ja eine ziemliche SCH#!$$#. Da ist das Chaos ja vorprogrammiert!
 
Dabei seit
02.12.02
Beiträge
1.546
Standort
Lübeck
#4
Nicht ganz ernst gemeint :):

Schreibe Deine Standard-Routinen als .cpy.
Schreibe in Deine Scripte COPY-Anweisungen für die Standard-Routinen.
Schreibe Dir ein Startscript, das das Script liest, die Copy-Strecken einfügt und das Ganze als Arbeitsscript niederlegt.
Starte mit dem Startscript anschließend Dein Arbeitsscript.

Fingerübung für Anfänger und funktioniert, aber ob es das Gedödel wert ist?

Gruß Jochen
 

poeth

Mitglied
Dabei seit
15.07.02
Beiträge
728
Trophäen
[!!!!(!)(!)][**]
#5
Welcome back to the early Eighties... DAS muss ich mir noch schwer überlegen, ob ich mir das antue. Andererseits nervt das ewige Kopieren unheimlich und dann erst das

Abklappern aller Kopien, wenn es Änderungen gibt! Aber wem sag ich das?

Grüße
#Poeth
 

W.P.

Mitglied
Dabei seit
16.10.02
Beiträge
5.050
Standort
Anzing BY
#6
Hallo Poeth,

auf die Gefahr, das mich Jochen lyncht :eek::

Arbeite Dich doch mal in die Windows Script Components (*.WSC) ein. Im Prinzip eine Klasse auf COM-Prinzip.

Einziger Nachteil. Um eine Komponente zum Laufen zu bringen, musst Du Sie in der Registry registrieren.

Dabei hilft Dir ein Wizard von Microsoft. Eine deutsche Anleitung (im Zuge von ASP-Sripting) gibt es unter
http://www.aspheute.com/PrinterFriendly/19990828.htm
Dort findest Du auch einen Link zum Wizard auf der Microsoft-Homepage (Microsoft hat ihn etwas vergraben).

Schönen Gruß,

Werner
 

poeth

Mitglied
Dabei seit
15.07.02
Beiträge
728
Trophäen
[!!!!(!)(!)][**]
#7
Hallo Werner.

Danke für die Tipps. Ich kann nur hoffen, dass ich dazu Zeit finde mir das mal näher anzuschauen. Aber was sollte Jochen dagegen haben?  ???

Grüße
#Poeth
 
Dabei seit
02.12.02
Beiträge
1.546
Standort
Lübeck
#8
Werners Intention ist, aus Scripten COM-Objekte zu machen. Das ist relativ einfach und hat den Vorteil, daß ein Script in dieser Form im System bekannt ist und nur einmal vorgehalten werden muß. Man verwendet diese Technik, um Standardfunktionalität im System global zu verankern.
Es ist nicht "eine Klasse auf COM-Prinzip", es wird ein echtes COM-Objekt erzeugt.  
Leider hat Werner anscheinend immer noch nicht verinnerlicht, daß durch die dann erforderliche Registrierung das ganze Elend daran hängt, das diese idiotische Registry-Erfindung mit sich bringt. Das Registrieren und der dazu vorher erforderlich Aufwand ist vollkommen überflüssig, wenn man nicht ein Script mit einer Funktionalität programmiert hat, die systemweit verfügbar sein muß. Und das dürfte in der Regel nicht und im FF-Bereich eher nie der Fall sein. Ein FF-Script in dieser Form ist sinnlos, es wird nur von FF bzw. dessen Anwender benutzt, der Aufwand, der getrieben werden muß, steht im Verhältnis zu annähernd Null Nutzen gegenüber einem normalen Script (ganz abgesehen davon, daß Scripte, die mit FF-Funktionen arbeiten, ohnehin nicht lauffähig wären).
Weitere Nachteile sind, daß bei jeder Klassenänderung mit manuellem Aufwand mangels geeigneter Hilfsmittel immer wieder ein COM-Objekt erzeugt werden muß , also unnützer Aufwand entsteht, daß eine Installation erfolgen muß statt simplen Kopierens, daß einfaches Verschieben nicht mehr möglich ist und das Entfernen des Scripts eine Leiche in der Registry hinterlässt, sofern man nicht für die Installation einen dafür geeigneten Installer benutzt.
Bei aller Begeisterung für programmtechnische Neuentdeckungen, Werner, ist das mit wenigen Ausnahmen ungefähr so sinnvoll, wie sich den bewussten Knopf an die Kniescheibe zu nähen.  

Gruß Jochen
 

W.P.

Mitglied
Dabei seit
16.10.02
Beiträge
5.050
Standort
Anzing BY
#9
Hallo Jochen,

Und das dürfte in der Regel nicht und im FF-Bereich eher nie der Fall sein. Ein FF-Script in dieser Form ist sinnlos, es wird nur von FF bzw. dessen Anwender benutzt, der Aufwand, der getrieben werden muß, steht im Verhältnis zu annähernd Null Nutzen gegenüber einem normalen Script (ganz abgesehen davon, daß Scripte, die mit FF-Funktionen arbeiten, ohnehin nicht lauffähig wären).
Sorry, auch im FF-Bereich sind solche Funktionen sinnvoll, allerdings nicht für kleine Projekte. FF-Funktionen sind allerdings, wie Du erwähntest nicht lauffähig!
Weitere Nachteile sind, daß bei jeder Klassenänderung mit manuellem Aufwand mangels geeigneter Hilfsmittel immer wieder ein COM-Objekt erzeugt werden muß
Quatsch. Im Entwicklungszustand musst Du kein neues Objekt erzeugen! Du kannst im registrierten Zustand nahezu Deine komplette Klasse umbauen und lauffähig halten. Einziger mir bekannter Nachteil dieses Verfahrens: COM-Projekte mögen keine Umlaute im Quelltext. Dies gilt auch für Kommentare! Diese verhindern ein Registrieren bzw. deren Löschung.
Beim Verschieben ist zu beachten, dass das Com-Objekt aus der Registrierung entfernt wird (Rechte Maustaste). Am Zielort ist es neu zu registrieren! Mit gleicher CUID. Es entstehen also keinen NEUEN Leichen.
Bei aller Begeisterung für programmtechnische Neuentdeckungen, Werner, ist das mit wenigen Ausnahmen ungefähr so sinnvoll, wie sich den bewussten Knopf an die Kniescheibe zu nähen.
Ich habe es Dir schon einmal gesagt, aber gerne wieder. FF ist nicht das einzige Softwareprodukt, das Scripting und COM unterstützt! Sicherlich ist zu überlegen, wo man dieses Werkzeug einsetzt. Für wiederkehrende, programmübergreifende Verfahrensweisen ist es jedoch eine schnelle, effiziente Weise portablen Code zu erzeugen, auch JScript mit VBScript oder sonstigen Sprache zu mischen! Normalerweise würde man eine klassische Programmiersprache für solche Objekte wählen. Nur mit Scripting geht's nunmal leichter und schneller und mit wesentlich weniger Systemaufwand (auch wenn er in professionellen Entwicklersystemen durch Assistenten versteckt wird). Ich habe zumindest keine Dateileichen von Dll's, OCX, COM oder EXE rumliegen, die ein diverses anderes Entwicklungssystem ungefragt zurücklässt. Von Registryeinträgen ganz zu schweigen.

Schönen Gruß,

Werner.
 
Dabei seit
02.12.02
Beiträge
1.546
Standort
Lübeck
#10
Hallo, Werner

Sorry, auch im FF-Bereich sind solche Funktionen sinnvoll, allerdings nicht für kleine Projekte. FF-
Die Projektgröße ist vollkommen unerheblich. Wenn Du von vielen Stellen her bzw. aus vielen Anwendungen heraus "Hello, World" auszugeben hast, mag auch die Registrierung eines Einzeilers sinnvoll sein, ansonsten ist es mit möglichen Ausnahmen schierer Unfug. Bei Abwägung des Aufwandes, des möglichen Ärgers, der schlechten Kontrollierbarkeit der Situation beim Anwender usw. kopiert man besser eine Klasse in seinen Quelltext und hat die Sache selber in der Hand.

Quatsch. Im Entwicklungszustand musst Du kein neues Objekt erzeugen!
Spätestens bei Namensänderung, Entfernung, Hinzufügen von Methoden und Properties und wahrscheinlich globaler Public-Variablen muß Deine Komponente neu erstellt werden. Das liegt in der Natur der Dinge.

Beim Verschieben ist zu beachten, dass das Com-Objekt aus der Registrierung entfernt wird (Rechte Maustaste). Am Zielort ist es neu zu registrieren!
Na Klasse. Und wer außer Dir soll das machen? Das bekommt ein Anwender nur hin mit Installer, der auch eine Deinstallationsroutine hinterlässt.

Mit gleicher CUID.
Was nun? ClassID? GUID (Globally Unique Identifier)?

Ich habe es Dir schon einmal gesagt, aber gerne wieder. FF ist nicht das einzige Softwareprodukt, das Scripting und COM unterstützt!
Wer hätte das gedacht.
Komponenten verwenden kann heute wohl jede moderne Software, nur muß der/die Programmierer dazu Methoden und Properties Deiner Komponente gekannt und die Absicht gehabt haben, sie zu verwenden. Eher sehr unwahrscheinlich, daß Microsoft vielleicht auf einen Beitrag aus dem FF-Kreis gehofft hat, von daher kein Registrierungsbedarf ... Wenn Du selber die Absicht hast, Komponenten zu verwenden, benötigst Du ebenfalls keine Registrierung deines Scripts, die vorhandenen Schnittstellen kannst Du auch so anzapfen.
 
Für wiederkehrende, programmübergreifende Verfahrensweisen ist es jedoch eine schnelle, effiziente Weise portablen Code zu erzeugen
Was ist portabler daran, nur weil Du es am System festnagelst? Und wieso schneller, wenn Du zusätzlichen Systemaufwand generierst?

Normalerweise würde man eine klassische Programmiersprache für solche Objekte wählen. Nur mit Scripting geht's nunmal leichter und schneller
Das ist doch nicht wirklich Dein Ernst? Scripting ist so ziemlich die primitivste, umständlichste und nervtötendste Art zu programmieren seit MBasic 3 anno domini 1980. Das kann man als nostalgisches Hobby betrachten, oder man rennt, was einen die Füße tragen. Mit VB6, DotNet-Basic oder C# arbeitet man um ein Mehrfaches schneller und komfortabler.

Von Registryeinträgen ganz zu schweigen
Dann suche mal Deine Registry mit geeigneten Tools ab, Du wirst Dich wundern.

Zusammengefasst:

Registrierung nur bei Notwendigkeit der Zurverfügungstellung globaler Funktionalität.
Nur nach Abwägung, ob es ein normales Script nicht genau so gut tut.
Nur nach Abwägung, ob System- und persönlicher Aufwand gerechtfertigt sind.
Nur wenn es gar nicht anders geht.

Ansonsten ist es bloße Spielerei.

Gruß Jochen
 

W.P.

Mitglied
Dabei seit
16.10.02
Beiträge
5.050
Standort
Anzing BY
#11
Hallo Jochen,

Thema:Registrierung, wenn's Dir Spass macht, kannst Du Dein Com-Projekt manuell im Script registrieren und bei Beendigung diese aus der Registry wieder entfernen. Zwei Aufrufe! Der Müll wird dadurch nicht mehr als wenn Du einmal registrierst. Dann kannst Du Deine Programme jeden Tag verschieben, wenn Du willst.

ClassID: Du kannst Properties, Methoden und globale Variablen hinzufügen, löschen oder umbenennen, es macht im Laufverhalten und Stabilität keinen Unterschied! Selbst ausprobiert. Die ClassID hängt zu einem Teil mit der verwendeten DLL vom Scripting zusammen (Name ist mir gerade entfallen), der Rest mit dem Namen des Objekts, ob für ASP etc. Solange Du kein Event nachträglich einfügst, dürfte sich nicht viel fehlen. Thema Scripting und Event hatten wir ja schon.

Programme: Es ist mir klar, das mit VB6, .Net, oder C# viel mehr sehr schnell erreicht werden kann. Zum einen aber mußt Du das Entwicklungssystem kaufen, WScript wird bei Windows wie Batch bei DOS mitgeliefert. Neue Programmiersysteme laufen nur unter bestimmten Betriebssystemen .Net z.B. ab WinXP. Habe aber keine Lust auf XP upzudaten! Dann versuch doch mal den Inhalt von Word-, Excel-, JPG-, OpenOffice, Corel Designer-Dateien oder sonstiger komerzieller Software das Dateiformat zu lesen, scannen, extrahieren, suchen und in Datenbank speichern etc. Ohne weitere Ausgaben von Toolboxen wirst Du bald Probleme bekommen. Das fängt bei EXIF und Vektorgrafikobjekten an und hört bei XML auf. Scripting ist dagegen implementiert, jedoch nicht immer das von Microsoft. Dennoch können beinahe aus jedem dieser Programme COM-Objekte angesprochen werden! Damit brauchst Du nur noch die Vermittlerschicht zu schreiben und nicht für jedes Programm das Rad neu erfinden. Für Com-Objekte geeignet sind Dinge wie Registry-Routinen, INI-Routinen und Klassen, HTML-Parser, XML-Datenbanken etc. All diese Objekte kann man ebenso in FF nutzen. Ohne Code kopieren (was im Übrigen für spezifische Dinge sehr nützlich ist), ohne Konflikte mit globalen Variablen oder Konstanten.

Festnageln: Jedes moderne Programm wird ans System genagelt! Einschließlich FF! Einschließlich mit VB xy und C yz erzeugten Programmen. Sobald das Programm gestartet wird, eine Datenbankroutine, Systemfeatures, OCXe oder VBXe benutzt werden, hängst Du, ob Du willst oder nicht! Und hör mir mit den Installern auf, die haben bei mir schon mehr Chaos angerichtet, als was gut ist. Infrarot an Me anzuschließen habe ich aufgegeben, trotz Internet-Forum und UseNet!

Wo wir uns einig sind ist: COM-Objekt nur für wiederverwertbare, komplizierte, systemumspannende Aufgaben oder mit hohem Wiederverwendungswert. Oder als Mittler zwischen Sprachsystemen, oder, was ich noch im Hinterkopf habe, als Komponente zur Benutzung im Team bei gemeinsamen Projekten. Dann kann jeder seine bevorzugte Sprache benutzen: JScript, JavaScript oder VBScript, nur die Schnittstellen müssen vorher definiert werden. Und jeder behält sein geistiges Eigentum!

Apropo nervtötend: Wo sind Deine Drahtseile geblieben?  ;)

Schönen Gruß,

Werner.
 
H

Hippo6

Gast
#12
Eine Frage an die Scripting-Profis: Ich stelle beim Testen derzeit fest, dass ich immer wieder denselben Code in verschiedene Scripts kopieren muss. Gibt es die Möglichkeit sich Code-Bibliotheken anzulegen, um einzelne Funktionen wiederverwenden zu können.

Grüße
#Poeth
Vielleicht bin ich ja OT, aber HTML-Editor Phase5 von Meybohm bietet die Möglichkeit sogenannte Includes anzulegen, die als Baustein in Scripte eingefügt werden.
http://www.qhaut.de/modules.php?name=FAQ&myfaq=yes&id_cat=4&categories=Includes#23
Wäre das nicht Lösung (...wenn ich #poeths Problem richtig verstanden habe)
 

Zaph

Mitglied
Dabei seit
13.01.03
Beiträge
191
#13
VBScript bietet von Haus aus nicht die Möglichkeit an, Includeblöcke anzugeben.

Jochen hat diese Funktionalität aber mit seinem Tool "VBSCopy" (im Downloadbereich unter Script-Tools) als sog. COPY-Blöcke nachgebildet.

Grüße Zaph
 
H

Hippo6

Gast
#14
Jochen hat diese Funktionalität aber mit seinem Tool "VBSCopy" (im Downloadbereich unter Script-Tools) als sog. COPY-Blöcke nachgebildet.
Hallo Zaph,
Ich war davon ausgegangen, dass diese Blöcke noch zu erfassen sind und dann wäre das eine hilfsweise Lösung gewesen.

BTW: Ich hab mir gestern deine Scripte auf der Suche nach einer Möglichkeit angesehen, mit der EXIF-Teile als HTML-Baustein in #poeths WegGall-Script importiert werden könnten. CopyEXIF (?) wäre genial dafür geeignet, wenn es für eine Auswahl Bilder als Modul aufgerufen werden könnte und ein automatisch erzeugtes EXIF-HTML aus dem Zwischenspeicher ins HTML der Templates übernommen werden könnte.
Übrigens ganz großes Lob von mir für die sauber programmierten Scripte. Alle Achtung!
 

hkiemes

Mitglied
Dabei seit
04.01.04
Beiträge
65
Standort
Aachen
Trophäen
*
#15
Hallo zusammen,

kann mir jemand erklären wie man die Methoden
FF_CallScript, FF_SetParam und FF_GetParam benutzt.
kann mann damit eventuell ein script aufrufen, das eine
klasse erzeugt und ein object der klasse zurückliefert?
das wäre doch dann eine bibliothek.

Bsp.(so oder so ähnlich):
bibliothek.js:
function test(){
...
return this;
}
FF_SetParam(test());


hauptscript.js:
FF_CallScript(bibliothek.js)
new klasse = GetParam();
...

????
 

JKS

FF-Team
Dabei seit
06.06.02
Beiträge
6.671
#16
Nette Idee, geht so aber nicht. Es kann nur ein (beliebig langer) Text mit FF_SetParam()/FF_GetParam() übertragen werden.
(Es scheitert sicher nicht an Grundsätzlichkeiten, sondern an meinem mangelhaften Verständnis von COM,VARIANTs... kriege nicht mal Arrays übergeben, um den Zugriff auf die Bilddaten zu beschleunigen)
 
Oben