Direkt zum Hauptbereich

Posts

Es werden Posts vom Juli, 2013 angezeigt.

Darstellung mehrerer Spalten in VisualForce

Zur Abwechslung möchte ich die APEX-Welt verlassen und eine kleine, aber keine triviale Aufgabe in Bezug auf die Frontend-Programmierung beschreiben.
Ich habe eine VisualForce Page, die als Suchmaske fungiert. Es gibt eine Hand voll Felder, die in einem Block mehrzeilig und mehrspaltig dargestellt werden. Insgesamt gibt es 3 Zeilen und 3 Spalten.

Problem: die letzte Spalte wird auf die minimale Breite zusammengedrückt, so dass es einen Umbruch in den Feldbezeichnungen gibt.


In meinem Konstrukt gibt es viele Felder mit Default-Werten. Aus dem Grund muss ich auf die einfache Darstellung eines Feldes <apex:inputFieldvalue="{!myObject.name}"/> verzichten.
Statt dessen sieht der Aufbau eines Feldes so aus:
<apex:pageBlockSectionItem>   <apex:outputLabelvalue="{!$ObjectType.myObject.fields.City__c.label}"/>   <apex:inputTextvalue="{!City}"/> </apex:pageBlockSectionItem>
Lösung: die Richtung ist schon mal klar - ich muss die Spaltenbrei…

SOQL vs. getRecord()

Die Entwicklung von VisualForce Seiten ist zwangsweise mit der Entwicklung von Apex-Controllern verbunden. Meistens greift man auf die Standard-Controller zurück und erweitert die Standard-Funktionalität wie z.B. "Save" oder "Close" um weitere Funktionen. Die neuen Funktionen werden in einer neuen Klasse entwickelt, die als "extensions" in die VisualForce Seite eingebunden ist, z.B.


<apex:pagestandardController="Lead"extensions="LeadConvert">
Meistens muss entweder der aufgerufene Datensatz oder die mit diesem Datensatz verknüpften Datensätze modifiziert werden. Um eine Instanz des aufgerufenen Datensatzes zu erzeugen, stehen zwei Methoden zur Verfügung.

1) Klassische SOQL Methode:
Lead leadObj = [Select id, name, Firstname, Lastname fromLeadwhereid=:idParameter limit 1];

in der "idParameter" zuerst berechnet werden muss:

idParameter = Apexpages.currentPage().getParameters().get('id');

2) getRecord Methode:

Lead lea…

Case-Anlage als Portal Benutzer

Beim Entwickeln und Testen einer neuen Funktionalität für Portal Benutzer, die Cases einstellen dürfen, bin ich auf ein interessantes Systemverhalten gestossen.
Kurze Beschreibung:
ein Portal Benutzer erstellt einen neuen Case. Das Feld "Account" bleibt leer, bzw. dieses Feld hat die Eigenschaft "Read only" für Portal Benutzer und ist somit nicht editierbar.

Nach dem Speichern und dem erneuten Öffnen des Cases ist das Feld "Account" gefüllt.

Recherche:
ich war mir ziemlich sicher, dass hier ein Trigger im Spiel ist. Nachdem ich die Ressourcen untersucht habe, stellte ich fest, dass es keine programmierte Funktion gibt, die den Account berechnet und im Case abspeichert.
Nach einigen Tests, unter anderem mit der neu entwickelten Funktion, war das Muster erkennbar:
* ein Portal Benutzer impliziert die Existenz der beiden Datensätze "Contact" und "User" im System
* ein Contact ist zwangsweise mit einem Account verknüpft
=> der mit dem Con…