Google tabelist Industry_Project'i ja Industry_Eventi kirjutamine

[jaanleppik]

Teeme algust Google tabelist, fimid / RAW tabeli eeskujul, Industry_Projecti ja Industry_Eventi Straoisse kirjutamisega. Alustaks tabelitega, kust kirjutada (RAW) Strapisse, ja mille struktuur peegeldaks Strapis IP ja IE struktuure.

Ja küsimus sel teemal aruteluks: kui palju on Strapi tasemel sarnasusi HTML vormist ja Google tabelist Strapisse kirjutamisel? E kui suur on nende arenduste ühisosa?

[LiisKasper]

Mis ajaks esimene prototüüp valmis peaks olema? Äkki on see hea koht, kus katsetada custom endpoint'ide tegemist.

[LiisKasper]

indusryEvent viitab IndustryProjectile, kas neid toimetatakse ühest tabelist? Lisaks on mõlemal collectionil mitmeid viiteid teistele objektidele (ProjectType, ProjectStatus, Organisation, Awardings jne). Kas neid toimetatakse Strapis v tabelites? Samades tabelites v erinevates? Kas on mingi ajaline järjestus, mida enne toimetatakse?

[jaanleppik]

Viited teistele objektidele - seda saaks samuti teha mirrori kaudu? Kõik omadused peaks saama tabelis ära kirjeldada. St kui on ainult viited teistele, siis saaks Strapist Mirrorisse info ja Mirrosi info on siis valikutes, reklatsioonide kohal. Nagu filmide tabelis on kõik need keeled ja festival editionid ja festivalid ja programmid. See kah toimib nii, et valikus on ainult Strapis olev info, e otse mirrorist täidetakse dropdownid põhimõtteliselt.

Ajaline järjestus on hea küsimus - mõtlen ja arutame. et kui on näiteks vastastikune viitamine - kuidas siis peaks ajaline järjestus olema? :)

Custom Endpointide teemat arutaks esmaspäeval?

[LiisKasper]

Saan aru, et siis muu info täidetakse Strapis ja Starpis olemasoleva infoga täidame relatsioone IndustryEvent ja IndustryProject juures. Ka IndusryPerson saab täidetud Strapis ja Awardings jne. Mirroris on info, mis on juba Strapis. Jah, mirrori kaudu saame viidata teistele objektidele. Küsimus rohkem, kas seda infot hakatakse sisestama läbi tabeli v läbi Strapi? Hetkel nt FestivalEdition, Festival ja Programme on Strapis täidetud ja loeme olemasolevat infot.

[LiisKasper]

Proovime edaspidi lahendada tabelist kirjutamised läbi custom endpointide. Teemaga läheme edasi, kui @jaanleppik annab tabelite põhjad, millega toimetajad tööd teevad. Seni : isuue #487

[LiisKasper]

infoks: IMPORTRANGE drawbacks Poor import performance if multiple IMPORTRANGE formulas are used. The more IMPORTRANGE formulas your spreadsheet has, the more time it will require to process requests. At some point, it can even stop working completely. Data loads only when the spreadsheet is open. The imported data may not be available until you open the spreadsheet with the IMPORTRANGE formula. This is troublesome if the data in the spreadsheet is synchronized with a third-party app or tool. Limited functionality. With IMPORTRANGE, you can’t import the entire sheet; you have to specify a cell range; you can’t schedule data import; you can’t import a consolidation of sheets from a spreadsheet, etc. If you’ve faced any of the issues above, you might need an alternative to IMPORTRANGE.

allikas: coupler.io blog