Fiori Elements mi, Freestyle SAPUI5 mi? Doğru Yaklaşımı Seçmek

Fiori projelerinin başında hemen her zaman aynı soru sorulur: "Bunu Fiori Elements ile mi yapalım, yoksa Freestyle mı yazalım?" Cevap çoğu zaman teknik bir değerlendirmeyle değil, ekibin alışkanlığıyla verilir. UI5 bilen bir ekip her şeyi Freestyle yazar; ABAP ağırlıklı bir ekip her şeyi Elements'a sığdırmaya çalışır.

Bu yazıda iki yaklaşımın gerçekte ne olduğunu, ikisinin arasında kalan ve çoğu projede gözden kaçan üçüncü yolu ve karar verirken kullanılabilecek kriterleri kod örnekleriyle anlatıyorum. Fiori'nin tasarım prensiplerine genel bir giriş için önce Fiori ve UX yazısına göz atabilirsiniz.

Bu Seçim Neden Bu Kadar Önemli?

Bir Fiori uygulamasının maliyetinin büyük kısmı ilk sürümde değil, sonraki yıllarda ortaya çıkar: yeni alan istekleri, UI5 sürüm yükseltmeleri, yeni cihazlar, ekip değişiklikleri. Yaklaşım seçimi bu maliyetin kimin omzuna ve hangi biçimde bineceğini belirler.

• Gereksiz yere Freestyle: Standart bir liste-detay ekranını elle yazdığınızda filtre çubuğu, varyant yönetimi, tablo kişiselleştirme, Excel'e aktarma, mesaj yönetimi gibi Elements'ın hazır verdiği her şeyi siz yazarsınız — ve bakımını da siz yaparsınız.
• Zorla Elements: Şablona uymayan bir etkileşimi Elements'a sığdırmaya çalıştığınızda, framework'ün iç yapısına dayanan uzantılar birikir. Bu uzantılar ilk UI5 yükseltmesinde kırılmaya adaydır.

İki hata da geri dönüşü pahalı kararlardır; çünkü yaklaşımı sonradan değiştirmek, pratikte uygulamayı yeniden yazmak demektir.

İki Yaklaşım Aslında Ne?

Fiori Elements Pratikte: Ekranı Backend Çizer

RAP ile modellenmiş bir satış siparişi uygulaması düşünelim. CDS projection view'ı hazır ve @Metadata.allowExtensions: true ile işaretli olsun — bu katmanın nasıl kurulduğunu OData V4 / CDS yazısında adım adım anlattım. Ekranın tamamı bir metadata extension dosyasında tarif edilir:

