Looks like most folks are looking for more direction, some explicit, some general. This is a good thing. But you can only do what you have documentation on. The rest falls under Relativity knowledge, documentation, task delegation and design comps.
I'll do my best to address the ticket feedback so far:
1: Machine Names
a: Each independent content type has an explicit machine name
ex; News Content type - machine name = news
ex; Session Content type - machine name = sess
all fields contained on the News Content Type begin with news_
ex; Body - machine name = newsbody
all fields contained on the Session Content Type begin with sess
ex; Body - machine name = sess_body
b: The machine name is used for indexing and visual reference
when naming fields, always remember to follow the machine name call out, but keep your field read-
able by others. If it's an image, be sure that everyone can see it's an image
ex; Hero - machine name - hero
Hero Image - hero_image
2: Entity References
a: All Entity References begin in a content type and then reference a content type (parent/child)
Relativity allows for visual reference from parent to child via machine names with a suffix
ex; Organization Hero (field on the organization content type)
field name - Organization Hero
machine name - orga_hero_ref
cardnality is then configured on the Organization Hero field
ex; cardnality = 4
Result: When editing the Organization node I will be able to add 4 hero images.
b: Further Understanding Concepts:
1: The Hero Content Type is independent.
2: The example above is only for the Hero on the Organization
3: But to re-use the Hero on another content type we need to ensure we can independently manage
those cardnalities etc. We may want 6 hero images on another content type. If we configure cardnality
on the Hero content type, then all instances of the Hero could not be independently configured.
3: File Field Configurations
Design comps are well underway. So as back end devs, we need to use those to clear up specifics on
field configs such as...
On the Organization Hero, does the designer call for 4 hero max, or more?
On the Static Page, does the designer call for less than 4 heroes?
On Member Contributions, does the designer call for 6 nodes in a list display?
On the Hero, does the designer call for desktop image dimensions. Based on the call out we can do
the math to then determine max image dimensions and then image sizes and storage buckets.
I appreciate all of you diving in as you have. Your questions will all be answered as you learn to think as a data architect and not necessarily as a Drupal dev. Relativity is based on a site builder being equally competent in not only Drupal, but in related table design, user experience and articulating design concepts into the data display returns. I promise, stick with the concepts and you'll all come out of this build with huge personal capability enhancements.
Looks like most folks are looking for more direction, some explicit, some general. This is a good thing. But you can only do what you have documentation on. The rest falls under Relativity knowledge, documentation, task delegation and design comps.
I'll do my best to address the ticket feedback so far:
1: Machine Names a: Each independent content type has an explicit machine name ex; News Content type - machine name = news ex; Session Content type - machine name = sess all fields contained on the News Content Type begin with news_ ex; Body - machine name = newsbody all fields contained on the Session Content Type begin with sess ex; Body - machine name = sess_body
b: The machine name is used for indexing and visual reference when naming fields, always remember to follow the machine name call out, but keep your field read- able by others. If it's an image, be sure that everyone can see it's an image ex; Hero - machine name - hero Hero Image - hero_image
2: Entity References a: All Entity References begin in a content type and then reference a content type (parent/child) Relativity allows for visual reference from parent to child via machine names with a suffix ex; Organization Hero (field on the organization content type) field name - Organization Hero machine name - orga_hero_ref cardnality is then configured on the Organization Hero field ex; cardnality = 4 Result: When editing the Organization node I will be able to add 4 hero images. b: Further Understanding Concepts: 1: The Hero Content Type is independent. 2: The example above is only for the Hero on the Organization 3: But to re-use the Hero on another content type we need to ensure we can independently manage those cardnalities etc. We may want 6 hero images on another content type. If we configure cardnality on the Hero content type, then all instances of the Hero could not be independently configured.
3: File Field Configurations Design comps are well underway. So as back end devs, we need to use those to clear up specifics on field configs such as... On the Organization Hero, does the designer call for 4 hero max, or more? On the Static Page, does the designer call for less than 4 heroes? On Member Contributions, does the designer call for 6 nodes in a list display? On the Hero, does the designer call for desktop image dimensions. Based on the call out we can do the math to then determine max image dimensions and then image sizes and storage buckets.
I appreciate all of you diving in as you have. Your questions will all be answered as you learn to think as a data architect and not necessarily as a Drupal dev. Relativity is based on a site builder being equally competent in not only Drupal, but in related table design, user experience and articulating design concepts into the data display returns. I promise, stick with the concepts and you'll all come out of this build with huge personal capability enhancements.
J