Das Notes Forum

Domino 9 und frühere Versionen => ND6: Entwicklung => Thema gestartet von: CLI_Andreas_Schmidt am 13.08.04 - 16:29:28

Titel: Ein anderer und besserer Weg
Beitrag von: CLI_Andreas_Schmidt am 13.08.04 - 16:29:28

Ich bräuchte mal ein paar Ideen.

Wenn ich mit einem Agenten einen String zusammenbaue, der später die zulässige kb Grenze des Feldes übersteigt und auch eine Ansicht den Inhalt auch nicht mehr auslesen kann, wie kann ich dann dieses Problem umgehen ?

Der String muss ja in seiner Form bestehen bleiben. Natürlich könnte man den String schneiden, aber ist das die allgemeine Lösung ? Gibt es da nicht etwas sinnvolleres. Da ja nicht genau vorher feststeht, wie groß der String letztendlich wird, also man auch nicht wissen kann wieviele Ansichten man benötigt, ist eine Teilung nur bedingt eine Lösung.

Gruss

Andreas

Titel: Re:Ein anderer und besserer Weg
Beitrag von: TMC am 13.08.04 - 16:39:40

Kannst Du mal ein konkretes Beispiel geben?

Gerade weil Du schreibst "Der String muss ja in seiner Form bestehen bleiben.".

Bei einer Historie (siehe z.B. den Thread "Wie kann ich eine Klasse sinnvoll aufbauen" in R5 Entwicklung) werfen wir alte Einträge raus, wenn die KB-Grenze überschritten wird. Klar, die könnte man dann in ein separates Dok schreiben - wenn man diese Infos braucht.

Titel: Re:Ein anderer und besserer Weg
Beitrag von: umi am 13.08.04 - 16:41:53

Das Speichern des Strings könnte man z.B. durch kaskadieren von Feldern lösen. D.h. z.B.

die 1. 65kb gehen ins Feld "Feldname"
die 2. 65kb ghen ins Feld "Feldname_1"
etc.

oder RichtextFelder verwenden.

Du willst den String dann in einer Ansicht anzeigen lassen?


gruss
umi

Titel: Re:Ein anderer und besserer Weg
Beitrag von: CLI_Andreas_Schmidt am 13.08.04 - 16:55:34

Ein Beispiel wäre:

<Hauptdokument>
   <Antwort>Inhalt aus Feld</Antwort>
   <Antwort>Inhalt aus Feld</Antwort>
   <Antwort>Inhalt aus Feld</Antwort>
   <Antwort>Inhalt aus Feld</Antwort>
      <Kommentar>Inhalt aus Feld</Kommentar>
      <Kommentar>Inhalt aus Feld</Kommentar>
      <Kommentar>Inhalt aus Feld</Kommentar>
      <Kommentar>Inhalt aus Feld</Kommentar>
</Hauptdokument>

usw.... Das String geht dann über eine Diskussionsansicht mit ca. 1200 Dokumenten. Problem erkannt ?

Gruss

Andreas




 

Titel: Re:Ein anderer und besserer Weg
Beitrag von: TMC am 13.08.04 - 17:42:21

Zitat von: CLI_Andreas_Schmidt am 13.08.04 - 16:55:34

Problem erkannt ?

Nö, ich habs noch nicht kapiert. Was aber nix heisst. ;D

Erkläre doch mal die Anwendung. Was willst Du mit Deinem String machen? Woher holst Du die Werte des Strings? Aus Deiner 1200-Doks großen Ansicht?

Titel: Re:Ein anderer und besserer Weg
Beitrag von: CLI_Andreas_Schmidt am 13.08.04 - 17:59:18

Die Werte werden alle aus einer Ansicht (Dokument für Dokument mit Hierarchiebezug) gesammelt, in eine Variable gespeichert und dann in ein neues BackEnd-Dokument in ein Feld gespeichert. Dieses Dokument wird in einer Ansicht angezeigt (nur dieses Dokument) und später als Computed Text ausgelesen.

Die Variable (String) wird leider viel zu lang, sodaß ein Feld den Inhalt nicht speichern könnte. Auch eine Ansicht hat Beschränkungen, die nicht zu überwinden sind. Also funktioniert auch der Computed Text mit dem @dbcolumn nicht mehr.

Jetzt ?

Titel: Re:Ein anderer und besserer Weg
Beitrag von: TMC am 13.08.04 - 18:16:54

Ich frage deshalb nach, weil es vielleicht Alternativen geben kann wie man das löst.

Ich habe verstanden, wie Du Dein String füllst (also aus Ansicht auslesen) und was Du damit machst (in ein Dok speichern).

Aber: Warum machst Du das so? Warum brauchst Du das alles in einem String?

Einen Tipp, wie man die KB-Grenze aushebelt wird es wohl nicht geben. Du frägst nach Alternativen.
Da müsste man schon noch Details wissen um helfen zu können. Am besten konkret, was das für eine DB ist.

