My scenario:
The xpage ( document content ) has a complex structure. I have a 1st button which opens this xpage, having in the postNewDocument:
Contr.replaceItemValue("txt_codformularmain","01") // I use this field as a flag.
Now, there is another button which compose the same xpage ... but in this case, I do want the xpage to be different, in other words to have some additional / showed fields.
I could add another code at the postNewDocument, like this:
Contr.replaceItemValue("txt_codformularmain2","01")
Later on, in some views I will filter the listed documents by this 2 fields: some views will be listing the documents where txt_codformularmain=01, other views for txt_codformularmain2=01, and so on.
All the fields are on the same form element. ( I could create easily 2 different xpages, with 2 document contents, but in the form Properties at onOpen and onWebAccess settings, I can add only one xpage )
But, I think it isn't the best approach for this. Because in both cases, postNewDocument takes place, and both fields are having the value 01.
In classic lotus notes programming, I had used only one field ( flag ) and for every different button, inside the button's code I just changed the field value: 01, 02, and so on, before the newDocument had been composed.
Should I use another/ a better approach?
I might go for creating a new form with the fields needed there, and creating a new XPage binded to that form...
dominoDocument.isNewNote() will tell you if it's a new document or not. You can compute visibility based on that.
If it's based on a field value, then again set the visibility based on what the value should be for the panel to be visible - instead of getComponent().getValue() use dominoDocument.getItemValueString() assuming it's a Text field for best practice. In the onblur event of the control that's bound to the field you're checking against, trigger a partial refresh. You will need to amend the default partial refresh settings if there is validation on the page.
Once you're comfortable with that technique, start thinking about using a dataContext to hold whether or not an area should be visible, and referencing that dataContext variable in the rendered property. The benefits of this are not only performance, but youo can give a better variable name to the dataContext to make it clearer when supporting the application what the logic is behind it being visible. For someone supporting the Notes Client app, for example, it's unclear without hunting what state "01" or "02" means. Descriptors like "newDoc", "published", etc have an advantage there.
Another method of optimisation would be to use a Dynamic Content control.
But it sounds like your XPage is going to be complex enough without adding more complexity at this stage.
Related
I have an xPage that is behaving very oddly. (if xPages get corrupt, I think this one might be) Tell me what you think:
I have editable fields with onChange events that take the value of the field (a company name) and looks into the database to see if the company already exists. If it does not, a field called "isNew" is set to "y". BUT the next time a Full Update is performed, from another field or button, my "isNew" field (or all of them) are erased! Why on earth would a full update erase a totally different field?
Do I need to just recreate this xPage?
============================================================================
Ok, here's the onChange event on the editable field that sets the flag:
var c = currentDocument.getItemValueString("company");
var id = #DbLookup("","AD",tc,11); // this view column gets the doc ID
if (id==null || id==""){
#SetField("isNew","y")
}
This field is being set properly - I use a computed field to display it. But the next full update (button, field, whatever) will erase the "isNew" field.
I think your problem is caused by the data sources you have on your page and how you save them.
Maybe you have data sources that gets binded from the url that should not be.
Are you using data sources within a repeat or view panel? If so, make sure you are only saving the correct data source
JSF (and thus XPages) works best when keeping MVC in mind. So you never manipulate a component, but keep that component bound to a model, like a data source or a scope. This way code doesn't get into each other's way.
A refresh of a page computes the whole tree, not just the updated field, so you need to design your calls carefully.
Work directly with your data source so do this instead of #SetField():
currentDocument.setValue("isNew", "y")
This seems like it should be easy to do but I cannot get it done.
I have an Xpage called Location. There are two general types, A and B. I have a series of views for A and B. They are the same except for the value of that one field.
In the views I want my "New Location" button to automatically populate the type to A or B, depending on whether the user is in one of the A views or B views.
Seems like I would set a scoped variable and then check for that on document creation, but it doesn't seem to work. What is the best practice to do this?
Jesse Gallagher's frostillicus framework on OpenNTF (XPages Scaffolding - http://openntf.org/main.nsf/project.xsp?r=project/XPages%20Scaffolding&SessionID=DN6QBBFGEB) includes flashScopes, which give the facility to pass information from one page to another and get cleared when the page is loaded.
You can use sessionScope variable to transfer data from one XPage to another.
A better approach might be to use URL parameter for your case.
Add for example &type=A to your URL like
http://server/database.nsf/Location.xsp?action=newDocument&type=A
Then you can read this parameter in your destination XPage with param.type like
var type = param.type;
The disadvantage of sessionScope is that it's the same for all browser tabs. So, you need to delete it right after usage in this case. Using an URL parameter instead you don't have to think about that.
I want to know if I can click a button in my XPage and dynamically create a Domino View and then show it in a panel control on the same page. The reason I want to do this is because I have a categorized view and I don't want to lose category data by using full text search. So I am thinking of creating a new view dynamically and pass my search parameters, like end date or start date, into the view selection formula.
Is it possible? Any other alternative solution is also welcome.
yes you can, but you don't want to. A Domino view takes space in the database and quite some time for its first use. So you end up with a lot of views taking space and the need to adjust database space after removal. Your response times will suck big time.
Categories as shown in Notes views are no web interaction pattern, so you might want to solve a problem that actually shouldn't exist.
The preferred method for Domino application is navigation / drill down over search. But you could do a FTSearch where you add your category to the search parameters and render your results in a repeat control instead of a view control. There you have more control over the look and feel.
Whether or not it's the best solution, the answer to the immediate question about creating a view on the fly is yes: the Database class has a couple "createView" methods to allow you to create a new view, either entirely from scratch or based on a named other view. From there, you can use the "setSelectionFormula" and "createColumn" methods in the created View to build what you want. You can't do EVERYTHING with those methods, but it may be enough.
One problem you'd likely run into is ACL access: you'll need Designer rights to the database, which a normal user most likely wouldn't have. If you use the sessionAsSigner object to fetch a signer version of the DB (say, "var signerDB = sessionAsSigner.getDatabase(database.getServer(), database.getFilePath())"), you can work from there. Off the top of my head, I don't remember if you will also have to up the "Maximum Internet access" setting on the last tab of the ACL to Designer as well, but you may.
I am assuming that you are referring to the problem that exists when you choose the documents based on the category. This is something that I find highly annoying and I wish that it was possible to turn this on and off. It makes sense for embedded views, but not for much else.
What I did to solve this was to include the category value in the next column. In this way that text could still be seen, even if it was a flat view.
Alternatively, you could also look into using a repeater control and create your own way of presenting the information. This would be used instead of a (Dynamic)ViewPanel control. You could then present the information any way you wanted as long as it is returned in the viewrow set.
Happy Programming!
In my SharePoint List, I have an "Employee" column that is a User type field. I would like to add some custom Business Logic to the processing of this field.
Currently, when the user adds a row, I check to see if the user is an Employee or a Manager and then change the behavior on this column accordingly. I do this by statically rendering the field in my custom "ListForm Rendering Template", just before my custom ListFieldIterator. I simply use a standard SharePoint FormField (and FormLabel) control. In the markup of the FormField control, I specify the FieldName (Employee) and an event handler for the Load event. In this Load event, I will check to see if the current user is an Employee or Manager (using two different SharePoint groups). If the user is an Employee I set the value of the field to the current user (this part works perfectly). I also want to change the field so it can't be modified. I thought I might be able to just change the ControlMode on the field (in the code of the OnLoad Event Handler) to Display, but for some reason this has no effect. The field still renders with the full, people picker editor. Am I not changing the fields control mode soon enough? Or is this simply not the correct approach? The other logic I want to put in is if the user is a Manager, I would like to allow that user to select the person from a list (SharePoint group) of Employees. It may be easier to just use the people picker and limit the selectable users to that group. (I think I can do this with the SelectionGroup property.) Although, it would be better if I could just provide a dropdownlist of users, which I could possibly do with a hidden dropdownlist that I would show and event handlers that I could use (handle event selectedindexchanged) to pull the value selected and populate the (now hidden) Employee (user) field. Does this approach make sense? Assuming all that will work, the real difficulty I am having is with changing the ControlMode (rendering) on the field (when the user is an employee) to a label or some kind of read only control, which is how that field renders when viewing the row, which is why I think if I can just trick the control into thinking it is in Display mode then it should work perfectly!
I am still learning SharePoint, but I am very proficient in ASP .Net. This is why I would like to keep my customizations in this Custom Rendering Template, using code behind and leverage my existing skill set as much as properly.
Any thoughts, opinions or advice? Does anyone know why I can't get the column to switch the "Control Mode"?
I do not think that I fully understand your scenario. Some code samples could help.
But anyway it sounds like you want some heavy customizations of the user field. In that case you might want to have a look at creating a custom field with all its advantages and disadvantages. Have a look at MSDN: http://msdn.microsoft.com/en-us/library/gg132914.aspx
Another option might be - in case you do not want to re-use this column in many list definitions - that you can get away with your custom rendering template and create a custom create/edit form where you implement the specific edit behaviour for the field (plain ASP.NET with some SharePoint controls). Here is a nice walk-through on how to grab a custom edit form from SharePoint designer: http://community.bamboosolutions.com/blogs/sharepoint-2010/archive/2011/05/12/sharepoint-2010-cookbook-how-to-create-a-customized-list-edit-form-for-development-in-visual-studio-2010.aspx
I hope this helps. Kr., Bernd.
I have a SharePoint list that has MANY columns in it. The default AddForm and EditForm rendering is very cumbersome for the users. Most of these fields hold simple Number (integer) values. The default rendering for those two forms (using the ListFieldIterator I suppose) render the columns one by one vertically down the page. My thought was to design an input form with three basic "zones" (left/middle/right) and use a Custom Field for all of these "Number" fields. The Custom Field would contain two custom variable properties "Zone" and "Order". (Zone could contain middle/right and order would be the "order" in that zone the field would appear, the "left" zone would be for the fields that are not these "Number" fields, things like Date, Customer, etc. etc.) I would design the page with an HTML table and 6 Columns (1 for the "label" and one for the "TextBox" for each of the three "zones"). Then I could put a control (something similar to the "ListFieldIterator"). The control in the first zone would render the "static" fields, the zones in the other two zones would render the appropriate Custom Fields (based on the Custom Variable Property "Zone" and "Order").
Does this make sense? For the life of me, I can't figure out how to do this. I had thought about "giving up" and just using my ASP .Net skillset and creating FormViews and GridViews bound to the proper (ListView) DataSources. That has even proved challenging.
Does anyone have any ideas on how I could accomplish this? (InfoPath isn't an option and I want to stay with the "Custom Field" idea so the fields aren't laid out statically and can be moved around or even new ones added by the "administrator" of the Application (SharePoint List).
Any guidance is MUCH appreciated. I have been working on this all week and just seem "stuck".
Thanks,
Shayne
------ A Better explanation of my "application" and what I want to do-----
I have a SharePoint List that has about 60 fields in it. If I pushed this application out using the default Add/Edit SharePoint List Forms (and Rendering Templates), the users would hate it. The default forms use a rendering template that basically lays out all the list fields, one per (HTML) Row. Within that Row there are two (HTML) columns. The first one contains the "Label" for the field, and the second (HTML) column is the actual editor for the "FormField" (Text Box or whatever). Because of the number of fields in the list, the user would have to scroll several pages just to get to the bottom.
This list has about 10 "static fields" that I want to lay out on the left side of the page and then about 50 that are simply "task" fields. These store an integer and track "how many of these tasks did I do today". (This is a "port" of an MS Access application.) Depending on the "Add" page the user selects (I have a "parent" content type that contains every field and then a "child" content type for each "group" of users that will be using this form that contains just the fields/tasks that group tracks) the proper fields are rendered on the page. The problem is they are all rendered vertically and there is too much scrolling. These users (and admins) will NOT have access to SharePoint Designer or InfoPath. So, the "layout" for these fields must be iterator/repeater style (the users shouldn't have to get Development involved just to add a new "task" field to their application!).
The solution I had come up with is to use a Custom Field Type with two Custom Property Variables for each of these "task" fields. The Custom Property Variables (Zone and Order) would allow the administrators of the "application" to control where they want these fields to appear on the Add and Edit forms. The Zone Property can contain one of two values: "1st Task Column" (middle of the form) or "2nd Task Column" (right part of the form). (The "left" column of the forms would be used for those 10 or so "static" fields that all groups/depts/content types share.)The Order would just contain the order to sort the fields in, within their "zone". Obviously, the "zone" would indicate where on the form the field would appear (middle or right). I thought I might be able to use three Divs and render the appropriate List Columns in the appropriate DIVS. Or, following the default rendering template, instad of DIVs I could possibly use 6 (HTML) Columns instead of 2.
I quickly figured out how to make a new Field Type with Custom Properties (I used the Property Schema element in the XML definition, even though Microsoft says NOT to use that in SharePoint 2010, it was just so easy and I couldn't figure out how to add them otherwise. Now I know how to add them the "right" way, I just don't know if it is worth changing them.)
For the last few days, I have tried to figure out how to actually render these "zones". Remember, I want the users of this application to be able to add new fields dynamically, so I can't put any static field references in these forms. I have read about the Rendering Templates and the ListFieldIterator (and the new Content Iterator), but I can't seem to pull it all together and create an actual solution. The part that is throwing me off is how to query and render three different "sets" of fields at once (since the rendering is going to happen from "top to bottom").
Any help is very much appreciated!
Shayne
If InfoPath it out and you want to stay within the SharePoint infrastructure for forms, then the term you need to search for is DataFormWebPart. You may have heard of DataViewWebPart before, well this is the form equivalent. Just like the DVWP, this does lots and lots of XSLT to make its magic happen.
The trick is can you implement your grid/zone idea within the context of the DFWP's XSL. That I can't tell you but hopefully this is a starting point.
Defiantly Info Path is the solution here are some tutorials:
Video: http://channel9.msdn.com/blogs/laurhar/infopath-2010-customize-a-sharepoint-list-form
http://p2p.wrox.com/content/articles/customizing-sharepoint-2010-list-forms-infopath-2010
http://blog.libinuko.com/2010/03/21/sharepoint-2010-howto-start-customize-list-form-neweditview-using-infopath-designer-2010/
if you don't want to use InfoPath I would recomment JavaScript/jQuery you have just to modify (Edit) the page then inject some jQuery code to do what you want. Here are some articles about similar topics:
http://akanoongo.blogspot.com/2008/04/how-to-hide-fields-in-sharepoint-list.html
http://spground0.blogspot.com/2011/03/sharepoint-2010-custom-list-form-issues.html
http://ghamson.wordpress.com/2011/01/19/using-jquery-to-attach-regular-expression-validation-to-a-sharepoint-list-form-field-sp2010-ps2010-projectserver-in/
The only way you can achieve this type of custom form designing within the SharePoint framework is to apply it through post-rendering techniques using client-side code. And solutions like this tend to add considerably to page-load.
Simply changing the render template is not enough if you want it to be a dynamic and codeless experience for end users to author.
I can think of only one solution which comes close to fitting all criteria. It's "free", can be password protected, and also allows tab groups, rules and many other settings.
Dynamic Forms For SharePoint - http://spjsblog.com/dffs