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.
Related
Is there a way to populate checkboxes component (or different component which allows multiple choice) with dynamic values (just like you can do for a dynamic dropdown)? Let's say I want do populate checkboxes with countries. Example form: https://demo.orbeon.com/demo/fr/orbeon/builder/edit/73aeafa983d00f305fb381d72e59ce7c69e2b1ea
Yes, you can do this with Actions & Services:
Use an HTTP services if your data comes from a service that returns JSON or XML.
Use an database service if you prefer to write SQL to extract data from a database.
Use an action to define when your service should be called (e.g. on form load), what data you want to pass to the service (if any), and what to do with the result, which, in your case, it to set the choices of a selection control.
And note that Actions & Services are a PE feature.
I could update and publish existing form definitions in Orbeon:
When you create, edit, or read form definition with Form Builder, form definitions are stored as Form Builder data. That is, they are stored under: /crud/orbeon/builder/data/[FORM_DATA_ID]. On the other hand, when Form Builder publishes a form definition, it stores it where Form Runner will find it, that is under: /crud/[APPLICATION_NAME]/[FORM_NAME]/form. For example, this is what happens when saving and publishing a form definition acme/demo with a single attachment.
However, I don't know how to create a new Form Definition using REST API. Can someone please provide me an example of the REST call for creating a new form definition?
Most likely, the easiest way is to create an empty form in Form Builder, save it, and then retrieve the XML stored in the orbeon_form_data table in the newly added row, in the xml column (assuming you're using a relational database). Then, with that XML in hand, you can write your own code that creates a new row through the CRUD API.
Also, RFE 3080 covers an enhancement that might make this easier for you. It was written with creating new instances of forms you created in Form Builder mind, not new instances of a form definition, but in essence the idea is the same.
I think the answer is no, but the question has been put to me so I'd like to confirm. My understanding is that any custom XBL control that I create for use in Form Builder can have one and only one value. Is this correct?
I have always assumed this because the control name is then used in the data instance as the name of the node which contains the the value.
This question comes from the desire to have reusable components with multiple values, for example, an Address control so that addresses can be recorded consistently and the same set of fields does not need to be added many times. Orbeon does have some support for this in the form of Section Templates but because the control names stay the same in each instance of a Section Template this does not work well with our design.
The best idea I've had is that a custom control which records multiple values could encode all the values into a single text string for example in JSON. Of course, this is not ideal.
Are there any other options?
It is possible for controls to have multiple values. When that happens the values are typically stored in nested elements. I.e. a control could bound to an element <address>, and could create nested elements <street>, <city>,<country>, etc to store the different parts of the address.
In practice, you can look at how this is done in the Image Annotation annotation control (see wpaint.xbl), which creates nested elements <image> and <annotation>, leveraging the xxbl:mirror="true" functionality.
In an MVC4 project, I have a form that contains a partial view which is an index view of languages studied at school. It is a default type view template index, with Add, Delete, Edit links per row etc. When you Add or Edit, it opens an Add or Edit view for a Language. After e.g. adding a language, the updated partial view is returned.
My problem is that if the user opens the Language form, edits and captures on the main form will be lost. I can't just do an Ajax save before opening the Language form, as the main form may only be partially complete and fail validation. What I am thinking of doing though is using an AjaxPreserve action that takes a FormCollection, and stores it in session (o on disk, or anywhere) and therefore no model binding and server validation is performed.
I then have two problems: I will need to disable client validation before calling the AJAX action, and I will need to repopulate the main form using the FormCollection I saved earlier. I think there should surly be some jQuery voodoo to disable client validation, but I am completely stumped on repopulating the form.
ALTERNATE SOLUTION: Instead of using 'sub-forms', I can use editor templates, in pop-ip forms, where the FK IDs are not required, but that us only in certain cases, so my question still stands.
Could you use something like Knockout where you create javascript model and bind it to a grid/dialog edit/template view. I would transform the whole data to a JS model, bind it to a table/grid and then track all changes on the client side. When all is done, just serialize the whole model back to the server and update the data store.
If this is an acceptable scenario, it will save you a lot of trouble.
Familiarity with Knockout is required, but if you've used it before, you will be able to solve this in a very clean and efficient way.
This example on the Knockout website gives an idea of what I'm trying to suggest. Editing, deleting, adding is done on the client side until you send all of the data back to the server. You will need to track flags for each object to know if it's added, edited or deleted.
http://knockoutjs.com/examples/contactsEditor.html
Simple make the sub request for adding language using Ajax and repopulate the dropdown or what ever way you are accepting language on the main form on sucessfully save.
*This will save a lot of effort. *
Why don't you just use javascript?
E.g. You have main form, that stores some data. And when you need to add something specific like languages you open popup using partial view, allow user to fill form, but when user press submit you intercept action with js, save stuff to javascript array/object or whatever else and maybe store it in a hidden field of main form - for final submit
var newData = new Object();
newData.Field1 = $("#yourField1");
...
lanuageData.push(newData);
$("#languageContainer").val(JSON.stringify(languageData));
...
DataAnnotation validation works here as well like:
$.validator.unobtrusive.parse("your_partial_view_container");
When you need to edit some object that was already added to js array - open popup and fill it up with element of you js array. So basically you do all CRUD on client-side, saving changes only on final submit.
To make your code in a conrolller more clear you can use custom model binder which deserialize some string field from JSon to List or any other kind of object -> so it can be validated on server side.
Would saving your values to local storage be acceptable? What about using TempData?
In my web application framework (currently WebForms) I have a control that behaves like a classic propertygrid. It is initialized with an object ID (database key), then it reads metadata to determine the type of the object and the attributes of the object. It displays the attributes, string attributes as textboxes, bool attributes as checkboxes, enum attributes as dropdown lists. On page submit there is a method of the control ctrl.SaveData() that saved the changed attribute values back to the database.
The WebForm control tree and event model supports this approach quite nicely. Now I am asking myself if it is possible to achieve a similar solution for ASP.NET MVC. The main objective is to have a generic, reusable component that can be applied in a variety of situations with not much hassle. Additionally the solution must be flexible enough to put multiple instances of the component for multiple objects on a single page. Here the auto-generated WebForms HTML IDs also helped.
I am very curious about your ideas! Thanks a lot for answering!
You could achieve this effect using a custom ViewModel that contains enough metadata to identify the object being edited/saved. You would use this in conjunction with a partial view that renders the ViewModel. The main page would use the metadata in the ViewModel to either direct the post to a specific controller action to save that particular object or pass the metadata back to a common action (as hidden inputs, perhaps) in order that that action can choose the proper table in which to persist the data.
Personally, I would not take this approach. My feeling is that the more general you make a view/action, the more work it becomes to adapt it for different circumstances. I have done similar things for viewing sets of objects, but for a detail view or editing I like to work with more specific models and views.