multiple bowser enabled forms deployment to a form libray without having to use content types
Hi all,
I have a form library (in a MOSS solution),which is a repository from infopath templates,it has some directories in it, and in them, there are several xsn. These are browser enabled forms and open in the browser correctly. Note that they are not content type deployed, they are like normal list items. I needed to move some of these .xsn to another form library, and after copying some of them, these now don't open in the bowser, I just get a "file download" dialog... I configured the form library and the forms services to do so and no luck.
Googling, the only way I find one can have multiple bowser enabled templates is using content types which in this case is not an option...while troubleshooting I copied one of the working xsn to my destop, renamed it, and uploaded it back to the same place and it didn't open in the browser. I assume uploading is not the correct deployment process for these templates...
Anyone has any idea how can I deploy multiple bowser enabled forms to a form libray without having to use content types?
Thanks,
Todas as Respostas
- Are you talking about templates (XSN) or completed forms (XML)? For InfoPath forms to work, they must be opened where their template is published. You can't just move forms (XMLs) around. They only render when coupled with their template (XSN). Templates get published to a library either directly or as a content type, and then you can fill out and edit forms based on that template in the library you used. You by no means upload templates nor completed forms.
Why are content types not an option? That's a very basic and fundamental feature of SharePoint that is critical to its success.
SharePoint Architect || My Blog Hi thanks for the quick reply,
I'm talking about templates themselves not forms. Baisically I have to replicate the existing functionality on another site (but just for a few templates not the whole repository), so multiple xsn templates in a form/document library that open in the browser and not with a "file open/download" dialog.
Regarding content types, yes they are a basic/fundamental feature in sharpeoint but imagine you want to make available 30 templates, centralized in one place (like the users were used to when using the filesystem), to be opened in the browser, and the templates are so simple they don't even submit to anywere, users just use fill and print...having a dropdown with 30 content types...- How was it working before? If you just had templates uploaded to a library, which doesn't really do anything, then how were they being filled out in the browser?
SharePoint Architect || My Blog - That is the problem, I don't know how they were deployed in the first place....I just know how it is working now...templates opening in browser without content types, which I had never seen, but it works and rather nicely I must say...
- The only reason it appears to be working nicely is because you are not using the forms fully. You don't seem to be actually integrating them with SharePoint in that they are not being submitted to SharePoint for use in workflows and for logging or historical purposes. Are people just opening, filling them out, and then printing or something? This would only work if people are not actually doing anything with the form related to SharePoint. InfoPath form templates are not supposed to just be uploaded to the library and used that way, because then anyone can change that template, overwrite it, corrupt it, or if they save the resulting XML file, things will start getting overwritten.
Ok, so rewinding to your first post and understanding that these forms are not being used in the normal way but rather just for printing (seems awfully counterintuitive when the whole point of the e-form is to AVOID paper and save the data in SharePoint instead of a filing cabinet), then they should work the same way in another form library as they are in the original. When you made the new form library, how exactly did you configure it, how did you configure the site collection (enabled enterprise features?), and how did you configure forms services. You said you configured them, but what exactly did you do?
SharePoint Architect || My Blog - Yes they aren't using it fully in some cases they do submit to email, not just print, but it's definitely a minority among those ones. The templates are read-only for the users i think, and in the only thing they can do is submit by email or go to the print view so there aren't many chances they get messed up by the users. Nevertheless using them just for printing is in fact a rather simple use for an e-form but we're working on it.
Well, in the new one I configured the "Browser-enabled documents: Display as a web page" option and in the forms services configuration I checked the "Allow users to browse-enable form template" "Render form templates that are browser-enabled by users " options. What I fount interesting is that I copied one of the working xsn from the old form library to my destop, renamed it, and uploaded it back to the same place and it didn't open in the browser again, just file download... - Hmm, download one of those templates, and click File > Publish. See if there is already a URL in the site publishing page. If so, it means they have been published somewhere prior to being uploaded.
SharePoint Architect || My Blog - well, after choosing to publish to a sharepoint location the only url that shows is http://<host fqdn> (site collection url) not any particular site...no luck there :-s
- What do you mean by "the only url that shows up"? Was it already pre-populated? This is important, because if it was pre-popultaed with a URL, then that form _has_ been published. The root site collection URL does act as a container. If you view that root in Windows Explorer, you may see the form templates there. I'm not sure how that works, but the whole point of this little test was to see if those forms had ever been published, because that's the only thing that makes sense now after the info you've given. The fact that you can't simply download, rename, and upload a template means something else has been done to those working templates to get them to render in the browser in a very non-standard way.
SharePoint Architect || My Blog - Yes it was already pre-populate with the site collection root site. How can a root site collection URL act as a container since one needs to specify the document library or a content type in the next step when publishing a template...?
Having in mind the unsuccessful download, rename, and upload test, "where" in fact is the information regarding the openning of the template? It's not on the template neither on the document/form library | forms services configuration because if so the refered test would work rigth? - I'm not exactly sure - it's hard to figure it out remotely, but there is definitely something squirrelly that was done before you took over. For it to already be pre-populated with that root URL means something - just not sure what.
SharePoint Architect || My Blog - My thoughts exactly...I thought I might be missing some "special" publishing process that could have that outcome...guess not. Anyway if you have any ideas for further troubleshooting...
thanks again
