Az Application modell működésének hiányosságai a legújabb Sense/Net verzióban

[VargaJoe]

Probléma leírása

Az application modellt tesztelve a jelenlegi Sense/Net verzióban az alábbi problémákat tapasztaltam:

1. GenericOdataAction CTD jelenléte, de nem elérhető:

Bár a GenericOdataAction content type definíció (CTD) továbbra is jelen van a repository-ban, ha felvesszük apps alá, nem jelenik meg az OData Actions listában. Jelenleg úgy tűnik, hogy csak a ClientActions típusú tartalmakat engedi át a rendszer.

2. Application szintű kód feloldás hiánya:

Még ha le is jönne az akció, a kód feloldása a ClassName és MethodName alapján korábban az Application rétegen történt (pl.: public class GenericODataOperation : ActionBase -> Execute -> _method.Invoke(null, p)), ami viszont az új Sense/Net verzióból hiányzik.

3. Korábbi verzióban meglévő mechanizmusok hiánya:

A korábbi verziókban volt lehetőség a GenericOdataApplication használatára, ahol a backend logikát OData actionhöz lehetett rendelni. A Contenteken be lehetett állítani a futtatni kívánt osztályt és metódust, és az Application Execute mechanizmus kezelte a megfelelő összerendelést. Az új verzióban azonban már nincs ilyen mechanizmus, csak ClientApplication típusú tartalmak vehetők fel, amelyek a kliens számára kvázi placeholderként működnek. Az OData műveletek most kódszinten vannak implementálva, amivel megszűnt az appmodellen alapuló típus és pozíció szerinti eltérő működés.

4. Új működési logika igénye:

Az új logikában a backend és a kliens oldali logika elvált egymástól. Bár sok esetben az üzleti logika a kliens oldalon valósítható meg, szükség lenne egy olyan mechanizmusra, ami lehetővé teszi, hogy az akció különböző tartalomtípusokhoz vagy struktúrában lévő pozíciókhoz eltérő viselkedést valósítson meg.
Kliens oldalon egy típusinformáció is elegendő lehet a megkülönböztetéshez, viszont a Sense/Net repository (webapp) oldalon is szükség lenne arra, hogy különböző adatcsomagot állítsunk elő a kliens számára.

Elvárt működés:

• Lehetővé kellene tenni, hogy különböző típusú tartalmakhoz azonos nevű akciókat rendelhessünk, ahogy korábbi verziókban is történt (pl. "(apps)/típusnév/akció").
• Az akciók lehetnek eltérő típusúak: például egy Car típusú content Edit akciója lehet RepairShop, míg egy Article content Edit akciója lehet WordEditor.
• A kliensnek kellene kapnia erről információt, arra az esetre, ha ott történne az üzleti logika megvalósítása.
• Sense/Net webapp oldalon a különböző akciók eltérő logikákat futtathassanak. Ez lehet osztály és metódus páros alapján (GenericOdataApplication-szerűen), contenthandler-en megcímzett metódussal, vagy a régi Application modellhez hasonló Execute mechanizmus révén.
• Az OData metódus megkapja a megcímzett application Contentet és beállításait
• A kliens nem kell, hogy előre tudja, mit fog meghívni, minden esetben ugyanazt az akciót címezheti meg, a backend logika pedig eldönti, mit kell tenni az adott akció alapján.
• Az akció eredménye a logikának megfelelő response-zal tér vissza webapp oldali végrehajtás esetén (pl. tartalom létrehozás, metaadat frissítés).

Egy javasolt megoldás:

• Az ODataMiddleware-be lehetne illeszteni egy custom logikát a GetAction és/vagy GetMethodBasedAction pontokon, hogy kezelni tudja az ilyen típusú akciókat.
• Ebben az esetben a folyamat így nézne ki:
  • A megfelelő contentekhez felvesszük a megfelelő app contenteket.
  • A kliens megkapja a tartalom elérhető akcióit az Actions listában.
  • A kliens meghívja az OData actiont az adott tartalomra.
  • Az ODataMiddleware ellenőrzi, hogy szükséges-e a custom logika futtatása, és ha igen, akkor végrehajtja a custom kódot.
  • Hagyományos OData action esetén a jelenleg is létező működés folytatódik.

Ez a megoldás lehetővé tenné a régi appmodell szerű működés visszaállítását és a különböző típusú akciók támogatásával, miközben továbbra is megmarad a kliens és backend logikák szétválasztása.

[VargaJoe]

Duplicate of #2166