Jump to content

shadowkyogre

Members
  • Content Count

    2
  • Joined

  • Last visited

Community Reputation

0 Neutral

About shadowkyogre

  • Rank
    Newbie
  1. Hi Gorny! I wrote some of my data hierarchy in the format shown in the link as part of a brainstorming exercise. After doing so, I could see why I'd need to arrange it in a ragged hierarchy. I do have cases where some characters play a big role in the world without that role being tied to participation in an organization. From a ProcessWire standpoint, I could see the information from the article and your post translating into the following:: Using the normal parent/child relationship in ProcessWire for pretty urls only (which'd make doing a site map really easy). Current site has granularity levels of the following. World > (Location | Era | Cosmology) > Organization > Role > Species > Character . Each of these is probably going to be a template, though that's a lot of copypasting same fields from basic-page. But it'd also make querying specific data types easier. I'm still not entirely sure what to do with the basic-page template here since I still use that for many basic pages that just have information, but no need for granular relationship participation. Example use cases I could think of with my own data include... Some organizations have Organization > Role > Species and some have Organization > Role > _ > Character Characters can be biologically classified by their Species > Character relationship. I'm not sure how wise it is to use a repeater with a single page reference and a text field to store additional variation information. Sometimes I just want to make bird characters without a wiki entry for each type of bird instead of grouping it into a broader biological category. Like having some ravens and peacocks, but filing raven and peacock characters under a generic talking animals page. Some characters are notable across the world for a reason. So they may have a World > _ > _ > Role > _ > Character. There are some Locations that aren't bound to a world. So they might not have a parent. It might be useful in some cases to flip Role and Organization around. Like if a Location has a different relationship with an Organization, it might be useful to have a Location > Role > Organization role that reads "Enemy" and another that reads "Ally" for those role nodes. Modeling multiple parents for each leaf by the following... A Page Reference field for the worldbuilding data type that's just "parents", where all worldbuilding page template types are valid parents. Sloppy visually, but, it works? A Page Reference field for each type of worldbuilding page template that can be a valid ragged hierarchy parent for a page. Might be a lot of field overhead though, but that's probably better for form readability. After modeling the multiple parentage, if I understand how to model this in PW with the given available tools, a few other things I could do with this are... A character page can query what bloodline they have by checking the Species > Character, as mentioned before. A character can list specific roles they have for organizations by checking for Organization > Role > Character. A character can list organizations they participate in, but don't have a chain of command role by checking their direct Organization parent. Character specific roles could simply have no parent or World parents according to the page reference fields, but in the page tree could be stored directly under the character. Organizations can list all members that don't have a role by checking for no Organization > Role > Character relationships, but there being an Organization > _ > Character relationship. Chain of commands in organizations can be handled with nested Role relationships with the rootmost Roles being direct children of the Organization. If there's anything I missed from my understanding that I'd need to consider, please let me know.
  2. [EDIT]: After sitting down and planning out my site according to the ragged hierarchy information, I settled on the following schematics. /$world/$template/$content_of_template_type/... for my pretty URLs /roster/$character for my characters a generic Repeater field with depth on most content types for custom positions for child pages to connect to instead of it directly a few Repeater fields on each content that have (PageReference[1], other fields) to establish associations A few FieldsetGroups to help me manage the fields that I needed to copy across a bunch of content types. Kept the original post below for context and tagged the OP for searchability. --- Hi everyone! I'm working on a personalized worldbuilding wiki to host my art and story stuff. Right now my site architecture looks like... /$world/cosmology/$cosmology /$world/locations/$location /$world/factions/$faction /$world/history/$history /$world/species/$species /roster/$character So far the layout works, but there's one problem. I need to make sub-sections for an organization. Organizations can appear under cosmology, locations, and factions. Sounds straightforward until... I run into the problem of figuring out how to represent subfactions. Key factors in this are... Characters should be able to be part of multiple organizations Characters should have an explicit role assigned to their membership. Character pages should be able to query the organization pages to display their ranks across organizations. Editing an organization's hierarchical layout should be visible while editing the root organization page. From what I've read of the ProcessWire documentation, the best use case for each way of representing the organization's subsections are... Child Pages:: Works best for menu presentation and dedicated editing. PageTables:: Works if you want control over where to place the PageTable fields, but requires opening a modal for the pages you want to edit. It's also kind of like normal pages. Repeaters:: Works great for inline editing and easy control over hierarchy, but the page urls become obscure. Sections in the body field:: Works for copypasting from my note files. But it doesn't expose relationships for easy querying. It looks like my best case for this is child pages since it allows displaying suborganization in the URL easily. But also I lose out on quickly reordering and editing the child pages. Any advice for people running into similar use cases?
×
×
  • Create New...