Lotus Notes / Domino Sonstiges > Help-Desk Applikation !!Help!!

Help Application demo at Lotusphere

<< < (24/34) > >>

flaite:
Imho wärs einfacher, wenn wir für sowas ein Versions-Kontrolle unterstütztes Projekt auf sourceforge.net, javalobby.org oder vielleicht sogar openNTF.org hätten.
Nathan Freeman hat angekündigt, dass er cvs für Domino unterstützen will. Werd da mal nachfragen, ob man dann da auch eng-Domino-verbundene-Java-Projekte (wie dieser Client) laufen lassen könnte. Würde Sinn machen.
Als nächstes würde ich javaLobby fragen.

Axel

eknori (retired):
Assign Ticket ist jetzt auch rudimentär implementiert. An den Parametern wird sich wohl nichts mehr ändern, aber innerhalb der Funktion fehlen noch ein paar Sachen...

%REM
#####################################################
 Public Function AssignTicket (strTicket As String, strAssignTo As String) As Integer
#####################################################
%END REM   
   Public Function AssignTicket ( ID As String, strAssignTo As String) As String
      
      On Error Goto ERRHANDLE      
      AssignTicket = ""
      
      If Trim ( ID ) = "" Or Trim(strAssignTo) = "" Then
         AssignTicket = ASSIGN_TICKET_ERR_MANDANTORY  'mandantory fields
         Exit Function ' nothing else to do, get outa here !
      Else      
         SearchFormula =|ReqNumber ="| & Trim( ID ) & |"|   
         Set dc = getDocuments ( SearchFormula )
         
         count = dc.count
         If count = 0 Then Exit Function
         If count > 0 Then  ' search successful
            Dim doc As NotesDocument
            Set doc = dc.GetFirstDocument
            If doc.status(0) <> "99" Then 'check status
               If doc.status(0) = "0" Then 'New Ticket
                  doc.status = "1"
               End If
               doc.supporter = strAssignTo
               success = doc.ComputeWithForm( False, False )
               AssignTicket = doc.ReqNumber(0) & ASSIGN_TICKET_ERR_NOERROR
               Call doc.Save ( True, True )
            Else
               AssignTicket = ASSIGN_TICKET_ERR_ALREADY_CLOSED
               Exit Function
            End If
         End If
      End If
      
      
EXITPOINT:
      Exit Function
ERRHANDLE:
      xProc = Getthreadinfo(LSI_THREAD_PROC)
      xError = xProc  & ": " &Trim$(Str$(Err)) & " on line " & Cstr(Erl) & ": " & Error$
      If UseOpenLog Then
         Call LogError
      Elseif LogScriptErrors Then
         Call ThrowException ( xProc, xError  )
      End If
      Print xError   'In all cases
      If ResumeMethodNext Then
         Resume Next   
      Else
         AssignTicket = ASSIGN_TICKET_ERR_MISC_ERROR
         Resume EXITPOINT
      End If
   End Function

flaite:

--- Zitat ---Todo ist weg.
--- Ende Zitat ---
Du meinst das ToDo bei den Details ? Ja, ich war gestern zu blöd, ein array zu (re)-dimmen ... baue ich abe morgen wieder ein.


--- Zitat ---Haben eigentlich die Blackberry Leute etwas gesagt?
--- Ende Zitat ---

Leider bisher noch nicht: habe heute morgen noch wg. Auth und deinem client nachgefragt ... Schweigen im Walde ...  :P


Boah ... ich glaube ich mache Feierabend; jetzt habe ich deinen Artikel editiert, statt drauf zu antworten ... :'(

eknori (retired):
Boah ... ich glaube ich mache Feierabend; jetzt habe ich deinen Artikel editiert, statt drauf zu antworten ...  :'(

flaite:
Nimms nicht persönlich, aber ich bin mir jetzt 100% sicher, dass ich bei dem nächsten Webservices Consumer, den ich programmieren werde, auf einen gewissen Formalismus (Use Cases, Objekt-Modell) bestehen werde. Aber um das effektiv zu machen, dient auch dieser Lernprozess.
Diese Api ist instabiler als 2 Erdplatten, die gerade einen Tsunami erzeugen  ;D
Kein großer Akt das neu zu erzeugen, aber ich hab ToDo auch im Business Layer weggehauen.

Ich probier jetzt mal assignTickets zu implementieren und für eins der von mir erzeugten tickets zu testen.

Um über instabile Apis zu sprechen. Ich glaub mittlerweile das TicketsDetails nicht so eine gute Idee war. Am besten wir hauen irgendwann Ticket weg und machen TicketDetails zu Ticket.
Das ist irgendwie doppelt. Eine Ticket-Klasse reicht eigentlich.

Bei mir kam gestern der Mann mit dem Hammer. Der 1.1. (Sonntag) war ziemlich extrem. Hab auch nicht alles richtig durchdacht. Es war und ist aber definitiv brauchbar und auf besser änderbar. Das betrifft aber mehr business-layer interne Sachen.

Ach ja. Wo wir jetzt so weit sind. Warum kann ich nicht einfach ein Datum hochschicken und du sendest nur Tickets runter, die nach diesem Datum zuletzt geändert wurden.
Es macht Sinn aus Performance-Gesichtspunkten, den Datenbestand auf dem Client und dem Server als 2 verbundene aber vollständige Datenbanken vorzustellen (wobei der Serverbestand natürlich der "führende" Datenbestand ist). Ich kann diese ganzen Tickets, ToDo und whatever Daten hier auch persistent in eine embedded Datenbank schreiben oder als Files serialisieren, so dass nach dem Neustart des Clients der Datenbestand des letzten Downloads gar nicht vom Server gezogen werden muss. So könnte z.B. auch ohne Internetverbindung gearbeitet werden. Dabei muss natürlich auch bei eventuellen Updates auf dem Server gecheckt werden, ob die Daten des Clients irgendwie veraltet sind. Das geht, macht Sinn und bzgl. der Konsistenz von 2 Datenbeständen gibts lecker Design Patterns von Martin Fowler.  :D
 

Gruß Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete