accessing item replicants

<container name='Highlights' combination='and' location='Highlights'>
    <item name="hightlights" rowcontinue="f" pathid="highlights" min="1" max="10">
  <textarea rows="10" col="20" required="f"  />
 </item>
</container>
... 
IWDatacapture.getItem('homepage/Highlights/highlights')).

Looks like a typo in your DCT - or perhaps just in your post?

jbonifaci

IWDatacapture.getItem('homepage/Highlights/highlights')).

In addition to what Adam said, you also are referencing the container instance in the wrong spot. This should be:

IWDatacapture.getItem('homepage/Highlights/highlights')).

~Jeff

Nidhi_Agrawal

one more change is required...
IWDatacapture.getItem('/homepage/Highlights/highlights');

[/font]

In addition to what Adam said, you also are referencing the container instance in the wrong spot. This should be:
IWDatacapture.getItem('homepage/Highlights/highlights')).

~Jeff

I could have sworn I had posted this last night, but ....

Are you sure about this?
The reason I ask is, although I've not had to deal with this myself yet, the issue here is a replicated item within a non-replicant container - so it would seem more likely that the index would be at the end.

Migrateduser

I managed to solve the problem, and as ghoti pointed out in his first reply, the typo is what caused all this mess. Thanks for pointing that out. I did not even think it would be a syntax error essentially since I was getting the exact same error the day before, and the problem was addressing the correct container and nothing close to a syntax error.
As far as addressing a replicant item in a non replicant container, I managed to do so, and the index has to be for the item, not the container.
To my understanding, the following three situations can occur:
1. Addressing an item within a replicant container - for which the format is 'root-container/container/item
2. Addressing a replicant item withing a non replicant container - for which the format is 'root-container/container/item'
3. Addressing a replicant item in a replicant container - for which the format is 'root-container/container/item'

To my experience those three formats are the correct ones for each of the situation they describe. Did anyone experience anything else?

jbonifaci

I could have sworn I had posted this last night, but ....

Are you sure about this?
The reason I ask is, although I've not had to deal with this myself yet, the issue here is a replicated item within a non-replicant container - so it would seem more likely that the index would be at the end.

Actually, I just looked back and I thought his container had a min/max on it and the item inside the container wasn't a replicant. My bad, looked at it too quickly. Smiley Wink

~Jeff

This container is contained within the root container named "homepage". So to access a replicant of the item I would do

Do we need to use root-container always to access a element in the formAPI. Can we avoid somehow to use the root element and just give the path of the element inside the container ?

TS6.5 + sp2 + unix

Do we need to use root-container always to access a element in the formAPI. Can we avoid somehow to use the root element and just give the path of the element inside the container ?

TS6.5 + sp2 + unix

The root container is what the name implies - a "root" container - a base-level from which all other elements are accessed.

You *must* have a root container.

I understand this Ghoti, but if we need to have root container everytime then we are not able to make generic formAPIs across DCTs.

Let me pour some more details here

We have generic fileInfo container in all our dcts. As part of this container we have fileName and fileGeneration location field and using a workflow we generate the page at the appropriate location.

We are populatin the fileGeneration location using formAPI but because of root container we need to write different formAPI for every dct although differnt fuctions does the same thing.

Thats why I was looking if we can access the fields without using the root container
I am not sure if I am doing something wrong Smiley Sad

I understand this Ghoti, but if we need to have root container everytime then we are not able to make generic formAPIs across DCTs.

Let me pour some more details here

We have generic fileInfo container in all our dcts. As part of this container we have fileName and fileGeneration location field and using a workflow we generate the page at the appropriate location.

We are populatin the fileGeneration location using formAPI but because of root container we need to write different formAPI for every dct although differnt fuctions does the same thing.

Thats why I was looking if we can access the fields without using the root container
I am not sure if I am doing something wrong

Have you thought of naming all your root containers the same?

hehe craky ... I am hacking it like this only at the moment but i dont find this a very good solution when I need to give my article root-container for my home page ... code looks weirdo

cheers!
-rocky

hehe craky ... I am hacking it like this only at the moment but i dont find this a very good solution when I need to give my article root-container for my home page ... code looks weirdo

cheers!
-rocky

Did you think about naming the root container something generic - like "root"?

Hi, in my experience we always used rulesets to distinguish amongst homepages, editorials, etc., and a common content structure for the most cases, composed of a <metadata> section and a section. This simple macro-structure, common for all contents, it's a great help for common formApi and perl scripts which refers to it. Unfortunately, we still use the datacapture5.0.dtd with TS6.5 instead of datacapture6.0.dtd, for backward content compatibility reasons. So we don't have to bother with the root-container problem. A first workaround that may work for you is to use this DCT then; of course, this may arouse problems if you use features introduced with the 6.0 DTD, such as replicant containers. In our case, we don't have any problem beacause we still use the old item.

So i tried to create a new DCT using the datacapture6.0.dtd, and *surprisingly* it lets me create a content -without- a root-container. I cannot figure it out, because in the DTD it's clear that you *must* specify a root-container:

