Subnode Possibilities

[Midnight Modding]

I have used a subnode class for an app I already finished, but I am curious about other possibilities with them in the current app I am working on and have some questions.

I haven't noticed IPS do any of this, so I am not sure if someone will remember offhand if these situations are possible without issues or not...

1. can a node class still allow subcategories of the same class if it also has a subnode class? Or is it either/or? (wondering because then it would probably need 2 totally separate add buttons in the acp).

2. could content items still be added? Would they have to be added into the subnode class? or they could be added to the main node class as well?

3. what about permissions? Only for subnode class? either? If implementing them in both would it work the same as going down the chain from parent to child in a normal node class?

The only time I have used a subnode class before, I didn't need to use content items or permissions with it, so there weren't any odd situations in that one. 🙂 I don't "have" to do any of that in this one, either, but would be handy.

[bfarber]

The node/subnode methodology is intended for places like custom fields where you have "groups" and then "fields", and these are different things but conceptually related.

I don't think you're going to want to try to do what you are talking about using nodes+subdnodes. I'm not sure if it's possible (I don't think 1 and 3 are without having tried, and you're only going to be able to add the content to the child class regarding #2), but really you'll be making things more difficult for yourself.

If you need to have two different side-by-side node types, your better bet would be to copy what we do for Gallery, where you have Categories and Albums (hint: albums are both a node and a content item).

[Midnight Modding]

ok thanks. I figured as much, since you guys yourselves didn't need it for this type of situation.

The node/subnode setup worked perfectly the other time I used it, but this was going to be trickier. I've actually not been asked to do permissions per node or do anything that requires content items on this app, so I don't really have to do it. I just thought it would be nifty.

I've seen that gallery one before and thought about using the same one as both a node and item in the past, but I figured that could get complicated too. If I do decide to do any of this, I think that would be the way to go, though. 🙂 

[Midnight Modding]

There are so many ways to do my structure on this and I hate making decisions. 😞 I could do it like I have it and not even use permissions or content items, do it similar to Album, have content items with a dummy node as a parent and not use nodes at all (have done that before, too), allow subcategories, don't allow them, use only ONE node class and have a setting determine whether it behaves like type one or type two... Hard to decide on a structure because I am just guessing how potential customers will use it.

Hmm, the more I think about it, I don't think the Album is similar enough, either. The secondary node isn't something similar to a content item. It's something that could be looked at as either one, but not needing to be both.

Oh well. I'll figure something out.

[Midnight Modding]

@bfarbercan you think of issues if I do a setup like the gallery Album, where it's a node and content item, BUT when it acts as a node, it has other nodes below it, not a second content item type?

So what I am wanting is:

node type 1 -> content item 1/ node type 2 combo -> node type 3

I have so, so many ways I can structure things in this app and it's tough deciding which way to go, due to not knowing all future features I'd want, of course.

I could technically even do a content item type 2 below node type 3 honestly. lol. (I mean if it would work, I do have a setup that would be able to use a different content item type there.)

edit: honestly it may just not be worth the trouble to do a fancy setup like that... I may do a straight 1 noew, 1 content item setup then everything "below" the item just not be either r anode or item... which is basically what iuj did on the tournaments app a while back. Nobody really "owns" a content item in this app, anyway, so it's likely not worth the headache to do a combo node/item setup.

Or I may do it, and then a second content item, same as Album ahs a second one below it. That way I could implement commenting on 2 of these types.

[bfarber]

All I can say is KISS (keep it simple stupid).

As an end user, it would be fairly complicated to navigate node type 1 > node type 2 > node type 3 before you even reach content. Users don't want to do that. Being able to do something and it being logical or desired are two different things.

[Midnight Modding]

59 minutes ago, bfarber said:

All I can say is KISS (keep it simple stupid).

As an end user, it would be fairly complicated to navigate node type 1 > node type 2 > node type 3 before you even reach content. Users don't want to do that. Being able to do something and it being logical or desired are two different things.

It's not going to look that way to the end user. it's just how I was going to organize it, where some pieces fit together and get commenting integrated, etc…. I originally actually made it have NO content item, but then thought well down the line I may want commenting.

It's complicated to explain, but the bottom line is to the end user it would look much simpler. One listing, click one, click add content button. The extra nodes and content items aren't truly like typical nodes or content items.

it's sort of like how topics have polls and topics have this and that etc... attached to them that aren't really nodes or tiems.

That all being said, I do think I am overcomplicating to try to make the app work for many different site types and I am going to have to keep it simple.

[Midnight Modding]

I can't find the topic where I was asking about the problem of having a node type where there may be hundreds and not wanting to have hundreds on one page in the acp, so I was going to disable reordering.

Well, I am sure going to know that system mighty well as much as I have messed with it. lol. I have found multiple ways to have it where it orders alphabetically in there and still not allow reordering.

One way I set the databaseOrderColumn and then extended Tree and I did my own function _getRow() and returned the parent with $noSort set to TRUE, where it would still sort, but wouldn't put the handles for resorting.

Another way was take out databaseOrderColumn and then nodesWithPermission() put my own ordering in it.

Reordering with the friendly name... which I forgot to be updating. lol.

edit: oops forgot this was in developer gateway or wouldn't have posted, ie bumping it. Anyway I decided to do the former, even though it meant adding my own tree file, since it would be a bit more straightforward changing databaseColumnOrder instead of remembering to go to my function nodesWithPermission() if I ever need to change the column. Other way would have meant one less file, though.