--- title: "Mértékegység-átváltó: Hőmérséklet" slug: "unit-converter-temperature" status: "new" updated: 2026-10-22T16:42:04Z published: 2026-10-22T16:42:04Z canonical: "support.tulip.co/unit-converter-temperature" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.tulip.co/llms.txt > Use this file to discover all available pages before exploring further. # Mértékegység-átváltó: Hőmérséklet To download the app, visit: [tulip](https://Library Ebben a cikkben Tamás, a könyvtár egyik fejlesztője, végigvezeti az olvasót a könyvtárban elérhető „Unit Converter: Temperature” építőelem-alkalmazás fejlesztése során hozott döntéseken. ## Miért használtam objektumlistát táblázat helyett Sziasztok, Tamás vagyok a Tuliptól. Ennél a komponensnél úgy döntöttem, hogy alapértelmezett változóértékekként tárolt objektumlistát használok, mivel az adatkészlet ritkán változik, és nem igényel táblázatalapú kezelést. Ebben az esetben a hőmérséklet-átváltási tényezők és eltolások statikus matematikai összefüggések. Nem igényelnek futásidejű szerkesztést, összesítést vagy relációs lekérdezést. Emiatt szándékosan elkerültem a táblázat használatát. Ehelyett: * Az átváltási definíciókat egy változóban tárolom * A változót alapértelmezett értékekkel inicializálom * Az objektumlista strukturált és olvasható adatnézetet biztosít * Nincs szükség táblázati összesítési logikára Ez a megközelítés biztosítja, hogy a komponens könnyű és önálló maradjon. ## Miért nem táblázat? A táblázat használata a következőket vonná maga után:* Szükség lenne egy további táblázat hozzáadására az alkalmazáshoz* Szükség lenne egy lekérdezés létrehozására az adott táblához* Szükség lenne az adott lekérdezéshez tartozó összesítési logika konfigurálására* Szükség lenne az adott lekérdezés és összesítés hozzáadására és karbantartására az alkalmazáson belül is Egy ritkán változó adatkészlet esetében ez a többletmunkára nincs szükség. Ha az átalakítási definíciókat alapértelmezett értékekként tároljuk egy változóban:* A komponens teljesen hordozhatóvá válik* Az alkalmazás másolásakor az adatstruktúra is átkerül* Nincs szükség külső függőségre Az objektumlista tiszta, strukturált képet ad a kapcsolódó attribútumokról (inputUnit-targetUnit, factor, offset) anélkül, hogy relációs logikára lenne szükség. ## Tervezési elv: Védett logika, rugalmas konfiguráció A komponenst egy kulcsfontosságú elv alapján tervezték: > A maglogikát soha nem szabad módosítani. Ennek támogatására bevezettem belső komponensváltozókat, és azokat előtti aláhúzással jelöltem (például **_temperatureInputUnit**). Ezek az aláhúzással jelölt változók stabil belső interfészként működnek, amelyekre a védett alapvető logika támaszkodhat. **Kompromisszum:** a belső változók használata két kis konfigurációs triggert igényel:* 01 – USER CONFIG: INPUT STAGE a külső forrásokat belső változókhoz rendeli* 03 – USER CONFIG: OUTPUT STAGE a belső eredményt a kívánt célhoz rendeli Ez egy vékony konfigurációs réteget ad hozzá a védett motor köré, de a MAGIC-triggert érintetlenül hagyja, és továbbra is könnyen másolható és beilleszthető marad. ### Alternatív lehetőség Egy egyszerűbb – de nehezebben karbantartható – megközelítés az lenne, ha a külső hivatkozásokat közvetlenül a magkifejezésbe illesztenénk be (például egy app változó vagy egy table record field helyőrző használatával). Ezzel elkerülhetők a felesleges konfigurációs triggerek, de csökken a hordozhatóság, és nehezebbé válik az újrafelhasználás, mivel minden másoláskor módosítani kell a maglogikát. A komponensek terjesztése szempontjából a belső változós interfészminta könnyebben kezelhető: a bemeneteket és kimeneteket a peremeken konfigurálják, míg a számítási motor stabil és védett marad. A MAGIC-trigger keresést hajt végre, és affín transzformációt alkalmaz: > eredmény = (érték × tényező) + eltolás Mivel az átalakítási definíciók központosítva vannak a belső objektumlistában, a trigger módosítás nélkül képes kezelni többféle esetet is. Ebben a megvalósításban:* °C, K és °F támogatott* Az összes 3×3-as kombináció előre definiált* A logika dinamikusan határozza meg a megfelelő szorzót és eltolást Az alkalmazáskészítőnek csak a következőket kell tennie: 1. Konfigurálnia kell a bemeneti forrásokat 2. Konfigurálnia kell a kimeneti célokat Nincs szükség képletek átírására. Nincs szükség a feltételes logika szerkesztésére. Nincs szükség szerkezeti változtatásokra. ## Miért skálázható ez? Ez a felépítés lehetővé teszi:* Új mértékegységek hozzáadását az objektumlista kibővítésével* A számítási motor változatlanul hagyását* Az architektúra konzisztenciájának fenntartását az alkalmazások között* A gyors újrafelhasználást több projektben A komponens szétválasztja:* Az adatforrás konfigurációját (bemeneti szakasz)* A végrehajtási logikát (MAGIC)* Az eredmény továbbítását (kimeneti szakasz) Ez az elválasztás biztosítja a rendszer biztonságát, kiszámíthatóságát és skálázhatóságát. ## A trigger lebontása – Hogyan működik a MAGIC (kifejezés) A védett MAGIC-trigger egyetlen kifejezésként van megvalósítva:`(@Variable._temperatureInputValue * array_value_at_index( map_to_number_list(@Variable._temperatureConversionDefaults , 'factor'), array_index_of( map_to_text_list(@Variable._temperatureConversionDefaults , 'inputUnit-targetUnit'), @Variable._temperatureInputUnit + '-' + @Variable._temperatureTargetUnit )))+array_value_at_index( map_to_number_list(@Variable._temperatureConversionDefaults , 'offset'), array_index_of( map_to_text_list(@Variable._temperatureConversionDefaults , 'inputUnit-targetUnit'), @Variable._temperatureInputUnit + '-' + @Variable._temperatureTargetUnit ))`Általánosságban ez a kifejezés három lépést hajt végre: ### 1. A keresési kulcs létrehozása A kulcs dinamikusan épül fel a konfigurált bemeneti változókból: > inputUnit-targetUnit Például: > °C-°F Ez biztosítja, hogy a logika általános maradjon, és minden támogatott kombináció esetén működjön. ### 2. A szorzó és az eltolás kiszámítása az objektumlistából A kifejezés egy lépésben határozza meg a szorzót és az eltolást:* **A map_to_text_list(..., 'inputUnit-targetUnit')** parancs menet közben építi fel a keresési kulcsok listáját.* **array_index_of(...)** megkeresi a megfelelő kulcs indexét.* **array_value_at_index(...)** ezt az indexet használja fel a megfelelő értékek lekérésére a szorzó- és eltolási listákból. A legfontosabb tervezési döntés itt az, hogy **az array_index_of(...) függvényt** közvetlenül **a map_to_text_list(...)** függvénnyel kombináljuk. Ezzel elkerülhető, hogy egy köztes kulcslistát külön változóban tároljunk. Ehelyett a keresési lista inline módon generálódik, és azonnal felhasználásra kerül a tényező és az eltolás lekérésére egyetlen kifejezésen belül. Ezáltal a MAGIC trigger önálló marad, és csökkenti a konfigurációs felületet, miközben továbbra is strukturált keresésként viselkedik – táblázat vagy összesítési logika nélkül. ### 3. Az affín transzformáció alkalmazása Miután a helyes szorzó és eltolás meghatározásra került, a számítás végrehajtásra kerül: > eredmény = (érték × tényező) + eltolás Mivel a keresési logika indexalapú és adatvezérelt, a trigger nem igényel feltételes elágazásokat vagy switch-case szerkezeteket. ## Miért választották ezt a szerkezetet? - Elkerüli a merev kódolású feltételes logikát. - Természetesen skálázódik, ha új egységkombinációk kerülnek hozzáadásra. - A számítás teljes mértékben adatvezérelt marad. - Egyetlen védett kifejezést tart fenn több trigger helyett. Ez a kialakítás biztosítja, hogy a komponens determinisztikus, bővíthető és védett legyen a véletlen logikai módosításoktól. ## Bővítés új mértékegységekkel Új mértékegység hozzáadásához bővítse a _temperatureConversionDefaults objektumot egy új bejegyzés hozzáadásával, amely a következőket tartalmazza:* inputUnit-targetUnit (kulcs)* factor* offset Amint az új leképezés megjelenik az objektumlistában, a védett MAGIC-trigger automatikusan feloldja azt – nincs szükség a maglogika módosítására. ### Hibakezelés (biztonságos keresési minta) A MAGIC trigger kifejezett hibaérzékelést tartalmaz, hogy biztosítsa a biztonságos végrehajtást, ha nem található konverziós pár. Ahelyett, hogy üres eredményre támaszkodna, a trigger közvetlenül ellenőrzi a keresési indexet: > ARRAY_INDEX_OF( MAP_TO_TEXT_LIST(_temperatureConversionDefaults, 'inputUnit-targetUnit'), _temperatureInputUnit + '-' + _temperatureTargetUnit ) Ha a visszatérő index értéke -1, akkor nincs megfelelő átváltási szabály. Végrehajtási folyamat: 1. A trigger elején törölje a _temperatureConversionResult változót. 2. Ha a keresési index = -1 → ne végezzen számítást. 3. Egyéb esetben → végezze el a számítást, és tárolja el az eredményt. Az OUTPUT szakasz ezután ellenőrzi: Ha a _temperatureConversionResult üres → hibaüzenet megjelenítése. Példa üzenetre: > „A kiválasztott mértékegység-párhoz nem található átváltási szabály. Ellenőrizze a mértékegység formátumát (°C, K, °F), és hogy a pár szerepel-e a _temperatureConversionDefaults-ban.” Ez biztosítja:• Hogy a korábbi futtatásokból ne maradjanak elavult értékek • Hogy érvényes szabály nélkül ne történjen számítás • Hogy a felhasználó egyértelmű és cselekvésre ösztönző hibaüzenetet kapjon A maglogika védett és változatlan marad, miközben továbbra is determinisztikus és biztonságos viselkedést biztosít. ## Miért nem használunk külön tömböket a kulcsok, a tényezők és az eltolások számára? Egy alternatív megközelítés az lett volna, ha a következőket tároltuk volna:* A keresési kulcsokat egy tömbben* A tényezőket egy másik tömbben* Az eltolásokat egy harmadik tömbben Bár ez technikailag működne, strukturális kockázatot jelentene: a tömbök közötti pozicionális kapcsolatnak mindig tökéletesen összehangoltnak kell maradnia. Ha az egyik tömb sorrendje megváltozik, a többié pedig nem, a kulcs–tényező–eltolás közötti kapcsolat észrevétlenül megszakadna, ami helytelen átalakításokat eredményezne. Az egymással összefüggő attribútumok objektumlistában való együttes tárolásával minden bejegyzésnél az **inputUnit-targetUnit**, **a szorzó** és **az eltolás** értékei logikailag csoportosítva maradnak. Ez csökkenti az eltolódás kockázatát, és biztonságosabbá, valamint könnyebben karbantarthatóvá teszi a struktúrát. ## **Csatlakozz** [Csatlakozz a közösséghez](https://community.tulip.co/), hogy megoszthasd a fejlesztési javaslataidat, új mértékegységeket javasolhass, hibákat jelenthess, vagy megvitathasd az architektúrával kapcsolatos döntéseket.