Jump to content
shadowkyogre

Not sure how to represent suborganizations for my use case

Recommended Posts

[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?

Share this post


Link to post
Share on other sites

I would consider how other systems work out the mapping of ragged hierarchies - where you store a hierarchy level in addition to the ancestors and children relationships. Having a two dimensional structures like this enables you to manage granularity level control as well as lineage control. It becomes trivial to isolate branch grouping based on a limit of the lineage and level - say less than three. Alternatively, you can also build queries that select peers across a given landscape. For example, if local heroes of a klan that is a subfaction of a race on a given world, you can list them alongside heroes that are also part of major clans without internal divisions, or even immortal heroes without lineage or clan that live on a mountaintop on a continent. Each 'level' number represents a granularity level, not necessarily a power, quality or quantity level.

The nice thing about this method is that it allows you to 'skip' levels while still retaining lineage integrity if you so choose.

Here's an example of building such a data structure for an unrelated BI tool, but I think you will understand the design pattern. Perhaps this is what you are looking for:

https://www.dundas.com/support/learning/documentation/analyze-data/create-a-ragged-hierarchy

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

The only thing I might suggest is that the Location Role and Organization Role seems like two different classifications - The tricky part that I see in general is that some of the items you talk about would be at the hierarchical level - say, at the vertical level of granularity - while other items are on at a description attribute levels - the horizontal level of classification.

Ultimately you will need to make some decisions with regard to what is considered an attribute and what is considered a degree of precision or size. I think the part that might mess with your head a bit is that there are likely going to be very common attributes of a variety of hierarchies. The advantage I can see from a PW perspective is that you could generate queries that pull selector values regardless of where they are in the hierarchy - but in terms of navigation structure I am not really sure how you would want to go about it without using URLSegments or something.

I have not tried to model out something that complicated in terms of URL structure - hopefully someone with more experience in tweaking segments can offer input...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By dfile
      Hello,
      I am running ProcessWire 3.0.165 but $input->urlSegmentLast or $input->urlSegment(-1) does not work as expected.
      Or do I something wrong?
      Thank you.

    • By bramwolf
      Hi Guys,

      I found here: https://processwire.com/docs/selectors/#finding2 that I can exclude results from my $pages->find($selctor); query by using parent!=123 ( parent ID ) But I was wondering if I can
      also do so based on the parent template? I've tried doing it by itterating over the matches array and dropping the matches with the parent but since the result is limited for use with the paginator
      it only drops the items from the batch displayed on this page. Say from the results within matches 0 - 20 and not the entire 0 - 220.

      Anybody have a idea of how to achieve this? 🙂

      Thanks in advace!
      Bram 
    • By LAPS
      I've pages using the custom-page-template and I would like to display a simple message at the top of the page form when editing those pages in the Admin.
      I thought about hooking ProcessPageEdit::buildForm() but I do not well how to use that hook in order to display the message just for the custom-page-template pages.
      Any help?
       
       
      UPDATE: Solution found
      wire()->addHookAfter('ProcessPageEdit::buildForm', function(HookEvent $event) { $ProcessPageEdit = $event->object; $form = $event->arguments('form'); switch ($ProcessPageEdit->getPage()->template->name) { case 'custom-page-template': $form->prependMarkup("<div style='margin-bottom: 3.6em; margin-top: 1em; background: #ffd;'>MY MESSAGE</div>"); break; default: // do nothing } }); Any improvement is welcome!
    • By VeiJari
      Hello,
      I'm trying to create a page via api and populate values to it. I can populate everything except user pages to a page reference array.
      Code: 
      $dataUsers = $data->project->users; foreach($dataUsers as $dataUser) { $newProject->projectUsers->add(wire()->pages->find('template=user, id=' . $dataUser->id)); } I'm receiving my data via JSON.
      Is there something I'm missing?
      Thanks for help
    • By David Karich
      ProcessWire InputfieldRepeaterMatrixDuplicate
      Thanks to the great ProModule "RepeaterMatrix" I have the possibility to create complex repeater items. With it I have created a quite powerful page builder. Many different content modules, with many more possible design options. The RepeaterMatrix module supports the cloning of items, but only within the same page. Now I often have the case that very design-intensive pages and items are created. If you want to use a content module on a different page (e.g. in the same design), you have to rebuild each item manually every time.
      This module extends the commercial ProModule "RepeaterMatrix" by the function to duplicate repeater items from one page to another page. The condition is that the target field is the same matrix field from which the item is duplicated. This module is currently understood as proof of concept. There are a few limitations that need to be considered. The intention of the module is that this functionality is integrated into the core of RepeaterMatrix and does not require an extra module.
      Check out the screencast
      What the module can do
      Duplicate multible repeater items from one page to another No matter how complex the item is Full support for file and image fields Multilingual support Support of Min and Max settings Live synchronization of clipboard between multiple browser tabs. Copy an item and simply switch the browser tab to the target page and you will immediately see the past button Support of multiple RepeaterMatrix fields on one page Configurable which roles and fields are excluded Configurable dialogs for copy and paste Duplicated items are automatically pasted to the end of the target field and set to hidden status so that changes are not directly published Automatic clipboard update when other items are picked Automatically removes old clipboard data if it is not pasted within 6 hours Delete clipboard itself by clicking the selected item again Benefit: unbelievably fast workflow and content replication What the module can't do
      Before an item can be duplicated in its current version, the source page must be saved. This means that if you make changes to an item and copy this, the old saved state will be duplicated Dynamic loading is currently not possible. Means no AJAX. When pasting, the target page is saved completely No support for nested repeater items. Currently only first level items can be duplicated. Means a repeater field in a repeater field cannot be duplicated. Workaround: simply duplicate the parent item Dynamic reloading and adding of repeater items cannot be registered. Several interfaces and events from the core are missing. The initialization occurs only once after the page load event Attention, please note!
      Nested repeaters cannot be supported technically. Therefore a check is made to prevent this. However, a nested repeater can only be detected if the field name ends for example with "_repeater1234". For example, if your MatrixRepeater field is named like this: "content_repeater" or "content_repeater123", this field is identified as nested and the module does not load. In version 2.0.1 the identification has been changed so that a field ending with the name repeater is only detected as nested if at least a two-digit number sequence follows. But to avoid this problem completely, make sure that your repeater matrix field does NOT end with the name "repeater".
      Changelog
       
      2.0.1
      Bug fix: Thanks to @ngrmm I could discover a bug which causes that the module cannot be loaded if the MatrixRepeater field ends with the name "repeater". The code was adjusted and information about the problem was provided 2.0.0
      Feature: Copy multiple items at once! The fundament for copying multiple items was created by @Autofahrn - THX! Feature: Optionally you can disable the copy and/or paste dialog Bug fix: A fix suggestion when additional and normal repeater fields are present was contributed by @joshua - THX! 1.0.4
      Bug fix: Various bug fixes and improvements in live synchronization Bug fix: Items are no longer inserted when the normal save button is clicked. Only when the past button is explicitly clicked Feature: Support of multiple repeater fields in one page Feature: Support of repeater Min/Max settings Feature: Configurable roles and fields Enhancement: Improved clipboard management Enhancement: Documentation improvement Enhancement: Corrected few typos #1 1.0.3
      Feature: Live synchronization Enhancement: Load the module only in the backend Enhancement: Documentation improvement 1.0.2
      Bug fix: Various bug fixes and improvements in JS functions Enhancement: Documentation improvement Enhancement: Corrected few typos 1.0.1
      Bug fix: Various bug fixes and improvements in the duplication process 1.0.0
      Initial release Support this module
      If this module is useful for you, I am very thankful for your small donation: Donate 5,- Euro (via PayPal – or an amount of your choice. Thank you!)
      Download this module (Version 2.0.1)
      > Github: https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDuplicate
      > PW module directory: https://modules.processwire.com/modules/inputfield-repeater-matrix-duplicate/
      > Old stable version (1.0.4): https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDuplicate/releases/tag/1.0.4
×
×
  • Create New...