Titel: Re:Ein anderer und besserer Weg
Beitrag von: CLI_Andreas_Schmidt am 13.08.04 - 18:36:39

Alle Inhalte, die ich aus den Ansichten ziehe werden für eine dynamische Gliederung benötigt (so wie ein Flymenü). Ich baue den ganzen String mit weblinks zum Dokument (wo der Inhalt herkommt) plus Icon, plus Onlick Event für die Gliederungseinträge. ÄHNLICH WIE DIE ATNOTES GLIEDERUNG. Nur bei mir passieren zwei Dinge. Bei Klick auf das Wort klappt sich die Gliederung auf und gleichzeitig wird das Dokument in einem Zielrahmen angezeigt. Das kann eine normale Diskussionsansicht im Web nicht. Nur die DREIECKE klappen Gliederungen (oder Kategorien) auf, nicht aber der Klick auf die Information. Dabei geht in REIN Notes nur das Dokument auf. Ich verwende für das Menü die HTML Attribute <SPAN id='menu1'>

Gruss

Andreas

Titel: Re:Ein anderer und besserer Weg
Beitrag von: TMC am 13.08.04 - 19:07:20

Aha, es geht um eine Webanwendung. Da hab ich leider bisher wenig Erfahrung.

Ist umi's Vorschlag keine Lösung?
Also eine Function (oder Klasse - wahrscheinlich hier eleganter), welche anhand der Größe des Strings ein- oder mehrere Felder Deines Doks füllt.

Ich glaube eine Klasse kommt hier gut.

Du sagst nur noch:
Dim myFatString as RichtigGrossesString
Set myFatString = New RichtigGrossesString
Call myFatString.Append (strIchWillDazu)

Den Rest macht eben die Klasse.

Intern löst die Klasse das über mehrere Felder (um eben das KB-Limit nicht zu sprengen).

Titel: Re:Ein anderer und besserer Weg
Beitrag von: animate am 13.08.04 - 19:45:45

ist das HTML, was du da generierst???
du könntest dann deinen Code in eine Datei schreiben und die z.B. in einem Iframe anzeigen. Oder so.

Titel: Re:Ein anderer und besserer Weg
Beitrag von: CLI_Andreas_Schmidt am 13.08.04 - 20:19:54

Ja eine Mischung aus HTML und einem JavaScript, der dann mit dem HTML was macht. Die Idee gucke ich mir mal an.

Danke.

Titel: Re:Ein anderer und besserer Weg
Beitrag von: Marinero Atlántico am 13.08.04 - 23:00:17

Ich halte das mit dem IFrame auch für eine gute Idee.
Wobei ich zwei Nachteile sehe:
1. IFrames sind auch irgendwie so ein externes Element in einer Webseite. Aber vermutlich bin ich da einfach zu puristisch/paranoid.
2. Wenn du ein Element dieser Struktur wegnimmst oder veränderst, musst du das gesamte File neu schreiben. Oder du wirst parsing Experte.

Code

<Hauptdokument>
  <Antwort>Inhalt aus Feld</Antwort>
  <Antwort>Inhalt aus Feld</Antwort>
  <Antwort>Inhalt aus Feld</Antwort>
  <Antwort>Inhalt aus Feld</Antwort>
      <Kommentar>Inhalt aus Feld</Kommentar>
      <Kommentar>Inhalt aus Feld</Kommentar>
      <Kommentar>Inhalt aus Feld</Kommentar>
      <Kommentar>Inhalt aus Feld</Kommentar>
</Hauptdokument>  

Wie reagierst du darauf, wenn jetzt ein Anwender den 3. Kommentar löschst.
Man könnte das vielleicht als XHTML schreiben und jedem Element eine ID gibt, die es mit dem entsprechenden Notes-Dokument verpointerst.
Dann mit der DOM-API... Hm ist sicher nicht wirklich leicht.
Das File jedesmal neu schreiben ist sicher einfacher.

Kannst du diese Struktur vielleicht als kategorisierte Ansicht darstellen?
Dann könnte man u.U. den Baum unter dem Hauptdokument als eine html-View in den IFrame laden.

Gruß Axel

Titel: Re:Ein anderer und besserer Weg
Beitrag von: CLI_Andreas_Schmidt am 14.08.04 - 11:45:19

Ich danke Euch. Ich werde es so versuchen. Jetzt brauche ich nur noch eine kurze Erläuterung zum Begriff: Iframe

Was ist damit gemeint ? Dumme Frage vielleicht, aber das Wort ist mir noch nicht unter gekommen.

Gruss

Andreas

Titel: Re:Ein anderer und besserer Weg
Beitrag von: ..Andreas.. am 14.08.04 - 15:45:33

Wenn ich die Eingangsfrage richtig verstanden habe verwendest Du einen (LS-)Agenten um eine "Struktur" aufzubauen. Diese soll dann in einem Dokument gespeichert werden, um im Internet angezeigt zu werden.

Ich habe das Problem in einer meiner Internetanwendungen (CMS, das HTML mit deutlich mehr als 64 k HTML erstellt) wie folgt gelöst:

