Front-End és Back-End WorkFlow
Üdv,
Egy általános workflow-val kapcsolatban szeretnélek benneteket megkérdezni.Adott a következő szituáció:- Front-end design alapján elkészíti a buildet, de saját struktúrát, view templateket (mustache alapon) használva, és ebből publikál egy olyan html verziót, könyvtár struktúrát, ami a back-end-nek megfelel.
- Back-end (ASP.NET MVC) "szétszedi" a publikált html-t, View-okra, PartialView-okra, és Razor ViewEngine-t használva elkészíti az alkalmazást.
- Idő elteltével jön az igény, hogy valamit módosítani kellene az alkamazáson, Front-end elkészíti a saját megszokott view template-ein a módosításokat, publikál újra verziókezelt mappába.
- Backend verziókezelőt használva leköveti az adott módsításokat a Razor cshtml fileokon, de fileokat egyessével "végigtúrva".Gondolom látszik a fenti példából is, hogy ez így nagy alkalmazásoknál körülményes, és karbantarthatatlan, ha sűrűn változnak az igények (nem mellesleg a hibalehetőség is elég nagy), illetve ha kliens oldali template-elésről van szó (json adatot kötve template-hez), akkor a Front-end-nek ugyanúgy szüksége lehet a mustache view-okra (vagy amit ő preferál)
Gondoltunk arra, hogy ASP.NET alatt másik ViewEngine-t használnánk Nustache (.NET Mustache implementáció) használnánk, de ennek a fejlesztése relatív lassú, illetve nagyon sok mindent nem támogat, amit a Razor igen.
Front-end nem szívesen dolgozna a cshtml fileokon, ASP.NET MVC-s View, PartialView-okon, ASP.NET MVC szerinti mappastruktúrában.
Találkozott valaki hasonló problémával? Ti hogy oldanátok meg, van-e valami, amire mi nem gondoltunk?
Előre is köszi a hozzászólásokat!
■ Egy általános workflow-val kapcsolatban szeretnélek benneteket megkérdezni.Adott a következő szituáció:- Front-end design alapján elkészíti a buildet, de saját struktúrát, view templateket (mustache alapon) használva, és ebből publikál egy olyan html verziót, könyvtár struktúrát, ami a back-end-nek megfelel.
- Back-end (ASP.NET MVC) "szétszedi" a publikált html-t, View-okra, PartialView-okra, és Razor ViewEngine-t használva elkészíti az alkalmazást.
- Idő elteltével jön az igény, hogy valamit módosítani kellene az alkamazáson, Front-end elkészíti a saját megszokott view template-ein a módosításokat, publikál újra verziókezelt mappába.
- Backend verziókezelőt használva leköveti az adott módsításokat a Razor cshtml fileokon, de fileokat egyessével "végigtúrva".Gondolom látszik a fenti példából is, hogy ez így nagy alkalmazásoknál körülményes, és karbantarthatatlan, ha sűrűn változnak az igények (nem mellesleg a hibalehetőség is elég nagy), illetve ha kliens oldali template-elésről van szó (json adatot kötve template-hez), akkor a Front-end-nek ugyanúgy szüksége lehet a mustache view-okra (vagy amit ő preferál)
Gondoltunk arra, hogy ASP.NET alatt másik ViewEngine-t használnánk Nustache (.NET Mustache implementáció) használnánk, de ennek a fejlesztése relatív lassú, illetve nagyon sok mindent nem támogat, amit a Razor igen.
Front-end nem szívesen dolgozna a cshtml fileokon, ASP.NET MVC-s View, PartialView-okon, ASP.NET MVC szerinti mappastruktúrában.
Találkozott valaki hasonló problémával? Ti hogy oldanátok meg, van-e valami, amire mi nem gondoltunk?
Előre is köszi a hozzászólásokat!
XSLT
A backend feladata csak annyi, hogy a bejövő kérésre egy XML fájlt generáljon le a megfelelő adatokkal. A frontend dolga, hogy az adatokat formába (HTML-be) öntse a stíluslapok segítségével, amihez a backend sosem nyúl hozzá.
Ezer további előnye van ennek az elképzelésnek, az egyik, hogy meg lehet szabadulni a webnek attól az alapvetően hibás elképzelésétől, hogy statikus dokumentumokat kell előállítanunk.
SEO
Nem látom logikusnak, mert felesleges plusz réteget építünk be az alkalmazásba, nem beszélve arról, hogy a SEO szempontból ez elég destruktív.
Minden szerveroldali nyelvben
A plusz réteg nem felesleges, mert jelen pillanatban nálatok teljesen össze van kapcsolva a frontend és a backend. Az XSLT segítségével teljesen szétválna a két folyamat, ráadásul mindkét félnek egyszerűsödne a munkája. Ennek a technológiának ma egyszerűen nincs alternatívája (a felső két százalékba tartozó speciális igények kivételével).