Morning
I've been asked to make some form changes to an old (v3.1.2) project. It's one of a number of projects that all use the same header page. I've done so, then republished the project, and two of the fields in the header are not displaying any information. The bindings look ok, there are no errors in the logging (that relate to this anyway!), and no js errors on the page. Can you think of any reason why the info (which i can see in the xml factbase) doesn't map across?
To make things even odder, the same header project which doesn't display the info works fine with the other projects!?! :huh:
Thanks
I've been asked to make some form changes to an old (v3.1.2) project. It's one of a number of projects that all use the same header page. I've done so, then republished the project, and two of the fields in the header are not displaying any information. The bindings look ok, there are no errors in the logging (that relate to this anyway!), and no js errors on the page. Can you think of any reason why the info (which i can see in the xml factbase) doesn't map across?
To make things even odder, the same header project which doesn't display the info works fine with the other projects!?! :huh:
Thanks
RE: Bindings issue
This does seem strange.
Without being able to see the actual details it is hard to say for certain what may be causing this.
One common cause when the data otherwise looks correct is namespaces. eg the data element has the correct name and position, but is in a different namespace to that expected by the field binding xpath.
This could possibly explain the differences between your projects, as one could be passing the value in with a different namespace to the others?
Alternatively, could this actually be an issue with the deploy/publication area, eg the changed project has not included the correct version of the header?
If you can provide the full debug logs and the page XSL files I can have a look in more detail to hopefully explain what is happening. You can send these privately rather than posting on the forum if you would like.
Regards,
Gerard
RE: Bindings issue
Thanks for sending the details through.
I can see from the logs the problem you are getting, but unfortunately have been unable to replicate it in any of my testing.
Are you able to get the same problem when previewing the page in the studio? (eg by taking the real data from the logs and using this for the contents of the to_tabMainHeader_page.xml document in the components project.)
Are you able to test the project using local deployment, and if so do you get the problem here?
On the published environment where you are seeing the issue, do you get the problem every time or is it intermittent? Although there are not any relevant errors in the WebMaker logs, can you check if there are any details being output in the Tomcat logs (or whatever server you are running on)?
The two fields that seem to have the problem are both date fields. Could you try temporarily changing these to just string values (and so removing the date format conversion) and see whether you still get the binding problem?
I+?+?+?m sorry I can+?+?+?t yet explain this problem, but hopefully with some more information we can start to track down what is going on.
Regards,
Gerard
RE: Bindings issue
I got dragged off this to another project, and am just now looking at it again. Hope you had / are having a good Xmas.
Just as further info, I've followed both your suggestions:
- the problem does not occur when viewing the data in the test page.
- the problem also does not appear when the field type has been changed to string. Changing it back causes the problem to re-occur however. Odd.
Thanks
Graeme
[hr][/hr]
In addition, I've just reviewed the TC log too, and spotted this...Looks like there is a problem reading the parse-format-date xsl.
This is a new one on me - I've done basic things such as deleting the conversions.xsl file and re-adding it from a copy I know works. Any suggestions?
ERROR BELOW:
file:/d:/Program%20Files/Apache%20Software%20Foundation/Tomcat%207.0_Tomcat7WM/webapps/bizflowwebmaker/HRP_RiskRenewal/doc/JLT_HRP
/mvc/HRP_Components/views/view/Page_Painter/tabMainHeader.xsl; Line #1739; Column #63; Could not find template named: parse-format-date
file:/d:/Program%20Files/Apache%20Software%20Foundation/Tomcat%207.0_Tomcat7WM/webapps/bizflowwebmaker/HRP_RiskRenewal/doc/JLT_HRP/mvc/HRP_Components/views/view/Page_Painter/tabMainHeader.xsl; Line #4; Column #39; Had IO Exception with stylesheet file: conversions.xsl
file:/d:/Program%20Files/Apache%20Software%20Foundation/Tomcat%207.0_Tomcat7WM/webapps/bizflowwebmaker/HRP_RiskRenewal/doc/JLT_HRP/mvc/HRP_Components/views/view/Page_Painter/tabMainHeader.xsl; Line #1667; Column #62; javax.xml.transform.TransformerException: ElemTemplateElement error: parse-format-date
file:/d:/Program%20Files/Apache%20Software%20Foundation/Tomcat%207.0_Tomcat7WM/webapps/bizflowwebmaker/HRP_RiskRenewal/doc/JLT_HRP/mvc/HRP_Components/views/view/Page_Painter/PendTask.xsl; Line #4; Column #39; Had IO Exception with stylesheet file: conversions.xsl
file:/d:/Program%20Files/Apache%20Software%20Foundation/Tomcat%207.0_Tomcat7WM/webapps/bizflowwebmaker/HRP_RiskRenewal/doc/JLT_HRP/mvc/HRP_Components/views/view/Page_Painter/PendTask.xsl; Line #73; Column #54; javax.xml.transform.TransformerException: ElemTemplateElement error: parse-format-date
RE: Bindings issue
The conversions.xsl was not present in the PagePainter folder on the published version of the project, but was at designtime and runtime on my pc. Very strange.
Thanks for your help Gerard.
RE: Bindings issue
That was good timing.
I was just starting to look at this again and you have managed to resolve it! :)
With regards to why the file wasn+?+?+?t present, one thing you can check is that the conversions.xsl is definitely defined as a resource of the view Page_Painter node in the studio. It is these lists of resources that control which files get deployed/published to each directory.
Regards,
Gerard
RE: Bindings issue
The file was listed as a resource. However, the view.xml file in L1_pattern_instance_pool didn't seem to reference it correctly though. Very strange.
Thanks again.