Change XMS Profile from Modify News Page

[Dale Ray]

This thread includes discussion of creating items in Coranto that have a parent/child relationship.

In my ignorance I described a method I thought would work for faking this in Coranto. The problem is that method requires that you be able to easily change the XMS submit page for an item.

If you create an XMS profile that includes ALL of the fields that you want in your parent object and then create an XMS profile for each 'child' subset you want you can create the item and then change between the XMS pages by allowing the user to change the XMS profile associated with the item on the modify news page, saving the item and then selecting it again from the modify news page. This is cumbersome.

In addition Coranto will allow you to create many items with the same value in whichever field you use as the key - because the true key item for each item is the unique news id created by Coranto when you first submit the item.

My thinking to get around the first issue is to display a list of the available XMS profiles in a column on the modify news page. The user selects an XMS profile and when they click on edit the item is opened for editing in the XMS profile selected.

I used the Modify News: User Column addon as a base for an addon that will display the XMS profile that is currently associated with the item on the modify news page (see graphic below). The XMS Profile column needs to be a select box and the value selected needs to be passed to Coranto - right now it is just showing the current XMS profile for the item.



I am going to work on this some more but this looks like it will test my coding abilities.

I have posted this because I said in the other topic I would look into this some more. I don't know when I will get enough time to attack this some more.

[faithless]

An addon to handle Child and Parent relationships could probably insert a new hidden field into newsdat.txt. In this hidden field will store the newsid of the parent. If say the field is left blank, then it would be considered as a root entry (ie, top level parent).

Using the above concept, I can have a child, that is linked to parent via the parents newsid, which can be further linked to another top level parent, and so on. An addon can then possibly be coded to parse these parent child relationships and present them in a tree or something similar, which the user can then include in.

Parent
--Child
----Sub Child
--Child
--Child
--Child
----Current
----Sub Child
------Sub Sub Child
------Sub Sub Child

A potential problem would probably be circular linking, where id1 is linked to id2 and id2to id3 and then id3 is linked back to id1 again.

As for field data, you can probably have something on the modify/submit news page, that on checked, will replace all instances of that field for all child id's, or have it so that checked, will inherit the values from the parent id.

Speed wise, the data replacement is only done on saving news, so it should not have an impact on building news.

[Darren]

Three cheers -- an addon like this would be excellent.

[Replying to subscribe to thread updates ...]

[Darren]

Dale,

I've gone back and looked at this idea in light of my current Coranto install that uses XMS. When I Modify an existing content item, it defaults to using the XMS page with which the item was originally created, meaning there's no need to change it, submit, and reedit.

Is there an inherent problem with your parent/child workaround that I'm not seeing? I think I'm ready to try and implement it.

Thanks!
Darren