Zur Errechnung der Contents verwende ich eine (oder mehrere) Klassen die die Strings in einer String-Liste (Dim slistOfStrings List as String) halten. Damit hast Du lediglich für jedes Element der Liste das 64-k-Problem. Die Grösse Gesamtliste ist (glaube ich) nur durch die Hardwareressource beschränkt.

Wenn alle Informationen "zusammengesammelt" und in die richtige Ordnung gebracht sind, schreibe ich Element für Element, Zeile für Zeile in ein RichText-Feld (wieder nur eine Beschränkung pro Zeile, nicht pro "Gesamtfeld"). Dieses Feld wird dann im Internet angezeigt.

Das geht zwar in eine ander Richtung als der Rest der Diskussion, aber vielleicht hilft es Dir trotzdem. Wenn Du noch mehr Infos brauchst sag einfach bescheid.

Schönes Wochenende noch,
Andreas

Titel: Re:Ein anderer und besserer Weg
Beitrag von: Marinero Atlántico am 14.08.04 - 17:48:26

http://www.google.de/search?hl=de&ie=UTF-8&q=iFrame&btnG=Google-Suche&meta= (http://www.google.de/search?hl=de&ie=UTF-8&q=iFrame&btnG=Google-Suche&meta=)
hüstel

Titel: Re:Ein anderer und besserer Weg
Beitrag von: animate am 14.08.04 - 19:57:10

Zitat von: Marinero Atlántico am 13.08.04 - 23:00:17

Kannst du diese Struktur vielleicht als kategorisierte Ansicht darstellen?
Dann könnte man u.U. den Baum unter dem Hauptdokument als eine html-View in den IFrame laden.

ich glaube, das wird nicht gehen mit einer Ansicht, weil du ja alle Antworten zwischen den  Hauptdokumenttags haben musst. D.h. du musst nach der letzten Antwort den Haupdokumentendtag setzen - und das kannst du nicht machen in einer Ansicht.

Das Schreiben in eine Datei käme für mich auch nur in Frage, wenn sich die Struktur der Navigation relativ selten ändert. Dann kannst du z.B. die Datei per scheduled Agent jede Stunde(/Tag/Woche) neu erzeugen lassen (oder auch sofort - je nach Bedarf).

Titel: Re:Ein anderer und besserer Weg
Beitrag von: Marinero Atlántico am 14.08.04 - 21:49:06

Zitat von: Thomas Völk am 14.08.04 - 19:57:10

ich glaube, das wird nicht gehen mit einer Ansicht, weil du ja alle Antworten zwischen den  Hauptdokumenttags haben musst. D.h. du musst nach der letzten Antwort den Haupdokumentendtag setzen - und das kannst du nicht machen in einer Ansicht.

ja. Aber vielleicht kann man ja die Single-Kategorie Ansicht im IFrame in eine Page einbetten und das so machen:
<hauptdokument> (als Text)
eingebettete Ansicht
</hauptdokument>

Weiss aber auch nicht mehr, ob das was mit Andreas anfänglicher Fragestellung zu tun hat. Leider bin ich zu müde, ein Beispiel zu coden. Vielleicht schaffe ich das morgen.

Titel: Re:Ein anderer und besserer Weg
Beitrag von: animate am 14.08.04 - 22:10:19

klar. so kannst du es machen, wenn es genau 1 Hauptdokument gibt

Titel: Re:Ein anderer und besserer Weg
Beitrag von: Marinero Atlántico am 14.08.04 - 22:18:05

Aber es gibt doch diese "single category" Ansichten (oder so ähnlich).
1. Man embedded die Ansicht in einer Form.
2. In der URL des IFrames übergibt man die DocUnid des Dokuments an die Form (wird als http-get Parameter an die URL angehängt).
3. Die Form liest die DocUnid aus. Und schreibt es in ein Feld.
4.  Von dem DocUnid Feld wird abhängig gemacht, welche Kategorie angezeigt wird.
5. Die Kategorisierte Spalte enthält die DocUnidIds der Hauptdokumente.

Ich glaub das könnte gehen.

Gruß Axel

Titel: Re:Ein anderer und besserer Weg
Beitrag von: Tode am 18.08.04 - 11:43:45

ich habe jetzt die ganze Diskussion gelesen, verstehe aber immer noch nicht, warum das ganze nicht mit einer View funktionieren soll...

Man zeigt die View als HTML an und berechnet für jede Zeile den Code... braucht man JavaScript, dann kann man dieses in die $$View-Template oder eine andere Maske einbinden, in der die View eingebettet angezeigt wird...

Der Vorteil im Web: Maske und eingebettete View sind EINE Form... View- Elemente können also auf JavaScript- Befehle der Maske zugreifen.

Ich KANN mir nicht vorstellen, dass diese Anforderung nicht mit einer View gelöst werden kann... und dann fallen sämtliche restriktionen, was text- länge angeht, einfach weg...

Gruß
Tode