Autor Thema: Ein anderer und besserer Weg  (Gelesen 5398 mal)

Offline CLI_Andreas_Schmidt

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 668
  • Geschlecht: Männlich
  • I love YaBB 1G - SP1!
    • Lotus Notes & Domino Schulung und Entwicklung
Ein anderer und besserer Weg
« 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
Viele Grüße

Andreas.Schmidt@lotus-schmidt.de

Offline TMC

  • Freund des Hauses!
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 3.660
  • Geschlecht: Männlich
  • meden agan
Re:Ein anderer und besserer Weg
« Antwort #1 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.
Matthias

A good programmer is someone who looks both ways before crossing a one-way street.


Offline umi

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 2.062
  • Geschlecht: Männlich
  • one notes to rule'em all, one notes to find'em....
    • Belsoft AG
Re:Ein anderer und besserer Weg
« Antwort #2 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
Gruss

Urs

<:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jegliche Schreibfehler sind unpeabischigt
http://www.belsoft.ch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:>

Offline CLI_Andreas_Schmidt

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 668
  • Geschlecht: Männlich
  • I love YaBB 1G - SP1!
    • Lotus Notes & Domino Schulung und Entwicklung
Re:Ein anderer und besserer Weg
« Antwort #3 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




 
Viele Grüße

Andreas.Schmidt@lotus-schmidt.de

Offline TMC

  • Freund des Hauses!
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 3.660
  • Geschlecht: Männlich
  • meden agan
Re:Ein anderer und besserer Weg
« Antwort #4 am: 13.08.04 - 17:42:21 »
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?
Matthias

A good programmer is someone who looks both ways before crossing a one-way street.


Offline CLI_Andreas_Schmidt

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 668
  • Geschlecht: Männlich
  • I love YaBB 1G - SP1!
    • Lotus Notes & Domino Schulung und Entwicklung
Re:Ein anderer und besserer Weg
« Antwort #5 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 ?
Viele Grüße

Andreas.Schmidt@lotus-schmidt.de

Offline TMC

  • Freund des Hauses!
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 3.660
  • Geschlecht: Männlich
  • meden agan
Re:Ein anderer und besserer Weg
« Antwort #6 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.
Matthias

A good programmer is someone who looks both ways before crossing a one-way street.


Offline CLI_Andreas_Schmidt

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 668
  • Geschlecht: Männlich
  • I love YaBB 1G - SP1!
    • Lotus Notes & Domino Schulung und Entwicklung
Re:Ein anderer und besserer Weg
« Antwort #7 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

Viele Grüße

Andreas.Schmidt@lotus-schmidt.de

Offline TMC

  • Freund des Hauses!
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 3.660
  • Geschlecht: Männlich
  • meden agan
Re:Ein anderer und besserer Weg
« Antwort #8 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).
Matthias

A good programmer is someone who looks both ways before crossing a one-way street.


Offline animate

  • Freund des Hauses!
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 1.540
  • Uh, I'm just gonna go find a cash machine.
    • LA2
Re:Ein anderer und besserer Weg
« Antwort #9 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.
Thomas

Fortunately, I'm adhering to a pretty strict, uh, drug, uh, regimen to keep my mind, you know, uh, limber.

Offline CLI_Andreas_Schmidt

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 668
  • Geschlecht: Männlich
  • I love YaBB 1G - SP1!
    • Lotus Notes & Domino Schulung und Entwicklung
Re:Ein anderer und besserer Weg
« Antwort #10 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.
Viele Grüße

Andreas.Schmidt@lotus-schmidt.de

Marinero Atlántico

  • Gast
Re:Ein anderer und besserer Weg
« Antwort #11 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


Offline CLI_Andreas_Schmidt

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 668
  • Geschlecht: Männlich
  • I love YaBB 1G - SP1!
    • Lotus Notes & Domino Schulung und Entwicklung
Re:Ein anderer und besserer Weg
« Antwort #12 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
Viele Grüße

Andreas.Schmidt@lotus-schmidt.de

Offline ..Andreas..

  • Junior Mitglied
  • **
  • Beiträge: 60
  • Geschlecht: Männlich
  • Brevity is the soul of wit.
Re:Ein anderer und besserer Weg
« Antwort #13 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

Marinero Atlántico

  • Gast

Offline animate

  • Freund des Hauses!
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 1.540
  • Uh, I'm just gonna go find a cash machine.
    • LA2
Re:Ein anderer und besserer Weg
« Antwort #15 am: 14.08.04 - 19:57:10 »
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).
Thomas

Fortunately, I'm adhering to a pretty strict, uh, drug, uh, regimen to keep my mind, you know, uh, limber.

Marinero Atlántico

  • Gast
Re:Ein anderer und besserer Weg
« Antwort #16 am: 14.08.04 - 21:49:06 »

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.

Offline animate

  • Freund des Hauses!
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 1.540
  • Uh, I'm just gonna go find a cash machine.
    • LA2
Re:Ein anderer und besserer Weg
« Antwort #17 am: 14.08.04 - 22:10:19 »
klar. so kannst du es machen, wenn es genau 1 Hauptdokument gibt
Thomas

Fortunately, I'm adhering to a pretty strict, uh, drug, uh, regimen to keep my mind, you know, uh, limber.

Marinero Atlántico

  • Gast
Re:Ein anderer und besserer Weg
« Antwort #18 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
« Letzte Änderung: 16.08.04 - 07:24:23 von Marinero Atlántico »

Offline Tode

  • Moderatoren
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 6.885
  • Geschlecht: Männlich
  • Geht nicht, gibt's (fast) nicht... *g*
Re:Ein anderer und besserer Weg
« Antwort #19 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

Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen... das klingt dann so: "Tooode" (langes O, das r, s und n werden verschluckt, das t wird zum badischen d)

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz