I have a custom XSL that I'm posting to an action. Have done this a few times on 1 row XML with no problem. But I have a multi row form I'm trying to post and all the rows other than the first are showing as unbound in the dashboard.
The hidding "_xpath" fields are formatting the same as the generated xsl fields (ie /mvc:eForm/mvc :D ata/UCP_ASSIGN_CHAIR/record[2]/CHAIR_NAME). But for some reason it won't create additional rows of XML. Not finding what is different. XML structure in the <eForm> for the custom XSL is the same the XML as in the bindings (I originally had a regular form but then made a custom one based on that one for additional javascript features). Not sure what I'm missing. Hoping you guys can help.
eForm fragment:
sample xsl field declarations:
$CHAIR_ROWID = postion() (ie 1 2 3 4 ect)
The hidding "_xpath" fields are formatting the same as the generated xsl fields (ie /mvc:eForm/mvc :D ata/UCP_ASSIGN_CHAIR/record[2]/CHAIR_NAME). But for some reason it won't create additional rows of XML. Not finding what is different. XML structure in the <eForm> for the custom XSL is the same the XML as in the bindings (I originally had a regular form but then made a custom one based on that one for additional javascript features). Not sure what I'm missing. Hoping you guys can help.
eForm fragment:
<UCP_ASSIGN_CHAIR xmlns="">
<record>
<ACAD_GROUP_ID />
<ACAD_ORG_ID />
<ACAD_ORG_NAME />
<CHAIR_ID />
<CHAIR_NAME />
</record>
</UCP_ASSIGN_CHAIR>
sample xsl field declarations:
<input id="CHAIR_NAME{$CHAIR_ROWID}" name="CHAIR_NAME{$CHAIR_ROWID}" type="text" class="textbox " maxlength="50" size="50" value="{CHAIR_NAME}" />
<input name="CHAIR_NAME{$CHAIR_ROWID}_xpath" type="hidden" value="/mvc:eForm/mvc :D ata/UCP_ASSIGN_CHAIR/record[{$CHAIR_ROWID}]/CHAIR_NAME" />
$CHAIR_ROWID = postion() (ie 1 2 3 4 ect)
RE: Unbound XML on Multi Rows for Custom XSL
When you are submitting repeating data, there are a couple of extra control fields that are used to indicate how many records are being submitted. My guess would be that you don+?+?+?t have these which is why the additional XML sections are not being created. For example:
<input name="hyfrepeat-1-location" type="hidden" value="/mvc:eForm/mvc :D ata/UCP_ASSIGN_CHAIR/record" /> <input name="hyfrepeat-1-count" type="hidden" value="5" />The first one indicates the context in the data that the repeating information is binding to, and the second how many records are being bound.
If the data is coming from the same location as it is being bound to, then you can use the same XPath value to determine the count value, eg:
<input name="hyfrepeat-1-count" type="hidden" value="{count(/mvc:eForm/mvc :D ata/UCP_ASSIGN_CHAIR/record)}" />If you have multiple repeating data sections on your page, then you would need a set of these fields for each, with a different number in the middle of the names. The number sets the order that they will be processed when submitted. For example, with nested repeats it is important that the parent is processed first.
Hopefully this will enable you to get your page working, but I would be interested in knowing what the JavaScript features were that made you go the custom route.
Ideally we don+?+?+?t want people to need to do this as it can be a lot more complicated to set up and maintain. If you can provide your requirements, we may be able to suggest some other options for you, or at the very least we can keep them in mind for any future WebMaker development.
Regards,
Gerard
RE: Unbound XML on Multi Rows for Custom XSL
As usual, you guys have come through. Thanks again.
The Javascript features we are using are mostly jquery ajax calls to retrieve specific data and dynamically update the html display, as well as save specific data on the fly. Plus a jquery addon for popup messages/modal boxes for validation, confirmation and lookups. We are still on WM 4 since we haven't done the latest Bizflow upgrade, so we don't have the latest features. Most of the forms we do are fine with plain WM generated xsl. But we've had a couple of pretty complicated and heavily used entry forms that we have really struggled with to get working within the generated xsl. We've needed to do a lot of dynamic html and ajax in order to made them work well enough to meet the requirements. So building these forms by hand allow us more control over the html structure and scripting. It takes a lot more time to do them by hand, but it really allows us a lot more freedom. Plus, jquery has some better features than dojo in some areas, but they conflict with each other at times. Custom xsl allows us to strip out the dojo when we don't need it.
It's not our first choice, but it has really saved us on a couple of projects.