Tomcat 7
Orbeon 4.1CE
After using 4.1CE, it cannot read the handwritten form in "orbeon/conf/resources/forms/"
Is there any new file need to define in 4.1 version?
Now, I know that the properties-local.xml affects this problem.
Is there any sample of properties-local.xml for 4.1CE?
First, if you're upgrading, I'd recommend you upgrade to the latest version (4.9 at the time of this writing), since 4.1 is already quite old.
Now, regarding your specific question, I can't remember Orbeon Forms ever using a orbeon/conf/resources/forms folder. Maybe orbeon/conf/resources was setup as a resource folder in your web.xml? If not, this must have been a directory your app was explicitly reading from.
About the properties-local.xml, you can define your own values for properties to configure the way Orbeon Forms works, and for more on this I'd recommend you go through the documentation about properties.
Related
I am using orbeon forms 2016.2 professional edition right now and I plan to switch to 2016.2.1 because the release notes highly recommend for the upgrade. When I perform the switch, can I use the same orbeon database that created with version 2016.2 without doing any patch works?
The data and table format hasn't changed between 2016.2 and 2016.2.1. (And in general, it shouldn't change in point releases, unless the change is really necessary to fix a bug.) So:
If you are using a relational database, and have already upgraded it to the 2016.2 format, or created it with the 2016.2 DDL, you're good to go, and can just switch to 2016.2.1.
If you're using the embedded eXist, you'll want to "copy" the WEB-INF/exist-data to the new version. For more on this, see point 2 in the When using Form Builder and Form Runner section of the documentation.
Is it possible to do a re-publish of orbeon forms automatically? (ie Forms that have been created with Form Builder and which have been saved and deployed/published before).
Actually we are upgrading from Orbeon 3.9 to Orbeon 4.6, and currently we have lots of orbeon forms in our 3.9 environment. since its very difficult to publish the forms one by one after upgrade to 4.6, it will be good if i can find an easy way to republish all the existing forms.
I found something here at https://github.com/orbeon/orbeon-forms/wiki/Form-Runner-~-Home-Page
When I tried this, I didn't get any error but the forms were not actually published. and I got error when I opened a new instance of any existing forms.
Appreciate if any one can help me on this.
Thanks
Did you check the orbeon log for errors? If orbeon is running in production mode there may be an error that is not displayed to the user.
I haven't gone through an upgrade myself, but it's possible that you need to upgrade your form definitions. Orbeon 4.6 includes a feature to do this in bulk on the Form Runner Home Page. See the 4.6 blog post.
This is the same question asked here: Symfony2 standalone form component - setting up a form. The answer to this question seems to fully address the issue.
Unfortunately back when this question was asked the version of the form component was 2.0.x, and several things have changed since, for example the form creation using the form factory is quite different now compare the old code vs the new one.
I looked around but didn't find any documentation or examples on how to do this with the latest versions.
any updated versions of a sample application using the form component outside of Symfony2?
I have a repository demonstrating the standalone usage of the Form component for Symfony 2.1+ with both Twig and PHP as templating engine (check the branches): https://github.com/bschussek/standalone-forms/blob/2.1%2Btwig/src/setup.php
The crucial part is that you shouldn't instantiate FormFactory objects manually anymore (to give us core developers more flexibility in changing its constructor), but use the Forms class instead:
$formFactory = Forms::createFormFactoryBuilder()
->addExtension(new CsrfExtension($csrfProvider))
->addExtension(new ValidatorExtension($validator))
->getFormFactory();
A nice side benefit is that your IDE will list you the setters of the form factory builder, showing you what you can configure and how.
It appears that Orbeon does not support form versioning. When a change is made to a form definition, the form builder will only show the most recent version of the form. We are using MySql to store our data and I have noticed that the form definition is not overwritten in the database. A new line is added with a newer time stamp.
One requirement we have is that old revisions of a form must be trackable. At the very least we need to be able to view old versions of a form. How can this be done? The only way I can think of doing this is creating an instance of a form named with the revision everytime the form definition is updated. Has anyone found a better way to handle versioning in Orbeon?
At this time, and this includes the upcoming Orbeon Forms 4.0, there is no proper form versioning feature in Orbeon Forms (but we have some ideas as to how to implement this).
If what you want is that form data entered with a given version of a form definition is always loaded with that same version of the form definition, then unfortunately that feature isn't there.
Now, as you have noticed when using MySQL or Oracle, form data and form definitions are never actually deleted from the database. But this is more of an auditing feature rather than a versioning feature. With this, if you just want to find or restore an older version of a form, you can do this with a SQL query.
Based on advice posted here and here, I looked into and installed MyFaces CODI with my application. My biggest concern was overcoming the shortcomings of Weld's implementation of #ConversationScoped feature. After some hiccups I got it running on my GlassFish 3.1 development platform, and I converted all my beans to use
import org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped;
In the end it seems like I am now not much further along than I was before. I do not have to call the conversation.begin() method anymore, which is good, but the beans hang around after the browser has left the page and come back.
What I was hoping for was the functionality of JSF 2.0 #ViewScoped that works with CDI. Once the user leaves the page, the backing bean should be discarded and re-created again if the user comes back. Is there a way to do this with CODI?
Incidentally, the documentation says it will pick up the #ViewScoped annotations and process them properly. I tried this and got and Weld wouldn't deploy it.
P.S. I am using myfaces-extcdi-dist-jsf20 version 0.9.5. I tried installing the core and JSF 2 optional module akibe but it would not deploy on my GlassFish/Weld platform. Any advice here much appreciated.
UPDATE 1: I ended up trying the ViewAccessScope annotation supported by CODI, and that seems to do what I wanted.
Follow-up question. The latest bundle that the maven repository that Apache maintains is 0.9.5 -- Can someone post the pom.xml segment that fetches the latest version?
Call conversation.close() before returning - ensure that you imported the correct annotation org.apache... and not javax... - see Wiki or use the ViewAccessScope instead. We are using: bundle in Glassfish 3.1.1 without problems. myfaces-extcdi-bundle-jsf20-1.0.1.jar is the only jar you need. Please also note that there is no "it". With CODI you have fine-grained groupable conversations instead of the monolithic and inflexible stuff you get with standard CDI conversations.
The set-up for the latest version with a Maven build is also in the Wiki.