XlF42 Ich glaub', der SF hat seine Lösung schon, daher beantworte ich mal Deine Fragen...
a) trivial
b) Beispiel in C:
void swap ( int *a, int *b )
{
*a = *a + *b;
*b = *a - *b;
*a = *a - *b;
}
ohne Google oder sonstige Literaturquelle
Sie sind in Begriff, Telefon-Treff zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachten Sie, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
XlF42 Ich glaub', der SF hat seine Lösung schon, daher beantworte ich mal Deine Fragen...
a) trivial
b) Beispiel in C:
void swap ( int *a, int *b )
{
*a = *a + *b;
*b = *a - *b;
*a = *a - *b;
}
ohne Google oder sonstige Literaturquelle
Ein CMS einzusetzen nur für dessen Fähigkeit, News einfach eintragen zu können, ist ein wenig mit Kanonen auf Spatzen geschossen...
Es gibt viele reine News-Skripte, eine Suche auf PHP-Skript-, Perl-Skript- bzw. CGI-Seiten sollte da einige zu Tage befördern.
Um nur ein paar Beispiele zu nennen, ohne irgendeine Bewertung hinsichtlich Tauglichkeit (die stammen aus meinen Bookmarks, einer ziemlich wirren Sammlung... ebenfalls keine Garantie, dass es die überhaupt noch gibt...), Qualität o.ä.:
http://www.chuck.uklinux.net/phpNews/
http://www.the-collective.net/~gideon/projects/yapns/
http://amphibian.gagames.com/newspro/
https://sourceforge.net/projects/hotnews/
http://www.brentc.com/inertianews/
http://nune.sourceforge.net/
...
Gruß
Michael
ich hab Deine Seite mit einem Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 (= Mozilla 1.2.1) und einem Opera 6.03 (auch unter Linux) angeschaut und keinen nennenswerten Unterschied bemerkt... bis auf eins: Die Ausrichtung der Ränder der einzelnen Teile des Rahmens klappt beim Mozilla nicht ganz, da sind immer wieder Sprünge drin.
Mein Opera hat offenbar Schwierigkeiten mit den Targets -- wenn man im Menü auf einen Link klickt (die haben target="content"), wird die entsprechende Seite in einem neuen Fenster geöffnet.
Mit Konqueror 2.2.1 sieht's o.k. aus.
P.S. Die Schrift ist bisserl arg klein...
Hallo,
um nochmal kurz das Problem zusammenzufassen:
Du hast zwei Tabellen, und möchtest
1. _alle_ Spalten aus Tabelle 1, mit zusätzlich der Spalte "Zusatzwert" aus Tabelle 2, sofern vorhanden
2. das JOIN-Kriterium ist die Artikelnummer (eine Zeichenkette), wobei diese in Tabelle 2 jeweils noch um " 00" erweitert ist.
Beispiel:
Gegeben seien die Tabellen Table1 und Table2 (hier mal der Kürze halber ohne primary key, erlaubten NULL-Werten etc.)
create table Table1
(
ArtNr varchar (35),
OtherInfo varchar (35)
)
create table Table2
(
ArtNr varchar (35),
AddValue varchar (35)
)
Die von Dir gesuchte Query lautet dann:
Obige Punkte werden mit folgenden Konstrukten gelöst:
1. ein Left Outer Join (die Syntax im Beispiel funktioniert mit MySQL, MS SQL Server und vielen anderen, Oracle hat -- zumindest bis Version 8i, neuere weiss ich nicht -- eine eigene, unlesbarere Syntax :-))
2. bei Join-Kriterium musst Du die "Verlängerung" ' 00' an die Artikelnummer aus Tabelle 1 anhängen, wenn Du mit der Artikelnummer aus Tabelle 2 vergleichst. Auch hier wieder gilt: Die Syntax CONCAT( str1, str2, ...) ist diejenige von MySQL, derartige Funktionen können von Datenbank zu Datenbank unterschiedliche Syntax haben.
Und zum selber ausprobieren noch ein paar Testdaten:
und siehe da, das Ergebnis lautet:
das entspricht zumindest meinem oben beschriebenen Verständnis der Problemstellung
Ciao
Michael
ZitatOriginal geschrieben von void
dann sehen sie nach oben genannter lösung spätestens während des downloads, wo die datei liegt (sofern mich nicht alles täuscht)
und ich halte es immernoch für eine seltsame idee
-void
So wie ich es jetzt verstanden habe, kann es schon Sinn machen. Die Benutzer sollen selbst keinen Zugriff auf den ftp-Server erhalten (wofür z.B. ein Passwort nötig wäre, dieses sollen die Anwender aber nicht erhalten). Also wird Ihnen auf einem Webserver ein Dateiangebot unterbreitet, und sie selbst interagieren ausschliesslich mit dem Webserver. Bei Anforderung einer Datei beschafft der Webserver die Datei vom ftp-Server und liefert sie dann an den Client des Anwenders. Woher der Webserver dabei die Datei holt, ob aus seinem eigenen Dateisystem, aus einer Datenbank, von einem ftp-Server, oder ob er sie frei erfindet :-), bleibt dem Anwender dabei vollständig verborgen.
Zu den bisher angebotenen Links:
* wwwfileshare -- löst eine ganz andere Aufgabenstellung
* pafiledb ist da schon näher dran, legt aber wohl die Dateien im Dateisystem der Webserver-Maschine ab (nicht zwangsläufig in den für den Webserver sichtbaren Verzeichnissen), die Datenbank (bzw. die Alternativversion über Textfiles) dient als Grundlage für die aus ihrem Inhalt generierten Webseiten mit Downloadangeboten. Ich hab mir nur ganz kurz die Beschreibung angesehen, bezweifle allerdings, dass die Dateien auf einem entfernten ftp-Server gelagert werden können.
Ich denke, das Problem ist so speziell, dass entweder die Anforderungen geändert werden müssten :-), oder es doch auf selbst programmieren rausläuft (zum einen brauchst Du dann auf dem ftp-Server ein Skript/Programm, dass Dir die Inhaltsverzeichnisse aufbaut und auf den Webserver legt [ok, das ginge auch per ftp und holen der Verzeichnislistings, aber einfacher geht's direkt im Filesystem des ftp-Servers], zum anderen brauchst Du die Download-Seite auf Deinem Webserver (download.php, oder wie auch immer man sie nennen möchte), die zu einer Ressourcenangabe diese vom ftp-Server beschafft und zum Client überträgt. Falls Du eine Datenbank hast, auf die der Webserver zugreifen kann, kannst Du die Informationen auch in der Datenbank ablegen, und die Webseiten dynamisch aufbauen. Wenn aber der Datenbankinhalt nur in bestimmten Zeitabständen (täglich) aktualisiert wird, und die daraus generierten Webseiten stets gleich aussähen, dann bringt die Datenbank keinen Zugewinn und es ist empfehlenswerter, direkt statische Webseiten zu erzeugen.
Was für ein Betriebssystem hast Du denn auf Deinem ftp-Server?
So, jetzt gehe ich mich auf die Suche nach was Essbarem machen...
Vielleicht solltest Du noch mal erklären, was genau Du willst. Mal sehen, ob mein Verständnis zutrifft:
a) Du hast einen FTP-Server, dessen Dateien Du den Benutzern zur Verfügung stellen willst. Die Benutzer sollen jedoch nicht direkt auf Deinen Server zugreifen.
b) Du hast ausserdem einen Webserver, auf dem ein Inhaltsverzeichnis des FTP-Servers angezeigt werden soll. Dort kann der Benutzer Dateien auswählen und bekommt sie vom Webserver über HTTP, ohne etwas von dem FTP-Server, auf dem die Datei eigentlich liegt, mitzubekommen.
--> Du brauchst folglich auch eine "Downloadseite", die als Parameter einen Schlüssel für die gewünschte Datei (das kann z.B. deren vollständiger Name incl. Pfad sein) nimmt, sich die Datei vom FTP-Server holt (wovon der Benutzer nichts mitbekommt, die Datei kann aus Sicht des Benutzers sonstwo liegen) und dem Benutzer zurück überträgt. Ohne eine solche Downloadseite müssten die Benutzer dann doch wieder direkt auf den FTP-Server zugreifen.
Aber der Sinn ist mir immer noch nicht ganz klar bei dieser Konstellation -- warum legst Du die Dateien nicht einfach auf dem Webserver ab? Oder wird der FTP-Server noch von anderen Applikationen aus genutzt, so dass die Dateien noch aus anderen Gründen dort liegen müssen? Oder hast Du eine zu starke Beschränkung des Webspaces, und auf dem FTP-Server ist mehr Plattenplatz verfügbar?
Zum "ohne ftp-Client funzen" -- moderne Browser können allesamt auch Dateien per FTP empfangen, wenn die Nutzer also Deine Webseite betrachten, nutzen sie höchstwahrscheinlich bereits einen ftp-fahigen Client (und beim direkten Zugriff des Benutzer-Clients auf den FTP-Server sparst Du Dir die Übertragung der Daten vom FTP-Server zum Webserver -- weiss nicht, ob Dein Provider Dir das Datenvolumen berechnet...)
Nun ja, vielleicht habe ich Dein Problem auch komplett missverstanden.
nur eine kurze Anmerkung zu 1) Du kannst prinzipiell nicht verhindern, dass jemand, der Deine Webseite laden kann, auch den Quelltext einzusehen vermag -- schliesslich muss der Quelltext ja zum Client, sonst könnte dieser nichts anzeigen.
In manchen Browsern lässt sich zwar per JavaScript der Rechtsklick deaktivieren, aber es gibt zum einen im Browser noch andere Wege, eine Webseite zu speichern, zum anderen kann der Benutzer JavaScript deaktivieren, und letztendlich -- wer sagt denn, dass der Client ein Webbrowser ist? Könnte ja auch ein anderes Tool (wget, ...), ein Perl- oder Ruby-Skript oder sonstwas sein.
Hmm.... -- weshalb ist eigentlich der HTML-Quelltext so schützenswert, wenn die Webseite einfach ein Dateiverzeichnis darstellt?
da ich schon dabei bin... zu 2) [vorausgesetzt, ich habe das Problem richtig verstanden] ich würde ein Skript vorschlagen (sh, perl, ruby, ...), das auf der ftp-Servermaschine von einem Scheduler in regelmäßigen Abständen ausgeführt wird, die Verzeichnisse absucht, die auf dem ftp-Server veröffentlicht sind, und aus den dort gefundenen Dateien/Unterverzeichnissen dann die Webseite aufbaut (dabei kann es 3) auch gleich mit erledigen). Schliesslich spielt es die Webseite auf Deinen HTML-Server auf.
? Ich habe von fun.mymobilesoft.com.sg die Vollversion Tetris... ebenso MotoGP... (vor ca. einer Woche runtergeladen... sollte sich da was geändert haben?)
Aber irgendwie stelle ich fest, dass mit dem Handy spielen nicht so richtig mein Ding ist... ist halt doch eher ein Telefon denn eine Spielkonsole
Falls ein clientseitiges Script (JavaScript) gewünscht ist, können die Treffer hier als Startpunkt für die Lösung dienen: http://www.google.com/search?q=Days%20until%20JavaScript
Ist bei mir genauso -- es lassen sich zwar Bildchen einfügen, jedoch nur diese nutzlosen vordefinierten Cliparts. Diese sind dann auch, wie im Handbuch beschrieben, mit einem * gekennzeichnet. Beim Einfügen von Tönen sieht es analog aus (wobei ich vermuten würde, dass eine EMS kein polyphones MIDI beinhalten kann?).
Ob das nun eine Auswirkung des O2-Flexings ist, oder grundsätzlich so (und das Handbuch uns mit dem "möglicherweise" nur in die Irre führen möchte) sei dahingestellt.
Michael