Non hierarchal structure

[joe_g]

(WARNING: long philosophical post, with no immediate problem solving needed. This is for the ones who might feel like discussing data modelling in PW)

 

 

 

Hello!

I'm about to start a new project and I ran into a structural problem that I'm not sure exactly how to get about (although I have an idea):

I have a project where all data will be tag-based: the same piece of data will show up in different places on the website. In other words it will 'exist' in more than one place. The PW CMS interface is based on a hierarchy, where everything needs to have one (single) main location.

I have no desire to expose myself to XSL again, so I'll be solving this project with PW instead of Symphony (getsymphony.com) – my previous CMS of choice. But I'll use it as a comparison:

If PW is based on a folder/hierarchy metaphor, Symphony is based on a relational database model metaphor. Symphony has sections (=tables) that can be 'joined'. They can be joined 'visually' (inline editing) with github.com/hananils/subsectionmanager/. It gives almost the same separation between presentation and data as any other old mysql website but mouse-click data modelling. Symphony gives less help on how my url's should be structured than PW. This project wouldn't actually be much easier to solve with Symphony, I would miss the friendly url/template hierarchy. But a match between PW and the subsection manager (allowing true many-to-many) would be so awesome that the gods of data modelling would step down from heaven for high-fives.

On a sidenote: To be honest I never quite understood why they (Symphony) decided to create a relational database on top if the relational database - instead of making the best CRUD known to man, but I'm sure they have their reasons.

Anyway, back to PW: I could solve this by letting each entry (page) have a main location. Let the path = tag. So that everything is forced to have a main 'tag' (path). Then a second field with secondary locations, pointing to other parents where the item 'reside'. The problem is that there will be two manoeuvres that essentially mean the same thing: Physically moving the page, and 'tagging'.

I could turn this into my advantage, though: Having a single main location is good for other reasons. There are formatting options that would only apply to the main location. So this approach is quite OK, and this is most likely what I'll do in the end. I'm just curious if anyone would have any thoughts on this.

J

[kongondo]

Maybe we can add these perspectives to the discussion?

How to create many-to-many relationship

Discussion/debate over correct or sensible use of repeater fields

Modelling data in PW (page relations)

Not sure they are all relevant to this topic though...

My 2 cents

/k

[joe_g]

Thanks. Topic is a bit floating perhaps

– Repeater field is strictly one-to-many, as far as I understand. You can't for example have add an author to a book, and then add that same author a second time on another book. (If author would be a repeater field)

– The other option is page field, which is essentially a pointer to another page. 

Two powerful options, but I did know about these (unless i missed something). So it doesn't change my plan (so far) to use page fields to point to alternate parents in the directory as a way for my content to exist in several places. It's a good enough solution, but it has two drawbacks:

– The editor has to be aware that everything has a primary location, and go there to edit the content

– Manual order (drag reorder) can only happen in one place.

J

[diogo]

I understand what you are talking about because I've used symphony myself, and I know how great subsection manager is. Actually, a talk where I mentioned it was the inspiration for Ryan to build the repeater fieldhttp://processwire.com/talk/topic/47-module-want-repeatable-elements/?p=4906

What you are asking here could be solved in the same way as repeaters. A page field that shows you that page fields directly on the hosting page (just like repeaters do). It relates somehow with this discussion also http://processwire.com/talk/topic/3092-field-naming-namespacing-and-how-we-can-prevent-excess-of-fields/.

[joe_g]

Maybe I'm totally misunderstanding the repeater, but I looked into it twice now to really make sure I understood how the repeater field works (sort of hoping I would be wrong). The repeater and subsection manager seems like apples and oranges to me (doing vastly different things).

SSM is many-to-many while repeater is one-to-many: An entry in a repeater field can only belong to one parent, if I understand it correctly.

For example, I cant use the repeater in the following scenario: I'm editing a page with the template 'book' in PW, and I'd like to add an author, so I make an author repeater to be able to add a bunch of authors. When editing the second book I can't find the *same* author from the first book and add it to the second book, right?

Am I getting this right?

J

Edited April 11, 2013 by joe_g

[apeisa]

Yes, you are getting it right.

I might try to see if Fredi wants to go backend too, so there could be modal edit links on page fields...

[kongondo]

Yes, you are getting it right.

I might try to see if Fredi wants to go backend too, so there could be modal edit links on page fields...

Apeisa,

Am confused...What has the great Fredi got to do with this discussion? Wrong thread perhaps?

[Macrura]

easy solution - put all the pages where you want;

