How to hide fields in InfoPath web form for different views, requestor and approver

  • 13 October 2008
  • 4 replies
  • 5 views

Badge +1

Hi,


I'm using Infopath 2007 web form which integrates with K2. The intention is to have different views in the form for requestor and approver. In fact there is only one dropdown field to hide from requestors, which is "approve" and "decline" dropdown. The rest are viewable for everyone. I have gotten some suggestion to create 2 views to make it happen. But someone also suggests to have one single view only to be practical and easier to manage.


What is the best practice? and how to do it if we get to have 2 views?


Cheers... 


4 replies

Badge +10
I personally have seen more of the 2 view path.  Someting i have also built many many times.
Badge +9
Just to contradict Chrisg, I've preferred to use the single view approach using conditional formatting to hide/show sections as necessary.  I feel it is easier to maintain, particularly when business rules change (let's face it, they will!) because you only have one place to make the change if it is a common section, be it formatting, rules or adding new fields.  I think you'll find that there is not really a best practice here, it is more personal preference and perhaps the complexity of the form and/or number of fields/sections that would be shared across different views.
Badge +4

As Tim said this is really personal preference, but I feel it also depends on the complexity of the form.  I lean towards the multiple view approach because as forms become complex then conditional rules can become a bit of a nightmare (but then we still use IP 2003 -- I don't know if the rule handling in IP 2007 is better in this respect or not).


For example, in my most recent form I have many views, each for a particular activity in the process, and then on top of that I have 2 copies of each view, one of which is read only and one which is read/write. The form handles determining which view you should see based on a view mapping XML file (stored as a reference file in the form) and some fairly simple code, and supports using hard-coded users, users selected in the form, and SharePoint groups -- it works in a similar fashion to Membership/Roles in ASP.NET.  Each view only shows information that is relevant to each activity, but you can switch back and forth between each view via custom navigation (a drop-down, button and a simple SwitchView method).  When a particular view is lengthy we break that view into "screens", and that's when we use sections with conditional display rules to hide/show the appropriate section and some more custom navigation.  One possible advantage to this methodology is that the security is completely independant of K2, so you can use this for scenarios that don't use K2.  We still use a drop-down for the actions and the nifty Action-based security in BP...


It sounds rather complicated, but it is actually fairly straight-forward, and remarkably flexible.  At some point I would like to post our solution as other might find some benefit from it.

Badge +11

Just to add one more opinion...


I think it is a matter of what works better for your development style. My personal preference is to use multiple views unless the form is really simple.  I find that keeping track of all the rules associated with each field can become difficult to manage. 


David

Reply