WAA Frame aufruf.

[DSEDSE]

Hallo Zusammen,

mein name ist Ayhan und bin seit 15 Jahren XBASE-Programmierer bin aus dem Raum Augsburg. Bin noch ein Anfänger bzgl. WAA. Hier meine Frage:

Habe 2 Frames, im Frame 1 sind die Button mit Funtionen hinterlegt. Diese Aufrufe würde ich gerne auf die Frame weiter weiten. Könnte mir jemand diesbzgl weiterhelfen.

Dank im voraus

Ayhan

[Martin Altmann]

Merhaba Ayhan,
eigentlich kann man doch beim Aufrufen einer URL angeben, wo die Seite geöffnet werden soll - also z.B. im selben Fenster, in einem neuen Fenster oder in einem bestimmten Frame. Dazu dient der target-tag. Diesen müsstest Du also mit einbauen.

Iyi aksamlar,
Martin

[DSEDSE]

Hallo Martin,

werde es gleich mal ausprobieren. Tessekürler!!!!!!


Ayhan

[DSEDSE]

Hallo Martin,

irgendwas mach ich noch falsch, der aufruf findet im Linken anstatt dem Rechten Frame statt

Code: Alles auswählen

 oHtml:header( "EWT-WEB" )
   oHtml:beginFrameSet( , "180,*", 'frameborder="0"' )

   oFrame := oHtml:newFrame( 'LeftFrame' , '', '/temp/FRAMEL1.HTM' )

   oFrame:header( 'Left Frame', 'BGCOLOR="#666666" TEXT="#FFFFFF"' )
   oFrame:put   ( 'EWT - WEB System' )
              
   

   oFrame:formStart( 'Simple'     , 'RightFrame'  )
   oFrame:setVar   ( 'WAA_PACKAGE', 'FRAMESET'    )
   oFrame:setVar   ( 'WAA_FORM'   , 'VIEWSOURCE1' )

aVars:={ {"WAA_PACKAGE","FRAMESET"                } ,;           
         {"WAA_FORM"   ,"dbedit"                  } ,;           
         {"WAA_OPTIONS",""                        } ,;           
         {"WAA_USE"    ,"artikel.dbf,artikel.cdx" } }  

   oFrame:ref("test",aVars) 

Gruß

Ayhan

[Martin Altmann]

Gün aydın Ayhan,
özür, aber ich habe das letzte Mal vor einigen Jahren mit WAA gearbeitet - dann bin ich umgestiegen auf XB2.NET. Und mit Frames mache ich dort auch nichts.
Eine gute HTML-Beschreibung findest Du z.B. hier http://selfhtml.org/
Mit Frames arbeiten bedeutet, eine HTML-Seite zu haben, in der die Frames definiert und benamst werden. Dann kannst Du die einzelnen Frames über ihren Namen ansprechen und dort entsprechende Seiten anzeigen (also hineinladen).
Wenn ich Deinen Code richtig deute, definierst Du dort nur noch einen Frame mit dem Namen LeftFrame. Dann beginnst Du ein Formular, das im Frame mit dem Namen RightFrame angezeigt werden soll - doch wo hast Du diesen Frame definiert?
Ich vermute, es gibt ihn nicht - und darum wird es im selben Frame angezeigt, wie der Rest.

Selam,
Martin

[Armin]

Hallo Ayhan,

schön, dann bin ich wenigstens nicht der einzige WAA-Freak. Martin hat wohl recht, dass der rechte Frame noch nicht erstellt wurde. Ich helfe Dir gerne weiter. Ich bearbeite mit dem WAA hauptsächlich HTML-Templates. D.h. man erstellt ein HTML mit z.B. einem geeigneten Designwerkzeug. Dieses hole ich mir dann und fülle es sozusagen aus und schicke es dann ab.

oLeftFrame := oHtml:newFrame( 'LeftFrame' , '', '/temp/FRAMEL1.HTM' )
oRightFrame := oHtml:newFrame( 'RightFrame' , '', '/temp/FRAMER1.HTM' )

Wenn Du Fragen hast...

Grüsse, Armin

[DSEDSE]

Hallo Armin,

bin zur Zeit in der Entscheidungsphase. Habe mir auch XB2NET zugelegt. Beide haben ihre stärken und schwächen. Was mir gut gefallen hat ist das Beispiel-Programm
von Roger XB2NET in Verbindung mit Express. (im Verzeichnis samples\html) .

Arbeites du mit Frames? Was ich brauche bzw. machen will ist z. Bsp:

3 Frames

1. Frame = Menü
2. Frame = Stamminformationen (z. Bsp. Containerdaten)
3. Frame = Browse (z. Bsp. Container-Inhalt Artikel)

desweiteren sollen die Container die Verladen wurden nachverfolgt werden (Tracking).