use a custom menu no related to the page tree as explained here:

http://processwire.com/talk/topic/2787-custom-menu-not-related-to-page-tree/

then make a way to find content based on tags, using the template/api and selectors.

you could make your category pages be search result pages, like with this at the end /?tags=

and the actual pages themselves be like this at the end /?tag=

use a redirect template for the pages, so no one ever sees the 'real' url

[joe_g]

Thanks! Then I know my options.

I wouldn't want to use any other cms than PW, but this is the only thing I'm missing.

I attach a sketch of an example of the SSM interface, similar to something I did in a previous project. My hope is to evoke some curiosity and highlight the differences between SSM and repeater field. Its infinitely recursive using the same 'template' / ("section"): Person.

To the editor (that using the CMS), this interface looks simple, even if the data structure is quite complicated. In PW this would be hard to do, simply because each person would only be able to have one parent.

[apeisa]

Apeisa,

Am confused...What has the great Fredi got to do with this discussion? Wrong thread perhaps?

If I am not total out of the map, Page field + Fredi would be pretty much SSM that joe_g is talking about. Although instead of inline it would be modal.

[joe_g]

@Macrura, this is exactly what I'm doing, but with the two drawbacks described in my second post:

You can only order things manually in it's main location, everywhere else it would have to be sorted by some field (date for example).

And the editor has to be aware about the difference between the main location (the PW CMS tree) and the tagging system (similar to secondary parents)

I could also ignore the original location and rely solely on tagging - but then there is no easy way to order things.

[Macrura]

@joe_g - you could use url segments to get the URLs to look real and have the tags.

as far as the structure, looks like a page select to me, with possibly some custom validation, such as max 2 for the parents.

field 1: page select, selects from pages with tag 'parent' (custom selector)

field 2: page select, selects from pages with tag 'child'

allow creation of new pages on that page select...

not sure if this is what you're after though..

right, ordering is tricky... but you could make a custom field for that too.. might need a custom module to handle global ordering by tag.

[apeisa]

 You can only order things manually in it's main location, everywhere else it would have to be sorted by some field (date for example).

There are page fields, that allow dragging and sorting: try asmSelect.

[joe_g]

Actually, about order, PageListSelectMultiple is pretty close - I can reorder my items, maybe that's what you ment? It's the one I'm using. I wonder if it would be practical (and possible) to build my structure entirely with PageListSelectMultiple's...

The difference to SSM is the inline editing and possibility to search for items (only important if more than hundreds to select from). 

The inline editing makes me not having to be aware where the linked item resides in the tree.

J

[joe_g]

Yep.., PageListSelectMultiple makes ordering a non-issue If I would use that to build my structure.

What do you think about an edit link on the PageListSelectMultiple? Attaching sketch. Just to see what you think.

@apeisa: This is maybe what you ment with fredi in the backend?  Didn't get it before, sorry. Yes that would be very close to the SSM!

Edited April 11, 2013 by joe_g

[apeisa]

Yep, that is what I meant. Clicking "Edit" would open Fredi with editing and save.

[joe_g]

cool, gotcha..!

[Soma]

Something like this? https://github.com/somatonic/PageReferenceLink

I have started this module long ago but didn't come to finish it and just pushed to github. If someone likes to help out as I'm busy with other projects this could be taken and improved with settings and what not. Or Maybe it is of use for Fredi.

[apeisa]

Soma is the machine! (I am turning into a repeater here)

[joe_g]

Soma, that looks pretty sweet. 

I tried it but didn't get the little pen icon to show up on my list - any special prerequisites I should know about?

tx!

[diogo]

Ok, late to the party after my soon answer...

What I was talking about way up there is not more than a PageListSelectMultiple that shows allows you to edit the page in that same place. The relation that I did to repeaters, is because this is exactly what they do. They allow you to edit a page (that is hidden in the tree) from inside another page. So, technicaly, it shouldn't be very different to do.

[Soma]

On mobile so short. Yes you have to remove or edit the fields name restriction check in the hook function for the multi select. Line 59 in module. It's hard coded and also other hooks i was experimenting are commented out.

Back on laptop https://github.com/somatonic/PageReferenceLink/blob/master/PageReferenceLink.module#L59

... screw it I just updated it and commented out the check so all InputfieldPageListSelectMultiple fields will have an edit link.

This module is just experimental prototype but working and a start.

[joe_g]

soma, seems to work pretty goood

     

thanks!!

[diogo]

Soma is da man!

[joe_g]

amazing,

now I just need to rethink my structure