Unable to load form

Hi,
We installed TeamSite 721 into a new 64 bit server Windows environment.
When we are editing any form in the migrated content, the form is not able to open, it shows a Javascript error.
We have neither modified the dct nor the visual format file. The same works well in the old box which has TS 672.

What could be the reason?
Please help

Thanks,
Saurabh

Find more posts tagged with

Comments

nipper

Too many possible reasons to tell.

Maybe you are missing something (to me that is most likely)

You need to debug more before anyone can help.

What is the JavaScript error ? Is this in your own FormAPI (again most likely)

Can you view a DCR without any issues ?

What about create a new one ?

saurabh4984

Too many possible reasons to tell.

Maybe you are missing something (to me that is most likely)

You need to debug more before anyone can help.

What is the JavaScript error ? Is this in your own FormAPI (again most likely)

Can you view a DCR without any issues ?

What about create a new one ?

Hi,
Thanks for the reply,
Here's what I did, I removed the lookup to the visual format file and made it a simple textbox and I could load the form.
I cannot view a DCR, Edit it, Create a new form entry when I look up to the Visual Format File in the fields.
When I make the visual format field a normal textbox, it works just fine.
What is more puzzling is I havent modified any code which I had migrated from the old box.

Here's the error that I am getting


User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)
Timestamp: Fri, 20 May 2011 12:46:40 UTC


Message: 'eWebEditPro' is undefined
Line: 1227
Char: 5
Code: 0
URI: http://mum-its-dev:8080/iw-cc/command/iw.ccpro.create_form?vpath=//MUM-ITS-DEV/default/main/UAT/France/WORKAREA/Shared/templatedata/News/NewsArticles/data/USEnglish&cwd.vpath=//MUM-ITS-DEV/default/main/UAT/France/WORKAREA/Shared/templatedata/News/NewsArticles/data/USEnglish&done%5fpage=/iw-cc/base/util/refresh%5fdone%5ftarget%5fand%5fclose%5fwindow.jsp%3fdone%255ftarget%3dfs%255fget%255flist%255fframe%2528%2529&full%5fredirect=true

The javascript error is not my FormAPI.
It happens in IE and FF as well.
Please help

Amanpreet

Saurabh,
were you able to solve this , even we are facing this problem in Firefox, whereas it works fine in IE.
On click new form entry it just open a blank window.
TeamSite 7.2.1
Firefox 4.0.1

Regards,
Aman

Adam Stoller

Saurabh,
were you able to solve this , even we are facing this problem in Firefox, whereas it works fine in IE.
On click new form entry it just open a blank window.
TeamSite 7.2.1
Firefox 4.0.1

Regards,
Aman

This sounds like one or more of the following bugs that I filed towards the end of last year:

[indent]*** | Dec 07, 2010 @ 07:35:51 PST | ***

For a while now, I've noticed that a bunch of the DCTs at my current customer's site do not render at all in Firefox. [...]

So - following an error report from Firefox's Firebug - I traced the issue to at least one error and potentially many examples of poor-coding (the latter may not be the cause for the problem, but there's little excuse IMO to productize poorly written code.

The file in question is dc_render.js - which is located in (or referenced from) the JBoss directory

d:\ApplicationContainer\server\default\deploy\iw-cc.war\datacapture\dc_renderer.js

(obviously "d:" is the specific path here - yours may differ, and this issue might apply to Unix servers as well)

The major BUG is around line 1470 where there is code that looks like (hope this comes out reasonably well formatted):
---------- var obj = eWebEditPro.createButton(...omitted-for-brevity...);
retVal += obj.html;
retVal += "...omitted-for-brevity...";----------
The FIX is to change the above to look either like:
---------- var obj = eWebEditPro.createButton(...omitted-for-brevity...);
if (obj != null) retVal += obj.html;
retVal += "...omitted-for-brevity...";----------
or:
---------- var obj = eWebEditPro.createButton(...omitted-for-brevity...);
if (obj != null) {
retVal += obj.html;
}
retVal += "...omitted-for-brevity...";----------

