Thanks for reaching out to us on PI Square!
I'm a little confused to your about your question. You want to know if a list of elements can be declared as an attribute on an element? The structure of AF doesn't allow for that particular configuration. That being said, I think what you may be looking for is the concept child elements. You would be able to list courses elements as child elements (hierarchically one step lower) from your student element. Then each of those courses could have their own properties as you mentioned. So for my example structure below, I don't have each of the Boilers, Filters, Heaters, etc. as attributes on the Cracking Process, but rather child elements (or really grandchild elements). This still gives the sense of ownership that I believe you're after.
I apologize if I misunderstand, perhaps your use case or what you're trying to accomplish as the end goal here would be helpful in determining a good path for you.
2 of 2 people found this helpful
Interesting question, Jean-Francois.
I tend to think in terms of OOP class design or SQL database design, and that thinking can be extended to AF in terms of element templates and elements.
This means there should be an element template named Student that has information specific to a student that contains properties fairly fixed: name, birthdate (from which you calculate age), gender, student ID, etc. Your AFDatabase could then have an element named Students, which is composed of child elements derived from the Student template. Let's suppose we have this Students element on the database root.
You could also have an element template named Course, which has specific course information: title, teacher, number of hours, course ID, etc. You could then have an element named Courses, which is composed of child elements derived from Course. Again, we suppose the Courses would be on the root.
( To be even pickier, you could break it down further into Course (only title, number of hours, course ID) and also CourseSchedule (course ID, teacher, days, start time, building and room, schedule ID). This also implies there should be a Teacher template and possibly a Building template, depending on how large of a system you want to model. )
Finally, you need to associate a given Student with a given Course, and there a couple of ways going about this. I would think the master record should be under a Course, so I would create a child element named Students under each Course element. Under the child element Students should be element references back to the individual Student elements found under the root element Students.
Likewise, under each Student under the root level Students, you could have a Courses child element that has element references back to root level Courses for a given course a student may be following.
If I were designing this, I would try to have all this data driven from AFTables, which would be deemed the gospel source of record. I would write a routine to read the tables and populate the entire AFDatabase accordingly.
All of this is just theoretical about design. Can you have such a model with an AFDatabase structure? Yes. More importantly, is it the best place for such an application? If I were to put this into tables, I would rather just approach this as a straight-up SQL-based application. What I see from this is just relationships between Students and Courses. I don't see any traditional process data, which changes over time.
Thank you very much Robert, I succeded with two templates with one is a child of the other.
I didn't know that we can instanciate several templates under an element. So now, I can create several Courses under a student.
Thank you again !