I am working on an xhtml page that containt one very big form.
Within this form there is a loop driven from database results. Each row returned has a corresponding fragment which contains form inputs contributing to the outer form.I have wrapped this entire structure in a panelGroup for easy updating via Ajax. The problem is that these fragments each contain multiple modal dialogs which have fields that should be submitted independently from the outer structure
Is there any technique/ or something in omnifaces that can allow me to exclude specific components from the execute/render process?
rendered attribute allow to exclude component from rendering. Modal dialog(s) can be moved outside form.
Related
We consider Orbeon PE 4.10 for one of our projects. I know that you can add custom form elements as XBL components. Therefore, I read this documentation.
For our project, we need to add datamodel elements to the Form Builder (like the creation of an Microsoft Access form for an existing Access datamodel). Let´s say we have an existing database datamodel with an entity event. This entity has e.g. 15 database attributes like an arrival date, expected number of participants, topic, description etc.
When I create a new form for an event in Form Builder, I want to see all the fields mentioned above in a tree structure so that users can drag and drop those fields into a form (exactly like in Access). In addition, there should be a data binding between the form elements and the database entity.
My question is, of this is possible to realize without changing the source code of orbeon forms PE?
Orbeon Forms doesn't do "relational database mapping", but instead focuses on data capture. So the approach is maybe a little bit different than what you would do in Access. Instead of starting with a database schema, and then designing a form that you map to that schema, you start with the form, and Form Builder automatically creates an XML document for you that holds the data entered by users, and that XML document is typically stored as-is in your database. Then, when you need to access the data, you have Orbeon Forms send the XML to your app, go through the REST API, or access the XML directly in the database.
Now, about the event use case you're describing, if this is something that happens in several forms, you can create a section template for that event, and reuse it whereever you need it. For cases where you need something more custom, like a special date field, map field, or special type of number that requires a custom validation, you can create your own XBL component, which gives you more control, but requires a little more work to put in place compared to section templates.
I have two primefaces (p:layoutUnit) widgets: a tree in the layoutUnit on the left of my page and and a dataArea (to be decided on) in the layoutUnit in the center of my page. I have the tree menu working so that when a node is selected, the appropriate DAO method is called and the object(s) is(are) returned. My trouble is, is that the object is returned to the tree's form on the left of the page.
My question is: how can I get the returned object(s) to populate in the center of my page? Is there a JSF mechanism to do this?
You can leverage the select event of the <p:tree> component to issue an ajax call that will update the dataArea of your page based on the selected node:
For example:
<p:tree value="#{treeBean.model}" dynamic="true">
<p:ajax event="select" listener="#{treeBean.onNodeSelect}" update="form2:dataArea"/>
...
</p:tree>
In onNodeSelect, you'll populate an instance variable on your controller with the value(s) you want to show in dataArea. Setting the update attribute to "form2:dataArea" will cause the page to update the dataArea to the latest state (and pick up the data you've placed in the instance variable). Note that "form2:dataArea" is just a guess as to what your second form id and dataArea's id are labeled as.
Is it best to NOT label a form component (or any other component for that matter) unless you have a need to do so e.g. if you want to be able to reliably distinguish one component from another?
When I see examples of reference components I am always seeing them with a preceding colon e.g. ":dialog" rather than "dialog" or "form:dialog". Is not naming the form and then specifying the component using a preceding colon the best practice?
If you don't specify the id of the form because you don't need to reference it by a client ID right now, then it will technically not harm to omit it, because JSF will autogenerate one in any way.
From inside an ID-less form, for example, you can always reference the parent form as #form in execute and render attributes of <f:ajax> to signal that you want to submit and/or render the entire parent form.
<f:ajax execute="#form" render="#form" />
But if you need to reference for example another form or one of its child components on ajax render, then you should give that form a fixed ID, so that you will be able to reference it by client ID.
Another reason which we're experiencing in real world projects is that automated web unit testing software such as Selenium really requires a form with a fixed ID, because it needs to find the input fields and submit buttons by their name attribute which is also composed based on the JSF form ID. If the JSF form ID is not specified, then the input field name is unpredictable on every deploy/request and thus untestable.
All with all, the "best practice" is basically: "only if you need it". I myself am just getting used to always specify the ID of NamingContainer, UIInput and UICommand components. "You never know".
Your component ID would look something like,
:namingContainer:myComponent. Where the first “:” tells JSF that you
want to start looking for the component at the UIViewRoot instance, or
the very top level of the component tree
Read http://ocpsoft.org/java/jsf2-java/how-to-jsf-2-0-render-components-outside-of-the-form/
I'm using a section template created by Orbeon Form Builder that I included in another form also created by Form Builder. When in this form we make the section template invisible, it disappears from the form instance.
Is it possible to make the section template invisible without loosing it in form instance?
For each section templates, Form Builder generates an XBL component which wraps the fields in that section. In the form that uses the XBL corresponding to the section template, in the XML for the instance, there is just one element for the whole section, and the XBL component is bound to that element. The XBL component "knows" what the XML for the fields in the section is, and at runtime, when it becomes relevant, it inserts them inside the element for the section. Hence, if the section never becomes relevant, those fields will be missing from the instance.
This behavior isn't consistent with what happens for regular sections, but it shouldn't cause any particular problem to Form Runner. Say, if you save the data without those fields, edit it later, and the section becomes relevant, the XBL component will then add the elements to the instance. For this reason, we created this issue.
I dont work on Form Builder, but you can make section/fields invisible using
<xforms:group> or
by using relevant condition in bind definition.
If you use <xforms:group> then the section/fields will not be removed from model instance.
If you use relevant condition, then the section will be removed from model instance when the relevant condition is false.
I am currently binding an IEnumerable collection to a ListBoxFor, which works as expected, sending the currently selected values on POST. However, I need to send all the values instead (essentially any value in a given ListBoxFor I consider to be required, whether selected or not). How would I go about doing this?
(I can probably rig something up in jQuery where, on-submit, it manually selects all the elements in a box, but was wondering if there was a better way.)
If you want to continue using normal browser form serialization on submit, write a javascript function to fire right before the submission (hook into an onclick event or something) which iterates through the list box control and concatenates the desired values (perhaps comma-delimited) and places it in a hidden field. The value of that hidden field will be submitted normally and you can parse the individual values from it on the server side. It's still some manual work, but you avoid messing with GUI state (i.e. selecting all desired list box items) which I agree is something you don't want to do.