@Metadata.layer: #CUSTOMER
@UI.headerInfo: { typeName: 'Sipariş',
                  typeNamePlural: 'Siparişler',
                  title: { type: #STANDARD, value: 'SalesOrder' } }
annotate entity ZC_SalesOrder with
{
  @UI.facet: [ { id: 'General', purpose: #STANDARD, position: 10,
                 type: #IDENTIFICATION_REFERENCE, label: 'Genel Bilgiler' },
               { id: 'Items', purpose: #STANDARD, position: 20,
                 type: #LINEITEM_REFERENCE, label: 'Kalemler',
                 targetElement: '_Item' } ]

  @UI.lineItem:       [ { position: 10 },
                        { type: #FOR_ACTION, dataAction: 'approve', label: 'Onayla' } ]
  @UI.selectionField: [ { position: 10 } ]
  @UI.identification: [ { position: 10 } ]
  SalesOrder;

  @UI.lineItem:       [ { position: 20 } ]
  @UI.selectionField: [ { position: 20 } ]
  @UI.identification: [ { position: 20 } ]
  Customer;

  @UI.lineItem:       [ { position: 30, criticality: 'StatusCriticality' } ]
  @UI.identification: [ { position: 30, criticality: 'StatusCriticality' } ]
  OverallStatus;

  @UI.hidden: true
  StatusCriticality;
}

Bu tek dosya şunları üretir: filtre çubuğunda iki alan, sonuç tablosunda üç sütun ve durum renklendirmesi, satır seçildiğinde etkinleşen bir Onayla düğmesi ve detay sayfasında iki bölüm — genel bilgiler formu ile kalem tablosu.

Onayla düğmesinin arkasındaki iş kuralı da backend'dedir. Projection behavior definition'da tek satırla dışarı açılır:

projection;
strict ( 2 );

define behavior for ZC_SalesOrder alias SalesOrder
{
  use update;
  use action approve;
}

Düğmenin ne zaman aktif olacağı (feature control), hangi doğrulamaların çalışacağı, hata mesajının hangi alana bağlanacağı — hepsi RAP davranış katmanında tanımlanır ve Elements bunları kendiliğinden yansıtır. İş nesnesi draft destekliyse, kaydedilmemiş değişikliklerin korunması da buna dahildir.

Annotation yazmadan kazandığınız şeyler de var. List Report şablonu varyant yönetimini, tablo kişiselleştirmeyi, tabloyu elektronik tabloya aktarmayı, mesaj yönetimini ve klavye erişilebilirliğini hazır getirir. Bunların hiçbiri sizin kodunuz değildir; dolayısıyla UI5 yükseltildiğinde iyileştirmeler de kendiliğinden gelir.

Freestyle Pratikte: Her Davranışı Siz Yazarsınız

Şimdi farklı bir ekran: depoda el terminaliyle çalışan bir toplama (picking) uygulaması. Kullanıcı barkodu okutur; uygulama ilgili kalemi bulur, işaretler, giriş alanını temizler ve bir sonraki okutmayı bekler. Bu ekran bir iş nesnesinin listesi değil, bir etkileşim akışıdır — ve Freestyle'ın tam olarak güçlü olduğu yer burasıdır.

<mvc:View controllerName="z.picking.controller.Main"
          xmlns:mvc="sap.ui.core.mvc"
          xmlns="sap.m">
  <Page title="{i18n>pickingTitle}">
    <Input id="scanInput"
           placeholder="{i18n>scanPlaceholder}"
           submit=".onScan"/>
    <List id="itemList"
          mode="MultiSelect"
          items="{/PickingItem}">
      <ObjectListItem title="{Material}"
                      number="{Quantity}"
                      numberUnit="{Unit}"/>
    </List>
  </Page>
</mvc:View>

sap.ui.define([
  "sap/ui/core/mvc/Controller",
  "sap/m/MessageToast"
], function (Controller, MessageToast) {
  "use strict";

  return Controller.extend("z.picking.controller.Main", {

    // Okuyucu barkodu yazar ve Enter gönderir: submit olayı tetiklenir
    onScan: function (oEvent) {
      const sBarcode = oEvent.getParameter("value").trim();
      const oItem = this.byId("itemList").getItems().find(function (oListItem) {
        return oListItem.getBindingContext().getProperty("Barcode") === sBarcode;
      });

      if (!oItem) {
        MessageToast.show(this._text("barcodeNotFound", [sBarcode]));
        return;
      }
      oItem.setSelected(true);
      oEvent.getSource().setValue("");
    },

    _text: function (sKey, aArgs) {
      return this.getView().getModel("i18n").getResourceBundle().getText(sKey, aArgs);
    }
  });
});

El terminallerindeki barkod okuyucuların çoğu klavye gibi davranır: okunan değeri giriş alanına yazar ve Enter gönderir. Bu yüzden submit olayı yeterlidir; ek bir donanım kütüphanesi gerekmez.

Kod kısa, ama dikkat edin: filtreleme, sıralama, varyant, Excel'e aktarma, sayfalama, mesajların toplu gösterimi — hiçbiri yok. Gerekirse her birini siz ekleyeceksiniz. Freestyle'ın bedeli ilk sürümde değil, bu listenin her yeni maddesinde ödenir.

Yan Yana Karşılaştırma

Freestyle'a Geçmeden Önce: Elements'ın Uzantı Noktaları

"Elements bunu yapamıyor" cümlesini duyduğumda ilk sorum şudur: hangi katmanda denendi? OData V4 tabanlı Fiori Elements'ta çözüm sırasıyla şu katmanlarda aranmalıdır:

Örneğin detay sayfasına, kalemlerin hemen ardından gelen özel bir harita bölümü eklemek manifest'te birkaç satırdır:

"SalesOrderObjectPage": {
  "type": "Component",
  "id": "SalesOrderObjectPage",
  "name": "sap.fe.templates.ObjectPage",
  "options": {
    "settings": {
      "contextPath": "/SalesOrder",
      "content": {
        "body": {
          "sections": {
            "deliveryMap": {
              "template": "z.orders.ext.fragment.DeliveryMap",
              "title": "{i18n>deliveryMap}",
              "position": { "placement": "After", "anchor": "Items" }
            }
          }
        }
      }
    }
  }
}

Bu bölümün içi tamamen sizindir: bir harita kontrolü, özel bir grafik veya üçüncü taraf bir bileşen olabilir. Sayfanın geri kalanı annotation'lardan üretilmeye devam eder. Liste tablosuna özel bir düğme eklemek de aynı mantıkla, manifest'te controlConfiguration altında tanımlanır.

Ara Yol: Flexible Programming Model

Seçimi ikili düşünmek artık güncel değil. OData V4 tabanlı Fiori Elements, Flexible Programming Model (FPM) adı verilen bir yaklaşım sunar: Elements'ın parçalarını — tablo, filtre çubuğu, form, grafik — building block olarak kendi XML view'ınızda kullanırsınız. Bu parçalar yine annotation'lardan beslenir; aralarındaki her şey sizin kodunuzdur.

<mvc:View controllerName="z.orders.ext.main.Main"
          xmlns:mvc="sap.ui.core.mvc"
          xmlns="sap.m"
          xmlns:macros="sap.fe.macros">
  <Page title="{i18n>ordersTitle}">

    <!-- Tamamen serbest: kendi kontrolünüz, kendi davranışınız -->
    <Input id="orderScanInput" submit=".onScan"/>

    <!-- Elements yapı taşları: CDS annotation'larından üretilir -->
    <macros:FilterBar id="orderFilter"
                      metaPath="@com.sap.vocabularies.UI.v1.SelectionFields"/>
    <macros:Table id="orderTable"
                  metaPath="@com.sap.vocabularies.UI.v1.LineItem"
                  filterBar="orderFilter"/>
  </Page>
</mvc:View>

Bu sayfanın controller'ı standart Controller yerine sap/fe/core/PageController'dan türetilir; böylece Elements'ın yönlendirme, draft ve mesaj altyapısı kullanılmaya devam eder. Böyle bir sayfa, normal bir List Report / Object Page uygulamasının içinde özel sayfa (custom page) olarak da yaşayabilir.

FPM'in pratik anlamı şu: "ekranın çoğu standart, bir kısmı özel" durumu artık iki kötü seçenek arasında tercih yapmayı gerektirmiyor. Filtre çubuğu ve tablo, Elements'ın varyant ve kişiselleştirme yetenekleriyle hazır gelir; siz yalnızca şablona sığmayan parçayı yazarsınız.

Bir kısıt: FPM yalnızca OData V4 tabanlı Elements'ta (sap.fe) vardır. V2 tabanlı mevcut uygulamalarda bu yol yoktur — yeni geliştirmelerde V4'ü seçmek için bir sebep daha.

Karar Verirken Sorulacak Sorular

Yeni bir uygulama talebinde şu sırayla ilerlemek, kararı çoğu zaman kendiliğinden verir:

1. Ekran bir iş nesnesi etrafında mı dönüyor? Liste, detay, oluştur/değiştir, onayla/reddet — cevap evetse varsayılan seçenek Fiori Elements'tır.
2. Backend RAP/CDS ile modellenebiliyor mu? Elements'ın kalitesi servisin kalitesini aşamaz. Servis eski bir BAPI'nin üzerine ince bir kabuksa önce servisi doğru kurmak gerekir; RAP aynı zamanda ABAP Cloud ve clean core modelinin de temelidir. Veri gerçekten modellenemiyorsa (örneğin birden çok sistemden anlık birleştiriliyorsa) Freestyle gerçekçi bir seçenek olur.
3. Şablona uymayan kısım ne kadar büyük? Bir bölüm ya da birkaç düğmeyse uzantı noktaları; bir sayfanın tamamıysa FPM custom page; uygulamanın bütünü bir etkileşim akışıysa (tarama, planlama panosu, sürükle-bırak) Freestyle.
4. Bakımı kim yapacak? Şirkette UI5 geliştiricisi yoksa ve olmayacaksa, Freestyle uygulama ilk değişiklik isteğinde sahipsiz kalır. Bu kriter teknik kriterler kadar ağır basmalıdır.
5. Uygulamanın ömrü ne kadar? Birkaç ay kullanılacak geçici bir araçla yıllarca yaşayacak bir çekirdek süreç uygulaması aynı şekilde değerlendirilmez. Uzun ömürlü uygulamalarda UI5 yükseltme maliyeti belirleyicidir.

Sık Yapılan Hatalar

Sonuç

Fiori Elements ile Freestyle arasındaki seçim bir zevk meselesi gibi görünse de aslında bir sahiplik kararıdır: ekranın tarifi backend'de mi yaşayacak, frontend kodunda mı? Kurumsal uygulamaların önemli bir kısmı liste, detay ve işlem kalıbına uyar; bu uygulamalar için Elements hem daha hızlı teslim edilir hem de yıllar içinde daha ucuza yaşar.

Freestyle gereksiz değildir — yalnızca istisna olmalıdır. Etkileşimin kendisi şablonun dışındaysa doğru araçtır. İkisinin arasındaki geniş alanı ise artık uzantı noktaları ve Flexible Programming Model kapatıyor.

Bir sonraki Fiori talebinde ilk soru "hangi teknoloji?" değil, "bu ekran hangi iş nesnesinin etrafında dönüyor?" olsun. Fiori projelerinde sunduğum kapsamı Fiori & UI hizmet sayfasında bulabilirsiniz.