Thanks Michaël,

yeah, I've got that in place already...

The reason that I want to be able to administer the data (via the CMS) from both ends is ease-of-use for the client.

For example, say if the nodes in question are staff and office (i.e. a member of staff resides within a single office). When setting up a new office it would be great to pick staff from a multinodetreepicker, right? But, in the case where an existing staff member moves office; you really want to go to the staff member CMS page and change their office from a single picker?

Am I making sense here?

Thanks,

Splinx :-D

Hi Splinx,

its kind of confusing because first you talk about Regions and Countries and now Staffs and Offices!

That at a side node.

Maybe you can show your current content node structure with a screenshot? Then we can have a better view and understanding.

/Michaël

Hi Michaël,

I only attempted to provide a practical example because it was more pertinent to the second example - sorry.

 Home 
    |____ Region 
             |___ Country 

That's my document structure;

On Regions I have a multinodepicker of Countries where the CMS admin can select one or more countries within a region.

This is absolutely fine and on the front-end I have absolutely no problem getting a Region for a Country in code.

If the CMS admin visits a Country in in the back-end then they cannot see or change the Region for that Country since the relationship only exists on the Region node.

Are you with me?

Cheers,

Splinx

Yes I understand it completely, that's why I suggested the other solution in my first post. Then you don't have this problem and you don't need any single or multi content pickers.

The only thing you have to do is create a region node and allow country nodes to be added as children.

Below you can find a simular example in one of our projects:

So we have a country België and Nederland which have child cities.

Then on the België we use:

 var cities = Model.Content.Children;

to have a list of all cities in België.

Then on the for example Brugge content node, we use:

var country = Model.Content.Parent;

to have the country of the city.

Hope this helps.

/Michaël

Oh yea, I get ya :)

We've used that technique in the past and your suggestion makes complete sense buddy, thank you :)

I guess that I was only using that as an example and the second example of staff and offices may be more pertinent.

We could use the same node/child-node solution you have given here but we would lose in other areas; like the ability to use a single list-view to see all items across all parents. Not the end of the world, but I'm just trying to ascertain what's possible with this excellent CMS.

I'm gonna have a go with the relations thing like Ismail suggest.

Thanks again buddy :-D

Kind regards, David

Oh yea, I get ya :)

We've used that technique in the past and your suggestion makes complete sense buddy, thank you :)

I guess that I was only using that as an example and the second example of staff and offices may be more pertinent.

We could use the same node/child-node solution you have given here but we would lose in other areas; like the ability to use a single list-view to see all items across all parents. Not the end of the world, but I'm just trying to ascertain what's possible with this excellent CMS.

I'm gonna have a go with the relations thing like Ismail suggest.

Thanks again buddy :-D

Kind regards, David

Thank you Ismail,

I will look into this plugin and see if I can work it all out.

I'll report back either way.

You guys rock!

SplinX