Add a container replicant to the current instance using formapi

I need to generate an xml file where we have recursive node structure where I'm trying to limit the depth to '6'. This xml file is used for site navigation

Sample XML :

[html]

[/html]

Here is my datacapture.cfg

[html]
<script>
function init()
{
IWEventRegistry.addItemHandler("/sitemap-xml/site/node", "onReplicantAdded", addContainer);
}

function addContainer(cntr_instance)
{
var cntr = cntr_instance.getName();
alert('adding the container');
}
init();
</script>

Site

Name
Enter the site name.

Level One

Name
Enter the Node Name

Link
Link

[/html]

So in the addContainer() I need to add another container replicant to the current container instance dynamically.

Something like this :

[html]

Level One

Name
Enter the Node Name

Link
Link

Level One

Name
Enter the Node Name

Link
Link

[/html]

How do I handle this?

I looked at IWItem.addInstance but I'm not sure how to do that.

Besides, since its recursive, how do I call the addItemHandler on all the child nodes as well?

Any help would be appreciated.

Thanks !

Find more posts tagged with

Comments

nipper

I need to generate an xml file where we have recursive node structure where I'm trying to limit the depth to '6'. This xml file is used for site navigation

Sample XML :
[html]

[/html]
Here is my datacapture.cfg

[html]
<script>
function init()
{
IWEventRegistry.addItemHandler("/sitemap-xml/site/node", "onReplicantAdded", addContainer);
}

function addContainer(cntr_instance)
{
var cntr = cntr_instance.getName();
alert('adding the container');
}
init();
</script>

Site

Name
Enter the site name.

Level One

Name
Enter the Node Name

Link
Link

[/html]

So in the addContainer() I need to add another container replicant to the current container instance dynamically.

Something like this :

[html]

Level One

Name
Enter the Node Name

Link
Link

Level One

Name
Enter the Node Name

Link
Link

[/html]

How do I handle this?

I looked at IWItem.addInstance but I'm not sure how to do that.

Besides, since its recursive, how do I call the addItemHandler on all the child nodes as well?

Any help would be appreciated.

Thanks !

Fixing post, please use preview

Adam Stoller

I think you want to use onReplicantBeforeAdd - and then write the logic to count the number of children/grand-children/great-grand-children/etc - to determine whether it is okay to add a new instance (return true) or not (return false)

Frederik

To my understanding, you're trying to change your DCT with FormAPI, and that's impossible.

Suppose you have a replicant defined in a DCT, then you can use FormAPI to add instances of that replicant.

But what it seems you're trying to do, is to add a new item (a nested replicant) to the DCT, through FormAPI. Instead, you need to statically write out your DCT with 6 nested levels of node replicants. (or use something called itemref in the DCT to do nesting, but I've killed my brain trying to understand that)

BTW, your formAPI is setting event handlers before the form is ready. You should do that in an "onFormInit" handler, I believe.

ISCBorisB

Instead, you need to statically write out your DCT with 6 nested levels of node replicants. (or use something called itemref in the DCT to do nesting, but I've killed my brain trying to understand that)

This structure is impossible to map to *static* DCT. The reason is that each node (except perhaps root one) in this *6 deep*
Tree may have any number of siblings. Further, number of siblings on each level is unknown upfront and may differ from DCR to DCR.

Recursive definition (something called itemref Smiley Happy

is the only supported way to build this sort of DCT. Quick and dirty, the following
illustrates the approach using Raji's naming. Note that I've introduced extra level "Children" in this schema. This is unavoidable in DCT,
for obvious reasons recursive definition requires combination "or".

Note that the way this sample is written it'll work for XML DCR Type only.
[html]
Node

Name

Link

Children

[/html]

Frederik

This structure is impossible to map to *static* DCT. The reason is that each node (except perhaps root one) in this *6 deep*
Tree may have any number of siblings. Further, number of siblings on each level is unknown upfront and may differ from DCR to DCR.

I'm not seeing the problem... here is a quickly written 3 level deep tree DCT. Rinse & repeat for 6 levels deep.

[HTML]

Node Level 1

Name

Link

Node Level 2

Name

Link

Node Level 3

Name

Link

[/HTML]

produces following DCR (example)

[HTML] [/HTML]

ISCBorisB

I'm not seeing the problem...

You should. Sure, you can manually replicate nested processing in the form of nested code. You wouldn't want to code XML Parser in this
manner, would you? That's exactly what recursion has been invented for. I see at least two problems with static approach, not even
talking aesthetics.

1. This sort of trees normally has various depth on various branches. It is "Up to 6", not "6" exactly. It may be depth 1
on Branch 1, 3 on Branch 2, etc. Even in your simplified 3 level example the best you can achieve for root->Nodes A/B
is shown below, for full blown static 6 you'll have even more garbage branches.

2. Scalability. *Rinse and repeat* to 6 and then compare DCT Code size. Now imagine that few month from now your Business
requires 12 levels instead of 6. Rinse and repeat again and compare the size again. And the next request may well be unbounded
depth.
[html] [/html]

Frederik

Boris,

You said first that it was "impossible". That's why I showed that it is possible. Now you're saying "but you shouldn't for such and such reason". That's a different thing. I just wanted to show the original poster his options.

Btw, it's not because you write the nested containers explicitly in the DCT (that's what I meant with "statically write out your DCT"), that the DCR's xml will contain all the nested items in every branch of the tree. That is, if you need only 3 levels deep somewhere, instead of the maximum 6, then just remove all the replicant instances of the 4th level (container has min="0"), and the underlying DCR's xml will be "clean". This is illustrated in my earlier example, where {node title="name1"} was 3 levels deep, and {node title="aa"} was only 2 levels deep. So your first argument is void.

I can agree on your second argument... But logically speaking, every tree should have a reasonably limited depth... otherwise it's too hard to edit as DCR, or present on a webpage. And what's the problem with a lengthy DCT anyway?

Finally, I believe the explicitly nested containers in DCT produce a DCR form that is easier to edit than the OR container with itemref. But that could be personal preference.

cheers

ISCBorisB

Sorry Frederik. I'm afraid I've lost the thread of your argument.

I think that recursive DCT definition should be used in this case. It *seems* that you either do not think so or consider it a matter of personal preferencies.
Is that it? If so, I'm not going to argue, to each his own.

raji

Thank you all for the comments.

I don't want to use a static DCT b'coz :

1) Firstly, the DCT is going to be really nested and too messy.
2) We don't know the level of nesting ( I just gave limit 6 as an example )
3) If I want to add a new node level down the line I have to edit the DCT and the TPL accordingly.

So I'm looking for some dynamic solution.

Thanks !

Adam Stoller

Thank you all for the comments.

I don't want to use a static DCT b'coz :

1) Firstly, the DCT is going to be really nested and too messy.
2) We don't know the level of nesting ( I just gave limit 6 as an example )
3) If I want to add a new node level down the line I have to edit the DCT and the TPL accordingly.

So I'm looking for some dynamic solution.

Thanks !

DCTs, though they may contain some dynamic aspects, are static in nature - why? Because if you populate a DCT today to produce a DCR - you generally want to make sure that you can edit the same DCR tomorrow without losing data - which you would do if you dynamically added or removed fields based on something which changes irrespective of the content already stored within the DCRs.

Perhaps you need to re-examine this recursive requirement to determine if it really is recursive and/or if it really is arbitrary in terms of the level(s) of recursion -- you might be trying to put a screw in with a sledge-hammer.