ELEMENT ruleset (label?, description?, script*, root-container)

Somebody can tell me why this happens, or why TS doesn't do this check? As I say before, I've not used the 6.0 DTD extensivily, so I dont'have a clue.

Finally, I'll give you another possible solution to the problem (IN THE CASE IN WHICH THE ROOT-CONTAINER IS REQUIRED, BUT IT'S NOT UNIQUE FOR ALL DCTs):

Suppose you have N contents, with different root-container names, but each with a identical replicant item (I called it "areplicant").
The IWDatacapture.getRootItems() method may have to work:

var allItems = IWDatacapture.getRootItems();
var rootName = allItems[0].getName();
var myReplicant = IWDatacapture.getItem(rootName+"/areplicant");

In this simple formAPI example, I call the getRootItems() function to store all DCT items in the allItems array, then I call the IWItem.getName() method on the first object (the root item) in the array, in order to use it later to access the replicant item instance. The "rootName" will be in the form "/rootname", so that's no need to add any slash before it. Hope this works for you, too :-)

In the first lines, i've meant a metadata and content sections (I'm sorry but I'm not able to edit posts and not practical of the forum :-)).

Thanks buddy, this seems to be a very clean solution for this problem.. let me try this!!

Cheers!
-Rocky

That's nothing! Let me know if it works...

Anyway, if someone can tell me why is possibile to create a datacapture,

using datacapture6.0.dtd for validation, without a root-container, when the

DTD itself doesn't

allow that... it's a strange behavior, I remember I tried to

create some DCT in the past and I got an error when i tried the same thing...

Thanks.

That's nothing! Let me know if it works...

Anyway, if someone can tell me why is possibile to create a datacapture,

using datacapture6.0.dtd for validation, without a root-container, when the

DTD itself doesn't
allow that... it's a strange behavior, I remember I tried to

create some DCT in the past and I got an error when i tried the same thing...

Thanks.

Just to make sure I understand correctly - you had a DCT specified as using the datacapture6.0 DTD and you specified that the DCT was of type "xml" in the templating.cfg file - and it worked without a root-container defined?

This works perfectly and now we can have generic formAPI functions for all the DCTs in our system Smiley Happy

I dont know the answer for your question but thts true I have created this with TS6.1 6.0 dtd without rootcontainer and it worked fine for me as well.

Just to make sure I understand correctly - you had a DCT specified as using the datacapture6.0 DTD and you specified that the DCT was of type "xml" in the templating.cfg file - and it worked without a root-container defined?

Not exactly, but I've got the point. Thanks to your reply, I've understood the key is in the templating.cfg. In fact, i don't have to bother with the "dcr-type" attribute until... now. All our DCTs are configured to be of "iwov" type. I suppose that, in this case, they're not treated strictly, as XML files, so there's no need to be a root-container; in opposition to the other case ("xml"), where a root node is obviously needed. If this is right (I'haven't read manuals on this topic), I thank you for the tip.

Anyway, I tried to make a new DCT using the datacapture5.0 DTD, declared as "xml" type in templating.cfg, and still TS complains that "There must be one and only one root-container element.". Is it right? If so, the need to have a root-container or not depends only by the data-type entries in templating.cfg, and not by the specific DTD...

Not exactly, but I've got the point. Thanks to your reply, I've understood the key is in the templating.cfg. In fact, i don't have to bother with the "dcr-type" attribute until... now. All our DCTs are configured to be of "iwov" type. I suppose that, in this case, they're not treated strictly, as XML files, so there's no need to be a root-container; in opposition to the other case ("xml"), where a root node is obviously needed. If this is right (I'haven't read manuals on this topic), I thank you for the tip.

Anyway, I tried to make a new DCT using the datacapture5.0 DTD, declared as "xml" type in templating.cfg, and still TS complains that "There must be one and only one root-container element.". Is it right? If so, the need to have a root-container or not depends only by the data-type entries in templating.cfg, and not by the specific DTD...

I think you're mixing apples and oranges (or at least a couple of different varieties of apples ;-) - and TS is doing some work "on your behalf" that is causing the behavior you're seeing.

To the best of my knowledge - if you declare a DCT of type "iwov" then FormsPublisher will process the DCT as-if it was using the datacapture5.0.dtd - even to the extent of translating (or perhaps ignoring) attributes like 'location' and 'pathid' - and thus - there is no root-container expected.

If you declare a DCT of type "xml" then FormsPublish is (again, this is a guess) processing the DCT as-if it was using the datacapture6.0.dtd - and will insist that there be a root-container, and that all containers have a location attribute, and that all items have a pathid attribute.

So - I think you're right when you say that the key is in the templating.cfg file.

Ohh thanks, now it's all clear!

So my suspects that the DCD specified, in this case, is ignored, is right...

Anyway, I don't think the mapping "iwov->5.0" ; "xml->6.0" is a great thing.
How this will become when there'll be a datacatpure7.0.DTD? There'll find
another name to set in the dcr-type? Yep!

Thanks for all.

-------------
Ivan Gelpi
TS 6.5 / OpenDeploy 6.0.2