Open jaanleppik opened 2 years ago
Collectioni muutmine: Person / People collectionis on praegu muutujate süntaks camelCase. Teeme Person collectionit ümber - kas siin teha ka muutujate nimetused ümber snake_case'i? Kui suure töö see kaasa toob, et kõik Personi andmeid kasutavad koodi osad seda kasutada oskaksid? Peaks hindama, enne, kui otsustada ja teha.
Kõlab nagu parajalt suur tegemine... kui juba otsida VSC-s faile kus persooni kasutatakse, siis vähemalt ca 60 faili ja 1000+ rida mida checkida ja vajadusel muuta.
COLLECTIONS
uued: SmartFolder DumbFolder
muudetud: PatternCollection UserFunction UserRole
COMPONENTS
uued: FunctionParameters
muudetud: Conditions (enne FunctionConditions) UserRight
lisatud Person collectionisse uued väljad acc_imdb acc_efis acc_castupload acc_instagram acc_fb acc_other tag_secrets
@LiisKasper palun modeli update
Person collectionisse veel muutujaid: webpage_url industry_person_types (rel) tag_looking_fors (rel) slug_et slug_en slug_ru public
repr_org_name repr_p_name repr_phone repr_email repr_org_url
veel 1 acc_etalenta
skills_et skills_en skills_ru
Lõin 2 uut collectionit:
Mõte on saada avatud list märksõnu, mida saab kategooriatesse ja sektsioonidesse jagada. Umbes nagu AirBnB teeb. E nii saame idee poolest paindliku süsteemi, mida saab edasi ehitada juba peamiselt Admin keskkonna kaudu, ilma olulise progemiseta. Alustasin ka TagLocation ja TagCategory collectionite täitmist.
Relatsioonid nende vahel püüdsin teha seda pidi, nagu neid strapist päritakse. Nüüd tekib küll olukord, kui Location collectioni juures tuleb pärida relationi taga oleva objekti edasist relationit. Nii vormi täites - kasutaja poolt täites ja Strapi poolt vormi infot kuvades - kui ka locationi lehte ehitades:
TagCategory juures on ka Boolean valik - see tähendab, et selle all olevad vaikud on booleanina - 1 või teine.
Ja mõte on vormi kaudu infot kogudes luue iga valitud TagLocationi ja Locationi vahele seos kindlasti ka otse, lisaks TagCategory kaudu seose loomisele.
@LiisKasper palun mõtle see kriitiliselt läbi. Ja täienda modelit.
Lisaks tahaksin selle Locationi nö ajaloolise e varasema osa natuke ymber tuunida - need viited riigile, linnale, kinole ja saalile.
@LiisKasper
mõtleks, kas saame Personi ja Organisatsioni collectionite struktuuri ühtlustada, ideaalis pea identseks muuta?
mõte on selles, et siis saaks pea sama vormi kaudu sisestada ka organisatsioone.
need tuleks siis mingil määrl ümber teha. Olen alustanud Personi ja Org ühtlustamist. Aga ma arvan, et peaks ka nimed ja descriptionid lapikuks tegema, type (enumeration väli) ära kaotama jne. Organisatsion vajaks ka aadressi infos oleva kaardiasukoha kuvamist - aga see oleks aadressi info kaudu. Nii et ses mõttes ei puuduta Organisatsioni collectionit.
TagCategory juures on ka Boolean valik - see tähendab, et selle all olevad vaikud on booleanina - 1 või teine.
Tean, mis on boolean. Antud kontekstis ei saa päris täpselt aru, mida sellega mõtled. Category: Ownership, valikud on ERA ja AVALIK Selle kategooria (Ownership) all olevad valikud ERA ja AVALIK ei tohiks olla korraga tõesed ja vormis peaks neist saama valida ainult 1. https://admin.poff.ee/admin/plugins/content-manager/collectionType/application::tag-category.tag-category/1 Pole jah kõige õnnestunud nimetus :) Peaks ümber nimetama, mõtlen
@LiisKasper palun mõtle see kriitiliselt läbi. Ja täienda modelit.
täiendada hetkel ei oska, kui täidab eesmärki, siis vast on hästi. Location collectioni all on kaks remote id välja (remoteId ja remote_id), see tuleks täpsustada/ ümber muuta. Päringute sügavus siin ilmselt probleemiks ei saa, collection sees olevat collectionit saab eraldi pärida ja info peaks kenasti kätte saama.
Lisaks tahaksin selle Locationi nö ajaloolise e varasema osa natuke ymber tuunida - need viited riigile, linnale, kinole ja saalile.
Meeldetuletuseks! Kõigi tuunimistega/mudeli muutmistega tuleb arvestada, et kui vanast ajast on info sees siis see läheb kaduma, kui välja nime lihtsalt muudad vms. Lisaks kindlasti miski kuskil kasutab olemasolevat.
@LiisKasper mõtleks, kas saame Personi ja Organisatsioni collectionite struktuuri ühtlustada, ideaalis pea identseks muuta?
Saame ikka sarnasemaks muuta. Kuigi see vist ei ole üldse hea praktika, muuta mudelit selleks, et ühte vormi oleks lihtsam kasutada.
- kus me organisatsiooni infot praegu lehel kasutame ja fetchime?
esmane sõna 'organisation' otsing koodis annab vasteks 340 matches across 92 files
visitest_id on nyyd teine remote id'd tähistav väli collectioni all. @LiisKasper palun uuenda datamodelit ja siis lükkammuudatused MAINäi kah, nagu Martin möödunud nädalal rääkis. Siis saan hakata locationi vormi ehitama.
tegin address collectionisse uue välja: hr_address sinna peaks Strapis kokku kirjutama nende väljade väärtused: street_name address_number appartment postal_code municipality county country
komadega eraldatuna eesmärk on saada relatsiooni jaoks inimloetav väli, kui tahta strapis näiteks organisatsioonile või persoonile aadressi valida
või mis sa @LiisKasper arvad? kuidas saada Strapis liita org või persooni ja aadressi?
Väli on tehtav. Aga inimese v org aadressi valmisest oleme rääkinud. Minu arust peab olema igal oma aadress, mida saab luua ja muuta aga mitte valida endale aadressi. Ei tohi tekkida olukorda, kus kahel inimesel on sama aadress ja üks muudab teise oma. St viide on samale collectionile
courseEventt collectionisse lisasin chat_w_name välja, nagu filmil. Palun modeli update.
Väli on tehtav. Aga inimese v org aadressi valmisest oleme rääkinud. Minu arust peab olema igal oma aadress, mida saab luua ja muuta aga mitte valida endale aadressi. Ei tohi tekkida olukorda, kus kahel inimesel on sama aadress ja üks muudab teise oma. St viide on samale collectionile
Seda ma tahaks kasutada ainult Strapis, et ei viitaks - nimega objektidele :) Aga jah, kui sa tahad välistada ka nende aadresside ja relatsioonide muutmist Strpai tasemel - see on jah rangelt võetuna põhjendatud. Aga lugeda tahaks ikka... E olukord, kui ma näen persooni, aga addressi relatsiooni kohal on viide objektile nimega "-"... võibolla polegi vaja, aga kui tahan mingt google koordinaatide infot muuta, parandada, kasutaja pooliku töö lõpuni teha - siis oleks vaja toimetada.
loodud uus komponent RemoteImg organisation collectionisse said uued väljad: name_et name_en name_ru descrition_et descrition_en descrition_ru ja repeatable komponent remote_img
fetcher ei saa kätte TagLocation ja TagCategory collectionites olevat infot colectionites on info olemas settingutes on Maintenance rollile õigused antud aga buildil . [146ms] (0), Fetching every TagCategory Status 404 { headers: { 'Content-Type': 'application/json', Authorization: 'Bearer ....' }, hostname: 'admin.poff.ee', path: '/tag_categories?_limit=-1', method: 'GET', full_model_fetch: true } ""
milles võib asi olla?
Collection 'Origin' Collectionisse 'Organisation' relatsioon collectionile 'Origin'
lisasin Address collectionile Google mapsi embed lingi välja gm_embed ja Plus Code välja plus_code
Locationi alla olin unustqanud lisada relataiooni TagLocation nyyd lisasin
Collection 'Origin' Collectionisse 'Organisation' relatsioon collectionile 'Origin'
datamodelisse lisasin origin aga seost organisationiga ei näe mis eesmärgil selline väli?
Ma arvan, et origin on vajalik eristamaks, kas näiteks organisatsioon on loodud Visitestonia API kaudu või mull viisil. Seda on vaja eristada, sest Visitestonia info kasutamiseks on piigangud. Organisatsioonide ehitamisel vajalik siis lugeda Origin välja.
Ja ka persoonide kohta - kas vormist või muul viisil tekkinud info. Kah hea yhelt väljalt seda lugeda.
Võibolla saab ka teisiti, kausemalt kindlasti, aga ma arvan, et on hea omada eraldi välja päritolu salvestamiseks.
(ei leia praegu kuhu selle juba varem kirja panin :)
Organisationi alla tegin nyyd kah relatsiooni ära. Ja PERSON'i alla kah. Tundub, et eelmine kord onn see teema pooleli jäänud mul.
Lisasin Business profile collectionisse relatsiooni PÖFFArticle'le, relatsiooni nimi terms_p mõte on sellest, et meil on vajalik eri omanikega toodetel kuvada erinevaid tingimustega nõustumise artikleid. Kui tekib võimalus shop'i panna ka teistele domeenidele, siis vaja selline seos ka teiste domeenide artiklitega. Ja see seos oleks siis Product_category -> Business Profile -> terms_p E küllalt sügav. Mis sa @LiisKasper arvad, ka Business Profile juures peaks see olems hoopis komponendina, et seal oleks valmis teiste domeenide artiklitega seos, või on parem teha palikult - näiteks terms_p, terms_i (nagu Industry), terms_dc nagu Discoverycampus jne?
Relatsioon collectionile tundub parem. Seni on komponendid pigem probleem olnud seega mina teeks terms_p, terms_i jne, nagu alustasid.
Filmography collectionisse lisasin uue tekstivälja work_director palun datamodelisse ja MAIN'i kah, nagu Martin juhendanud
Filmography collectionisse lisasin uue tekstivälja work_director palun datamodelisse ja MAIN'i kah, nagu Martin juhendanud
Lisasin datamodelisse uue välja ja panin maini. Ei tea mida pead silmas ... nagu Martin on juhendanud all!
personi collectionisse lisasin relatsiooni industry_categories palun modelisse ja Main'i
Location collectionisse lisatud relatsioon Origin Palun mudelisse ja palin juhendist, kuidas seda serverist MAIN'i panna
lisasin Person collectionisse looking_for tekstivälja Palun mudeliseed ja Main'i
Location collectionisse lisatud relatsioon Origin Palun mudelisse ja palin juhendist, kuidas seda serverist MAIN'i panna
Pean edaspidi meeles seda ise teha.
lisasin courseevent collectionisse button komponendi, ühekordse komponendina paliun mudeli muutust ja Main'i lykkamist.
Organisation collectioni all uued väljad: tag_looking_fors looking_for phoneNr eMail
Palun mudelisse ja MAINi
CourseEvent collectionisse lisasin relatsiooni industry_people (collectionile Industry_People) Palun mudelisse ja MAIN'i @LiisKasper
Et mudel saaks arvestada ja fetch saaks arvestada:
EyeColours https://admin.poff.ee/admin/plugins/content-manager/collectionType/application::eye-colour.eye-colour?page=1&pageSize=10&_sort=name_et:ASC
HairColours https://admin.poff.ee/admin/plugins/content-manager/collectionType/application::hair-colour.hair-colour?page=1&pageSize=10&_sort=name_et:ASC
Statures https://admin.poff.ee/admin/plugins/content-manager/collectionType/application::stature.stature?page=1&pageSize=10&_sort=name_et:ASC
PitchOfVoices https://admin.poff.ee/admin/plugins/content-manager/collectionType/application::pitch-of-voice.pitch-of-voice?page=1&pageSize=10&_sort=name_et:ASC
TypeOfWorks https://admin.poff.ee/admin/plugins/content-manager/collectionType/application::type-of-work.type-of-work?page=1&pageSize=10&_sort=name_et:ASC
PopulatedPlaces https://admin.poff.ee/admin/plugins/content-manager/collectionType/application::populated-place.populated-place?page=1&pageSize=10&_sort=name_et:ASC See on eesti aadressisüsteemi kolmas level e lõppasula peale RIIKI ja MAAKONDA. Saab kasutada ka yldisemalt, välja labeli nimetamise kaudu. Ja täitsin eesti maakondadega ja populatued placedega collectionid ära praegu. Mõte selles, et välismaa aadresside komponente hakkaks lisama samasse struktuuri? Arutamise teema, et kas aadresside info salvestatakse lisaks konkreetsele aadressile veel ka collectionisse, mis aadressi selle tasandi infot kannab, või mitte? Praegu on siis seotud Eesti kui riik ja selle maakonnad, maakonnad ja selle populated places (vallad ja linnad).
Countries, Counties, PopulatedPlaces - eesti puhul kuni tänavani saab siis sellest valikust aadressi moodustada.
Aadress ise on komponendina. Selline Eesti sisene täpsus / standardiseeritus on vajalik, kuna eesti filmipersoone ja võttekohti peab maakondade / valdade / linnade kaupa täpselt jagama.