Díky za dotazy
1) V dnešní době už umí validovat formulářová pole přímo prohlížeč. Tedy není nutné se s tím trápit a doplňovat JS. Ovšem absolutně nic nebrání frontend udělat na jakékoliv technologii a doplnit tam cokoliv. View není integrální součástí Jet, ale je to v aplikačním prostoru s tím, že v základu je tam Bootstrap, ale vývojář si snadno může udělat cokoliv.
V rámci Jet je de facto model, který přenáší informace z view aplikace do view prvků samotných. Jak budou prvky vypadat, to už je čistě jen na vás. To Jet jakkoliv neurčuje.
2) Ano,. porovnávám neustále. Pokud bude zájem, udělám opět srovnávací článek.
Každopádně toto je výsledek dvanácti let praktického používání. A používání na projektech, které jsou hlavně o formulářích.
Především porovnávám pracovní efektivitu. A proto jsem vytvořil Jet. Jsem schopen v něm pracovat daleko efektivněji a dělat lepší aplikace (za méně času) než v čemkoliv jiném.
Dokonce jsem se opakovaně setkal s tím, že má konkurence kroutila hlavou (pomyslně i doslova) a ptala se jak je možné určitou aplikaci a projekt vyvinout v takové kvalitě, rozsahu a tak rychle ... A já tu odpověď na otázku "jak" teď postupně uvolňuji do světa.
To nejsou subjektivní věci, ale měřitelné - reálná praxe.
V Jet platí, že méně je více: méně času, měně starostí, méně zdrojáků, méně složitostí = lepší projekty za lepší čas.
Články budu vydávat cca každé dva týdny a dostanu se určitě k dalším a dalším porovnáním.
3) Děkuji za pochvalu ;-)
Ono je to ve své podstatě logické ... Entitu zakládáte tak jako tak. Jen jednou z adminstrace, jednou z REST API, jednou z importu.
Proto formuláře nejsou zaměřené na vizuální prezentaci formulářů. To je sice také věc důležitá a v Jet propracovaná, ale jiná.
Jet Form je o práci se vstupy. A proč ty vstupy omezovat jen na to co pošle uživatel z formu, když vstup je stále vstup a je irelevantní, kde je zdroj? Validační pravidla pro entitu jsou vždy totožná. Tedy není žádný důvod mít víc validací - to je vlastně neefektivní to tak dělat.
1/ O to nejde.
Nette formuláře fungují tak, že si vytvořím validační pravidla, a ty se mi pak použijí jak na serveru, tak na klientu. Ve vašem případě, pokud jsem to pochopil správně, musím tu validaci pro klienta psát ručně. To je mínus.
2/ Určitě mě to zajímá. I kdyby se nakonec ukázalo, že máte mezery ve znalostech konkurence, tak ale vynikne vaše vize. Což bude užitečné.
3/ Pouvažoval bych o přejmenování. Formuláře jsou vizuálu formuáře.
1)
To jak se budou formuláře validovat na straně klienta (v prohlížeči) není věc PHP, ale JavaScriptu. Teda potažmo prohlížeče samotného, ale pokud to nestačí, tak JS
Jet je PHP framework, který umožňuje použít jakoukoliv technologii pro frontend, ale drží se svého "kopita" - jak se říká.
Jet nemá ambice plést se nějak zásadně do frontentdu. To je jiné hřiště. A je tam spousta schopných hráčů.
Udělat view pro formuláře s nějakou JS validací je z mého pohledu naprosto triviální věc (triviální z pohledu doplnění do Jet aplikace), kterou si ale každý může udělat dle svých potřeb a preferencí na libovolné FE technologii.
Jak jsme říkal: Jet je PHP, svou práci dělá na serveru a tam je primárně jeho hřiště.
Jasně, ukázková aplikace má i frontend - jinak by neměla smysl, ale to není a nemá být hlavní pole působnosti Jetu. Ostatně specialisté na frontend udělají svou práci lépe než já.
Ovšem velice Vám děkuji za námět. Za zamyšlenou to určitě stojí a implementačně to není nic složitého a nemělo by to nabourávat kompatibilitu (změní se view v aplikačním prostoru, ne API knihovny).
Tedy: Díky, píšu si do kolonky "pořádně si to rozmyslet".
2)
Nebojte, konkurenci znám relativně dobře a neustále porovnávám a zkoumám. To je nekonečný proces.
A proto můžu směle tvrdit a dokázat, že Jet je lépe navržen a prověřen praxí.
3)
Formuláře jak prvek frontendu, tak se musí zpracovávat na serveru.
To je z mého pohledu backend vývojáře extrémně důležité a proto je na to kladen důraz.
Tam se determinuje efektivita aplikace (jak vývoje, tak běhu), ale i bezpečnost (řešená na vstupu).
Od toho to bylo primárně navrženo - pro tento účel a proto se to jmenuje formuláře.
To že to lze bez problému použít i jinak je pouze důkazem správnosti SW architektury a celého návrhu a dodržení smyslu OOP. (Teda než někdo v budoucnu najde ještě lepší architekturu ....)
Ale Vy máte naprostou pravdu v tom, že název nemusí být výstižný.
Ano, za úvahu by to stálo - zcela určitě.
Ovšem i kdybych si to rozmyslel a našel nějaký nový supervýstižný název, tak to nepřejmenuji. Bylo by velice nešťastné framework neustále měnit a to pouze ze subjektivních důvodů. To je přesně to co nechci a jeden z důvodů proč Jet vznikl.
V žádném případě se nebude překotně měnit. To je neslučitelné s použitím ve firemním prostředí. Ostatně o tom jsem psal na samém začátku.
Jet již má nějaké uživatel. Jasně, z pohledu uveřejnění a uvedení na světlo světa je to ještě novorozenec (s vyzrálou duší), ale již je několik lidí, kteří jej používají, nehledě na to, že já sám na tom mám postaveno několik projektů a chystanou e-commerce platformy. Teď už žádná zásadní změna nepřipadá v úvahu.
Ale kvituji Váš názor. Opravdu na tom něco je a téma k zamyšlení je to bezesporu.
Přečteno 20 794×
Přečteno 18 642×
Přečteno 17 839×
Přečteno 17 594×
Přečteno 16 315×