Für anregungen wäre ich sehr dankbar.


Schöne Grüße aus Mersin (Türkei)
Ayhan

[Armin]

Hallo Ayhan,

wir sind mit dem WAA sehr zufrieden. Wir haben damit eine komplette betriebswirtschaftliche Anwendung erstellt. Für was man dabei Express benötigen könnte, weiss ich nicht.

Wir haben unsere Anwendung sogar mit 4 Frames aufgebaut - Baummenü, Kopf und den Datenbereich dann noch einmal horizontal geteilt. Heutzutage baut man Webseiten eigentlich nicht mehr mit Frames, wobei eine Webanwendung ja auch keine Webseite in dem Sinne ist (Rollbalken, Schaufenstereffekte...).

Ein Browse-HTML bauen wir auch über eine Vorlage mit einer Zeile. Diese wird dann mit Xbase++ so oft kopiert und angehängt, wie Zeilen nötig sind.

Die HTML-Vorlage (Template) bearbeiten wir dann hauptsächlich mit den DOM-Funktionen (z.B. getelement()).

Beste Grüsse, Armin

[brandelh]

Hi,

die Diskussionen über WAA <-> XB2.NET <-> direkte CGI Programmierung wurden schon in mehreren Threads geführt.
Einfach mal danach suchen.
Aus meiner Sicht (ich nutze keine Frames) spielt die Frage welche technische Basis man verwendet keine Rolle für die FraGE welche HTML/CSS (Stil-)elemente man benutzen will. Solange die HTML Seite die Frames sauber implementiert, werden alle 3 diese sauber vom Browser anzeigen lassen. Möglicherweise ist das interne Handling mehr oder weniger aufwändig.

Ich persönlich schätze an meinen CGI.EXE Programmen, dass diese immer nur sehr kurz im Speicher sind und sich praktisch so nie aufhängen können (außer es liegt eine Programmfehler vor). Die Verantwortung für den HTTP Server hat dann der Hersteller dieser Software (Apache oder MS). Natürlich muss man meist selbst für Updates dieser Server sorgen, gerade heute durchaus ein Zeitfaktor (daher erwäge ich vom Apache auf den ISS zu wechseln).
Nachteil: man braucht einen Web-Server mit Windows BS und .EXE CGI Freigabe, bei letzterem liegt oft das Problem.

XB2.NET bietet natürlich mehr Möglichkeiten insbesondere automatische Tasks und Reaktionen zu hinterlegen.
Allerdings ist es nicht ganz einfach das auf einem 64 Bit Server als Dienst zu installieren und am Laufen zu halten.
Martin hat dazu schon viel gepostet ... zuletzt auch dass sein Dienst Speicher / Resourcen frist.
Möglicherweise liegt das an Xbase++ oder an XB2.NET oder an seiner Implementierung, ich kann dies nicht beurteilen.
Es scheint aber sinnvoll zu sein, den Dienst regelmäßig neu zu starten.
Nachteil: man braucht einen Web-Server mit Windows BS und zumindest eingeschränkten Admin Rechten ...

WAA ist im Prinzip eine CGI Schnittstelle zwischen dem Standard Webserver (dieser kann sehr verschiedene OS haben) und dem Windows Anwendungsserver (DLL). WAA hat aus meiner Sicht 2 Nachteile:
1. Nicht direkt als Dienst lauffähig - eventuell gibt es da Abhilfen
2. Es scheint nicht gerade an der Spitze der Wartungsschleife zu liegen
Andererseits wird Alaska sicher diesen auch intern nutzen.

Jetzt ist es doch wieder mehr geworden ... wie geschrieben, es gibt hier viele Infos zu dem Thema ...

[Armin]

Hallo Ayhan,

der Start der WAA-Anwendung erfolgt über ein HTML, das sofort eine Weiterleitung zu unserer Xbase Start-Funktion durchführt.

default.htm oder index.htm:

Code: Alles auswählen

<HTML>
<HEAD>
<meta http-equiv="refresh" content="0; URL=http://domainname/cgi-bin/waa1gate.exe?WAA_PACKAGE=DLLNAME&WAA_FORM=Login&WAA_HTML3CLASS=Frameset">
<TITLE>AnwendungXY</TITLE>
</HEAD>
<BODY>
</BODY>

Code: Alles auswählen

