ya ponimaju o chem vy govorite. K sojaleniju «zaxvat» features kotoriy obespechivaet NFX
ne ocheviden v scope takix statei kak zdes, poka s etim frameworkom ne porabotaesh na neskolkix raznix zadachax
budet ne vse ponyatno. Vy mojete skazat chto eto ploxo. Pust tak. Real'no mnogie veshi
vyglyadyat ne tak kak dictuet mainstream. Typizazii configa sdelanav NFX no ne tak kak vami ojidaetsya.
Delo v tom chto config eto kak raz prekrasnoe mesto (takje kak DataAccess) dlya dynamic-like languages.
To chto tam napisan kod po injekzii dependencies — eto sdelano spezialno, no sut ne v etom (eto voobshe tema drugogo posta).
tolko-configuraziju otdelno vzyat' nelzya. ya mnogo raz govoril pochemy.
Vy mne predlagaete pisat' config v kajdom projekte svoi s nylya?
Ya je vam obyasnil chto NFX.Environment.Configuration eto ne parsanie filov a zeliy
framework, kotoriy imeet okolo 10+ features: macros, variables, recursion, injection etc…
Где можно взять пакет для чтения laconic, чтобы я мог в этом убедиться?
Laconic mojno chitat xot na urovne Lexera xot parsera no zachem?
vam nujno Configuration a ne Laconic. Laconinc, command args ili XML eto ne vajno — on sam vse poimet.
ya ne poimu smisla voobshe etogo voprosa. ya otvetil: JSON eto OBJECT notation format.
Dlya postroeniya ABSTRACTNIX ierarxiy pamyati on neudoben xotya by potomu chto
on trebyet «key»/value" mapping. Derevo v NFX etogo ne trebuet voobshe.
Naprimer vy mojete imet xot 100 noudov s odnim i tem je imenem.
Eto delaetsya legko na XMLe, t.k on format razmetki texta prosto i vse.
Laconicn udobnee XMLa v razy. Seichas u menya realno ostalos tolko neskolko starix prilojeniy
gde ispolzyetsa XML — prosto uje davno.
Esli vam lichno nujen JSON eto vashe pravo, no vy ubedites sami chto isplzovat ego vmesto Laconic formata
v razy neudobnee. Ya proverial + moi partner proveryal. My daje vybrosili JSONconfig iz NFX t.k ne bylo ni odnoi zadachi.
Laconic nikakogo otnoheniya K JSON ne imeet voobshe.
Eto format imenno dlya configa. on podderjivaet takie udobnie veshi kak:
1. bukvalnie stroki a-la C# $" i can span many lines \not escape"
2. uproshennuju grammatiku bez operatorov «my+va-+-+lue=1 2 2», imena kluchei moigyt tozhe byt strokami
3. commenti: sngle line, multi line
4. true hierarchy without root object/array requirements
i chto samoe glavnoe, chto LACONIC voobshe ne trebuetsya.
Vy mojete napisat tot-zhe file s extension XML i vse budet rabotat na XMLe
Skajite, pochemy configurazija ne mojet byt' naprimer v baze ili commandnoi stroke ili v Mongo documentax?
Pochemy configurazija ne mojet «sobiratsya» dynamicheski is raznix fomatov (naprimer v baze polya, v file XML)?
Vy chto ne ponimaete chto configurazija eto prosto ierarxija imenovanix znacheniy.
Da mojno ispolzovat JSON kak ODIN IZ formatov, no on ochen neudoben.
Kstati, kogda menya zakalibal XML, ya reshil ispolzovat JSON i napisal JSONCOnfig za gde-to 15 miunut.
Potom ya osoznal chto eto ochen neudobno, imenno v svazi s otsutstviem kommentariev
da i strukturno v JSONE v prinzipe net noudov chistoi ierarxii kotorie est v XMLe tom je
eto odin prosto primer.
potom vy mojete prosto tak «prisobachit eto v klass:
[Config]
public int CompressionLevel....
..i ne vazhno voobshe dannie prishli iz XML, INI, command args — eto prosto derevo.
Eto kak raz u vas pochemy-to kasha i tight-coupling mezhdu FORMATOM i soderjimim
configuraizja — eto derevo v pamyati.
XML laconic ili yaml — eto voobshe nevazhno.
A mojet ya xochu derjat eto v SQL servere? pochemu net.
s kakogo boku tyt JSON? on voobshe dlya etoi zadachi nikak ne podxodit
вы даже не прочитали внимательно ответ.
в JSON невозможно создать ноуд валуе без имени в принципе.
node=45{}
в ХМЛ и прочих иерархических форматах запросто.
ЙСОН это object формат, у него нет корня без аттрибутов
поэтомы я вас попросил написат на JSON- вы же даже не удосужились вникнуть в проблему —
в вашем примере будет введен «type» суррогатныи ноуд. А если ноуд с таким именем уже есть?
вообше поражает что здесь никто не пытается даже прочесть ответ, не говоря о вникании в суть
Ne zabudte — dostup cherez rekasti pointerov i transformaziju v buffer (byte*) — eto i est «psevdoserializaija» razmazannaya teper po business kody.
Kak skazal Leo_Gan, vam prodali ne dom a grudu kirpichei :)
Naprimer:
myData[«Age»] = 12345;
a esli v buffere xranitsya v BigEndian, a processor rabotaet v little endian? Eto znachit uje zamedlenie.
Tak chto nikakix chudes net i byt ne mojet. Skorost «zero-copy» resheniy eto ne skorost «write to stream» — nado meryat' vse i UCHITIVAT
«nepolnozennost buferov» — nevozmojnost rabotat s etimi dannimi cherez standartnie sredtsva yazika — a znachit eto DTO — a DTO eto govnokod :) (elsi ego mojno izbezhat')
eto kak kogda-to xranili v Delphi (naprimer) Dataset v binarnom file na diske. Rows[] — eto byl prosto (byte*)
kotoriy kastalsya cherez FiedlByName(«ColumnName»).
Eto ne serializaija. Eto format xraneniya dannix. On ne transparenten dlya raboti s obektami yazika kotorie na to i objects
chtobi s nimi rabotat (call methods, properties etc...)
ne dumaju chto takoi comparison nujen ili daje vozmojen. ServiceStack ochen malo imeet otnosheniya k NFX.
Naprimer v NFX net ORM po opredeleniju — eto sovsem drugaja metodologiya.
Ya ne sporju chto SrviceStack xorosho sdelanniy framework, esho est Castle, Lotka, NSpring i shtuk 10 drugix.
Vse oni v chem to peresekautysa, gde-to rasxodyatsya.
NFX voobshe tyt ne podxodit dlya sravneniya, on ne prednaznachen dlya «hire any 25 developers who know whats cool»
V NFX net ni odnoi «cool» fishki, ni odnogo buzworda.
Eto tem interesno kto ponimaet kak rabotaet motor vnutri
v tom chto eto ispolzuetsya v desyatkax nest, takix kak ustanoivka programmnogo obespecheniya na servera.
vy vse pytaetes dokazat chto u vas ne Unistack i vy s etim happy.
Ya i ne spory
u vas vyigrish budet togda kogda vy poimete chto pishete odno i tozhe 25 raz v kajdom proekete na 3x yazikax i 10 formatax… vot poka eto ne eknet v grudi — to NFX eto ujasniy framework ot kotorogo tolko odna golovnaja bol
Its already there for everything I need.
If you have XYZ file system then you need to implement it? no?
others will miraculously self-implement? HDFS? ACFS? GDrive?
yes you will gain a lot, because nothing will change but 1 line in config:
_include{ file="/path/to/your/file" fx{ type=«NFX.IO.SVnFileSystem, NFX.Webl» params{...your connect strings..}}}
right, and using C# one can write any software as long as C# runs on a Turing-complete vm :)
it is all about practicality. In windows you can easily map a «local drive» to some remote virtual FS. So what?
This is VERY far from being an integrated solution that works 99.9%, like we use SVNFIleSystem — it only has 300 lines of code
but guess what — it has never ever failed me.
ne ocheviden v scope takix statei kak zdes, poka s etim frameworkom ne porabotaesh na neskolkix raznix zadachax
budet ne vse ponyatno. Vy mojete skazat chto eto ploxo. Pust tak. Real'no mnogie veshi
vyglyadyat ne tak kak dictuet mainstream. Typizazii configa sdelanav NFX no ne tak kak vami ojidaetsya.
Delo v tom chto config eto kak raz prekrasnoe mesto (takje kak DataAccess) dlya dynamic-like languages.
To chto tam napisan kod po injekzii dependencies — eto sdelano spezialno, no sut ne v etom (eto voobshe tema drugogo posta).
tolko-configuraziju otdelno vzyat' nelzya. ya mnogo raz govoril pochemy.
mojno NFX zelikom t.k on UNISTACK.
pm>install-package NFX
Ya je vam obyasnil chto NFX.Environment.Configuration eto ne parsanie filov a zeliy
framework, kotoriy imeet okolo 10+ features: macros, variables, recursion, injection etc…
Smotrim tyt:
blog.aumcode.com/2013/08/aum-configuration-as-facilitated-by-nfx.html
Laconic mojno chitat xot na urovne Lexera xot parsera no zachem?
vam nujno Configuration a ne Laconic. Laconinc, command args ili XML eto ne vajno — on sam vse poimet.
smotrite v kod na primere:
driver program: github.com/aumcode/nfx/blob/master/Source/Tools/gluec/Program.cs
conf applied to class: github.com/aumcode/nfx/blob/master/Source/NFX/Glue/Tools/GluecCompiler.cs
Naskolko ya ponyal Leo_gan vzyal primer is proekta SERBENCH
kotoriy tyt:
github.com/aumcode/serbench
vse eti configi mojno napisat na XMLe, configurazija vstroena v NFX Application
koei i yavlaetsya SERBENCH.
posmotrite v kod:
github.com/aumcode/serbench/blob/master/Source/sb/sb.laconf
etot je file mojete peredelat v XML i prosto pomenyaite extension. syt taje, koda net
Dlya postroeniya ABSTRACTNIX ierarxiy pamyati on neudoben xotya by potomu chto
on trebyet «key»/value" mapping. Derevo v NFX etogo ne trebuet voobshe.
Naprimer vy mojete imet xot 100 noudov s odnim i tem je imenem.
Eto delaetsya legko na XMLe, t.k on format razmetki texta prosto i vse.
Laconicn udobnee XMLa v razy. Seichas u menya realno ostalos tolko neskolko starix prilojeniy
gde ispolzyetsa XML — prosto uje davno.
Esli vam lichno nujen JSON eto vashe pravo, no vy ubedites sami chto isplzovat ego vmesto Laconic formata
v razy neudobnee. Ya proverial + moi partner proveryal. My daje vybrosili JSONconfig iz NFX t.k ne bylo ni odnoi zadachi.
vas ot etogo ne korobit?
teper napishite eto na XML (zabudem pro laconic, on yavno mazolit glaza)
i srazy vse stanet proshe
i teper nado delat array na JSONe, v etom i neudobstvo.
To pole, to array. JSON eto OBJECT NOTATION format. XML i Laconic eto DATA delimitation format
v etom vsya razniza
Dopustim u vas est attribut «type». Ktoto sverxy predlagal ego ispolzovat. Vopros: kak vyrazit takoe derevo na JSON:
friend{name=«Ezhik» age=3 type=«CloseFriendConnection»}
ili takoe:
connect
{
site=http://yahoo.com{}
site=http://google.com{name=«Google» type=""}
}
Eto format imenno dlya configa. on podderjivaet takie udobnie veshi kak:
1. bukvalnie stroki a-la C# $" i can span many lines \not escape"
2. uproshennuju grammatiku bez operatorov «my+va-+-+lue=1 2 2», imena kluchei moigyt tozhe byt strokami
3. commenti: sngle line, multi line
4. true hierarchy without root object/array requirements
i chto samoe glavnoe, chto LACONIC voobshe ne trebuetsya.
Vy mojete napisat tot-zhe file s extension XML i vse budet rabotat na XMLe
look, this is NFX config in XML:
github.com/aumcode/nfx/blob/master/Source/Testing/Manual/WinFormsTest/WinFormsTest.configuration
Skajite, pochemy configurazija ne mojet byt' naprimer v baze ili commandnoi stroke ili v Mongo documentax?
Pochemy configurazija ne mojet «sobiratsya» dynamicheski is raznix fomatov (naprimer v baze polya, v file XML)?
Vy chto ne ponimaete chto configurazija eto prosto ierarxija imenovanix znacheniy.
Da mojno ispolzovat JSON kak ODIN IZ formatov, no on ochen neudoben.
Kstati, kogda menya zakalibal XML, ya reshil ispolzovat JSON i napisal JSONCOnfig za gde-to 15 miunut.
Potom ya osoznal chto eto ochen neudobno, imenno v svazi s otsutstviem kommentariev
da i strukturno v JSONE v prinzipe net noudov chistoi ierarxii kotorie est v XMLe tom je
konechno ona sushestvuet. mnogie veshi configuriruytsya iz XML kotoriy byl napisan esho v 2002 gody.
a kto vam skazal chto configurazija voobshe imeet kakoe-libo otnoshenie k JSON?
vot primer configurazii v NFX:
eto odin prosto primer.
potom vy mojete prosto tak «prisobachit eto v klass:
..i ne vazhno voobshe dannie prishli iz XML, INI, command args — eto prosto derevo.
Eto kak raz u vas pochemy-to kasha i tight-coupling mezhdu FORMATOM i soderjimim
configuraizja — eto derevo v pamyati.
XML laconic ili yaml — eto voobshe nevazhno.
A mojet ya xochu derjat eto v SQL servere? pochemu net.
s kakogo boku tyt JSON? on voobshe dlya etoi zadachi nikak ne podxodit
конфиг фаил на 300 строчек, из них болше 25% комменты?
example:
в JSON невозможно создать ноуд валуе без имени в принципе.
в ХМЛ и прочих иерархических форматах запросто.
ЙСОН это object формат, у него нет корня без аттрибутов
поэтомы я вас попросил написат на JSON- вы же даже не удосужились вникнуть в проблему —
в вашем примере будет введен «type» суррогатныи ноуд. А если ноуд с таким именем уже есть?
вообше поражает что здесь никто не пытается даже прочесть ответ, не говоря о вникании в суть
Kak skazal Leo_Gan, vam prodali ne dom a grudu kirpichei :)
Naprimer:
myData[«Age»] = 12345;
a esli v buffere xranitsya v BigEndian, a processor rabotaet v little endian? Eto znachit uje zamedlenie.
Tak chto nikakix chudes net i byt ne mojet. Skorost «zero-copy» resheniy eto ne skorost «write to stream» — nado meryat' vse i UCHITIVAT
«nepolnozennost buferov» — nevozmojnost rabotat s etimi dannimi cherez standartnie sredtsva yazika — a znachit eto DTO — a DTO eto govnokod :) (elsi ego mojno izbezhat')
eto kak kogda-to xranili v Delphi (naprimer) Dataset v binarnom file na diske. Rows[] — eto byl prosto (byte*)
kotoriy kastalsya cherez FiedlByName(«ColumnName»).
Eto ne serializaija. Eto format xraneniya dannix. On ne transparenten dlya raboti s obektami yazika kotorie na to i objects
chtobi s nimi rabotat (call methods, properties etc...)
so how will this look in JSON?
Naprimer v NFX net ORM po opredeleniju — eto sovsem drugaja metodologiya.
Ya ne sporju chto SrviceStack xorosho sdelanniy framework, esho est Castle, Lotka, NSpring i shtuk 10 drugix.
Vse oni v chem to peresekautysa, gde-to rasxodyatsya.
NFX voobshe tyt ne podxodit dlya sravneniya, on ne prednaznachen dlya «hire any 25 developers who know whats cool»
V NFX net ni odnoi «cool» fishki, ni odnogo buzworda.
Eto tem interesno kto ponimaet kak rabotaet motor vnutri
vy vse pytaetes dokazat chto u vas ne Unistack i vy s etim happy.
Ya i ne spory
u vas vyigrish budet togda kogda vy poimete chto pishete odno i tozhe 25 raz v kajdom proekete na 3x yazikax i 10 formatax… vot poka eto ne eknet v grudi — to NFX eto ujasniy framework ot kotorogo tolko odna golovnaja bol
If you have XYZ file system then you need to implement it? no?
others will miraculously self-implement? HDFS? ACFS? GDrive?
_include{ file="/path/to/your/file" fx{ type=«NFX.IO.SVnFileSystem, NFX.Webl» params{...your connect strings..}}}
_include{ file="/path/to/your/file" fx{ type=«NFX.IO.GITFileSystem, NFX.GIT» params{...your connect strings..}}}
btw GIT is not in NFX oper source base, because it was needed only for one closed-source project where GIt is exclusive
it is all about practicality. In windows you can easily map a «local drive» to some remote virtual FS. So what?
This is VERY far from being an integrated solution that works 99.9%, like we use SVNFIleSystem — it only has 300 lines of code
but guess what — it has never ever failed me.