Direkt zum Hauptbereich

Posts

Es werden Posts vom September, 2013 angezeigt.

"Ich sehe was, was du nicht siehst" oder "Ich habe keine Ahnung was du willst"

"Ich sehe was, was du nicht siehst" ist ein Spielchen, das meine Tochter gerne mit mir spielt. Dabei muss ich den Namen eines Gegenstandes erraten, den sie irgendwo gesehen hat. Heute spielt Salesforce ein neues, beinahe masochistisches Spiel mit mir. Ich übertrage ein Changeset aus einer Sandbox in eine andere Sandbox. Beide befinden sich auf dem aktuellsten Stand mit Winter14. Das Changeset enthält nur 2 Elemente: - 1 Custom Field aus dem CASE - 1 Übersetzung (DE). Beim Validieren in der Ziel-Sandbox bekomme ich die folgende Fehlermeldung: Field feed_filter_case_notes does not exist on entity Case Übertrage ich das Feld ohne Übersetzung, funktioniert die Validierung problemlos. So schnell gebe ich nicht auf und "google" nach  feed_filter_case_notes . Aber auch Google will mir nicht verraten, was damit gemeint ist. Gar keine Ergebnisse zum gesuchten Begriff. Offensichtlich bringt Winter14 mehr Überraschungen als erwartet.

Zusammenspiel der STATIC und PUBLIC Funktionen

Eine VisualForce Page stellt diverse statische und dynamische Informationen dar. Mit statisch bezeichne ich Daten, die vom Controller beim Laden der Page berechnet werden. "Dynamisch" impliziert den Einsatz von Benutzerinteraktionen. Dabei werden Abfragen gegen die Datenbank gesendet, um aktuelle Content-bezogene Informationen zu erhalten. Die Abfragen sind in Form von Methoden und Funktionen im Controller integriert. Einige davon sind public , die Anderen sind  static  .  Ziel: sowohl  public  als auch  static   führen teilweise dieseleben Operationen durch. Ein guter Entwickler verzichtet auf die Redundanz des Codes und entwickelt eine neue Funktion, die von den beiden oben genannten Funktionen aufgerufen wird. Problem: eine neue Funktion zu entwickeln und den Code auszulagern stellt noch kein Problem dar. Erst beim Versuch, die neue Funktion aufzurufen, wird die Divergenz der beiden Typen  public  und  static   deutlich. Ein Zugriff auf die neue Funktion scheit

Darstellung der Picklisteneinträge als Checkboxen

Der Schwerpunkt des letzten Projektes lag eindeutig auf der benutzerfreundlichen Darstellung bestimmter Inhalte. Dazu gehört unter anderem die Benutzung von Checkboxen. Salesforce stellt zwar eine relativ große Menge von Feldtypen zur Verfügung, aber die in der HTML-Welt so geliebten Checkboxen sind leider nicht dabei. Mit Einsatz einer neuen VisualForce Page ist das Problem aber schnell gelöst. Das Ziel dabei ist: die Werte eines "Picklist"-Feldes sollen als Checkboxen erscheinen. VisualForce Page: < apex:selectCheckboxes value = "{!contactTypes}" >   < apex:selectOptions value = "{!contactTypesOptions}" /> </ apex:selectCheckboxes > Der Controller baut die entsprechende Auswahlmöglichkeiten zusammen: {!contactTypesOptions}  ist die Liste mit allen Werten {!contactTypes}  ist die Liste mit den Default Werten (aktive Checkboxen) Ich beschränke mich auf die Beschreibung der Liste mit allen Werten. Die folgen

Winter 14: Code Coverage wegoptimiert?

Offensichtlich war die gesamte für die Qualitätskontrolle zuständige Mannschaft von Salesforce im Urlaub als das neue Winter 14 Release fertiggestellt wurde. Beim Testen einer Klasse stellte ich fest, dass die "Code Coverage" Spalte fehlt. Die einzige Möglichkeit, sich einen Überblick über die Testabdeckung zu verschaffen, bietet die Developer Console. Hilft aber auch nur bedingt, da die Übersicht der nicht getesteten Zeilen fehlt.

Hilfetext auf VisualForce

Nach einem langen und erholsamen Urlaub in Andalusien holt die Realität schnell ein, und nun beschäftige ich mich wieder mit Salesforce, statt "Sandburgbauen". Auf einer VisualForce Page möchte ich die gelben Fragezeichen-Icons mit Hilfetexten implementieren, z.B. das Feld "Phone" aus dem "Contact". Folgende Möglichkeiten stehen dabei zur Verfügung: 1) Salesforce Standard < apex:pageBlockSectionItem HelpText = "{!$ObjectType.Contact.fields.Phone.inlineHelpText}" >   < apex:outputLabel value = "{!$ObjectType.Contact.fields.Name.label}" />   < apex:inputText value = "{!Contact.Phone}" /> </ apex:pageBlockSectionItem > Vorteil: wenig Code, Updatesicherheit 2) HTML Manchmal lassen sich die Anforderungen nicht mit Standard-APEX Tags umsetzen. Die HTML Design Elemente kommen dann zum Einsatz. So eine einfache Darstellung von Hilfetexten wird dann zu einem (lösbaren) Problem. Auf der