FUNCTION Login( oHTML, oContext )
   local aVars       := oHTML:getAllVars()   // Werte aus der HTML-Seite
  local cRoot        := "c:\docroot"         // oder aus einer Ini-Datei laden
  local cRemoteUser := trim(oContext:getRemoteUser())
  local oFrame

  // Logindaten checken
    oHTML:put('<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">')
    oHTML:Header('AnwendungXY')

   oHTML:beginFrameset('12%,100%')
   oFrame := oHTML:newFrame(HeadFrame','SCROLLING="NO" marginwidth="0" marginheight="30"' , cRoot+"HeadFrame")
   FillHeadFrame(oFrame, oContext)

   oHTML:beginFrameset(, '18%,82%')
   oFrame := oHTML:newFrame('LeftFrame', ,  cRoot+"LeftFrame.HTM")
   FillLeftFrame(oFrame, oContext, .F.)         

   oHTML:beginFrameset('54%,46%')
   oFrameMain := oHTML:newFrame('MAIN', , cRoot+"MAINFrame.HTM")
   oFrameData := oHTML:newFrame('DATA', , cRoot+"DATAFrame.HTM")
   FillDataFrame(oFrameData, oContext)  
   FillMainFrame(oFrameMain, oContext,.t.)  

return .t.

z.B.

Code: Alles auswählen

function FillMainFrame(oFrame, oContext)

   oDocument := HTMLDocument():loadFile( test.htm )

   use adressen
   oNewRow:GetElement( "name" ):value := ConvToAnsiCP(alltrim(adressen->name))

   cHTML:= oDocument:toHTML()
   oFrame:put(cHTML)


return .t.

In test.htm wird z.B. hiermit der value von ID="name" gefüllt.

Hoffe, das hilft Dir erst mal weiter, Grüsse, Armin

[brandelh]

Hallo Armin,

ich habe deine Mail mit [ CODE ] Tags ausgestattet, nun kann man es besser lesen

Hier lese ich eine Anmeldeprüfung im Kommentar, aber ...

Code: Alles auswählen

  // Logindaten checken
    oHTML:put('<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">')
    oHTML:Header('AnwendungXY')

die zwei Zeilen darunter machen scheinbar etwas anderes.

Ist die Zeile nur zur Erinnerung dass man hier einen Login checken muss oder bin ich blind ?

[Armin]

Hallo Hubert,

den WAA kann man auch per Diensteloader als Dienst laden - es gab da schon funktionierende Versuche. Wir betreiben ihn trotzdem als EXE - wieso auch nicht...

Der WAA erweist sich als sehr robust, es gibt keine aktuelle Probleme. Alaska betreibt damit auch ihre eigene Verwaltungssoftware.

Schön wäre z.B. eine durchgängige UTF-8 Unterstützung (von der DB direkt zur HTML, bzw. XHTML-Seite und zurück ohne umwandeln).

Beste Grüsse, Armin

[Armin]

Hallo Hubert,

danke

Grüsse, Armin

[Armin]

Hallo Hubert,

ja - die Loginprüfung könnte man da einbauen - das sind alles nur Codeschnipsel, da fehlt auch das eine oder andere local... usw.

Wir nehmen direkt den Windows-Benutzer - geht mit firefox und IE - und haben dann noch eine interne Rechteverwaltung.

D.h. vor jeder Funktion, die von einem HTML gerufen werden kann gibt es noch eine Rechte und eine Parameterprüfung. Sonst geben die lustigen Anwender die URLs direkt ein und es passieren komische Dinge

Grüsse, Armin

[brandelh]

Ja das mit dem durchgängigen UNICODE wäre schon eine schöne Sache ...

Vor kurzem viel mir auf meinem lokalen Apache Testsystem auf, dass einige Zeichen (° und Umlaute) falsch dargestellt werden ... nanu dachte ich, die tausche ich doch vor dem Versand in HTML Codierung um ...

Tatsächlich war das ° noch nicht in meiner Austauschfunktion, aber die Umlaute schon ...
Ich mußte meinen Browser von UNICODE auf Windows 1252 stellen, dann war es von der Anzeige ok.
Auf dem Produktivserver (ISS) läuft das gleiche Programm ohne dieses Verhalten und früher war mir das auch nicht aufgefallen.
In den conf Dateien kann ich beim Server auch nichts finden um diesen auf Windows zu stellen, aber irgendwie bin ich recht ratlos, warum HTML codierte Zeichen immer noch davon abhängig sein sollen &Auml; sollte doch immer stimmen

[Armin]

Hallo Hubert,

ein html-Zeichen wie z.B. &Auml; sollte im Browser immer das Ä darstellen - egal, welcher Zeichensatz eingestellt ist.

Wir speichern die Daten in ASCII-DBF (muss auch alles noch kompatibel zu einer Clipper-Anwendung sein).

Sie werden dann mit ConvToAnsiCP() umgewandelt.

Die Webseite hat dann immer:

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">

Ich habe noch Probleme mit der Zeichenumwandlung bei Ajax-Funktionen...

Grüsse, Armin

[DSEDSE]

Hallo Zusammen,

hatte leitungsprobleme . Wollte mich für eure anregenden Beiträge bedanken. Werde mich mal heute damit beschäftigen.

Gruß

Ayhan