The POOR CODING issue has to do with the fact that MOST of the JavaScript directives using closures do NOT end with a semi-colon. There are LOTS of examples of this throughout the file, but a simple example would be something like this (from around line 589):
----------Renderer.prototype.isActiveItem = function(item)
{
return item==datacapture.activeItem;
}----------
There SHOULD be a semi-colon after the closing curly-brace.

I have attached a FIXED, cleaner, better-formatted (for read-ability), version of the code. If you want to condense it (remove newlines and most white-space) for faster loading feel free to do so - but the fixes should be in there.

REQUESTS:
- Please file this as a BUG.
- Please note the bug ID in the case notes.
[...]
================================================================================================
*** | Dec 20, 2010 @ 04:01:24 PST | ***
Hi Adam,
I filed a bug for this issue and the bug id is TS-13345.
[...]
================================================================================================[/indent]

[indent]*** | Dec 07, 2010 @ 15:49:51 PST | ***

We were trying to debug an onSave FormAPI handler function that was failing in IE.
We brought up Firefox to run the same DCT through with Firebug enabled and found that it bombed out in dc_item_serializer_common.js on line 10. Doing a little quick research, it becomes clear that the parameter passed into the function is not considered a String object - and as such does not have the search() function - which is what was causing Firefox to bomb out.

I fixed the code by changing:
--------------function processForTransport(str)
{
if (str.search("]]>") < 0)
{
return IWSerializer.CDATASTART + str + IWSerializer.CDATAEND;
}
else
{
return XMLEscape(str);
}
}--------------
To:
--------------function processForTransport(str)
{
var txt = new String(str); [color=red]// #=# <<<===
if (txt.search("]]>") < 0) // #=# <<<===
{
return IWSerializer.CDATASTART + str + IWSerializer.CDATAEND;
}
else
{
return XMLEscape(str);
}
}--------------
Which not only fixed the problem in Firefox - but also fixed the problem that we were experiencing in IE-7.

REQUEST:
- Please file this as a bug
- Please note the bug id in the case notes
[...][/color]
================================================================================================
*** | Dec 20, 2010 @ 04:00:43 PST | ***
Hi Adam,
I filed a bug for this issue and the bug id is TS-13346.
[...]
================================================================================================[/indent]

[indent]*** | Oct 05, 2010 @ 11:55:20 PDT | ***

Everytime we try to debug our own custom FormAPI / JavaScript code when editing a DCR, Firebug always bombs out on line 157 of /iw-cc/datacapture/sarissa.js:
"Setting a property that only has a getter"
XMLDocument.prototype.readyState = 0;

Not sure where the actual file is located, but the code appears to be distinctly wrong as per all information I can find about this property via google (everything says it's read-only).

We would like:
(A) Verification of the above being a BUG
(B) The officially filed BUG ID
(C) A field-ready method for patching since we don't expect to get an
official patch immediately, but we do need to resolve the issue that
quickly so that we can get back to debugging *our* code.

Code context:...
if(_SARISSA_HAS_DOM_CREATE_DOCUMENT){
if(window.XMLDocument){
XMLDocument.prototype.onreadystatechange = null;
XMLDocument.prototype.readyState = 0; [color=red]// #=# <<<=====
XMLDocument.prototype.parseError = 0;
...

Reference Material: http://www.devguru.com/technologies/xmldom/quickref/document_readyState.html[/color]
================================================================================================
*** | Oct 27, 2010 @ 11:32:57 PDT | ***
Hi Adam,
I have filed a product issue and is linked to the case. I will go ahead and close the case. You can refer this case to see if the issue got resolved.
================================================================================================
*** | Oct 27, 2010 @ 17:41:23 PDT | Status: Resolved ***
Please provide the actual BUG ID number in the case notes.
(none provided)
I ended up just commenting out the line indicated
================================================================================================[/indent]

Hope that helps.

Amanpreet

Thanks Ghoti,

I update dc_renderer.js for checking null object and now DCR is opening in Firefox.
However visual formatter button is not available/ visible in Firefox. Is this expected behavior or am i missing something.

Adam Stoller

Thanks Ghoti,

I update dc_renderer.js for checking null object and now DCR is opening in Firefox.
However visual formatter button is not available/ visible in Firefox. Is this expected behavior or am i missing something.

Did you try putting the other fixes in place too?
None of this is "expected" behavior for a product that is supposed to be supported on the indicated browser...