Convert page_top to page (and use relationships instead of metadata)

[ewinslow]

Is there a reason we use two subtypes here? It seems highly redundant. You could just as easily determine which pages are "top-level" by checking if parent_guid is set to the group/user/site in question. This seems more correct, too, since "top-level" isn't really an immutable quality. What if I want to be able to move a top-level page to the second level? That is not possible easily with the dual-subtype approach.

The second suggestion is about using relationships to impose structure, rather than metadata. It's just a good idea -- it's what relationships are for!

[cash]

I agree. Maybe there should be metadata on top level pages to mark them as such ($page->top_level = true) to allow for easy querying.

I suggest use the same techniques that we plan to use for threaded comments to store the structure.

[ewinslow]

I'd say just do $page->parent_guid = $group->guid. Except we would use relationships instead of metadata. That way if you want to move the page underneath another page, you just change the parent_guid (or parent relationship) to the new value and don't have to clear the "top_level" metadata.

[cash]

Is it valid to want to grab all top level pages across containers? If so, we need a way to retrieve them.

If in a group, we can just grab all pages with group as the parent to get its top level pages.

If trying to do this across groups/individuals, we would need metadata for this. Now it may be that we don't have a use case for pulling top level pages. Either way, we want to avoid storing guids as metadata so I definitely prefer relationships.

Also, isn't it early for you to be awake?

[ewinslow]

Replying to cash:

Is it valid to want to grab all top level pages across containers? If so, we need a way to retrieve them.

Good point. Basically we'd want to search for all entities where the parent = container_guid, but there's no way to express this with the current api. Solution would then have to include metadata or make the API more expressive (or hardcode this particular case -- bleh!).

Also, isn't it early for you to be awake?

:), but not too late it seems...