I can't find a resource that clarifies the programming differences between Polaris and Orion versions. I've been googling for a few days now.
Probably you already read this article written by Jukka Niiranen
The Next Dynamics CRM User Experience: Orion
I think Gemini release will bring (at least) the possibility to use Xrm javascript with the new forms (actually is really a shame to don't be able to pre-fill a field or to do some show/hide logic) and provide the xml definition that will replace the ribbon.
I'm not sure if there is such a document yet. Before we start with Orion, we have to pass Gemini, first. And given the inconsistency between road maps and reality this far, it could as well be that Orion will be known as CRM-2014.
Related
This is not a technical question, but rather an inquiry on how to get better information regarding the huge numbr of parameters and properties of the various controls you can put in an XPage.
A concrete example:
I have a button which had a property save=true in its event Handler. I added some code in the postSave event, so a lotuscript angent could do some processing, and I started having save conflicts. It took a while but I managed to figure out that the save=true in the event Handler was causing the issue.
I like to know my options, so I wanted to look at what exactly that property ws doing (although the name kinds of give it), but that's when it hit me: where do I look for that kind of information?
Is there a site somewhere that lists all properties we can add and a description of what they are doing?
Maybe my Google skills are not the best, but I couldn't find anything yet...
The three IBM Press XPages books (Mastering XPages 2nd Edition, XPages Portable Command Guide and XPages Extension Library) are key to understanding the implications of the properties. There are the equivalent of Javadocs for controls (here's the link for the XPages Extension Library one), but they're not intended to go into the kind of depth to identify the problem you hit.
These might be useful:
http://xpageswiki.com/
http://www-01.ibm.com/support/knowledgecenter/SSVRGU_9.0.1/com.ibm.designer.domino.ui.doc/wpd_controls_cref.html
Howard
I have a basic knockoutjs project loading data from a SharePoint 2013 list scenario. Getting data and displaying data is easy, the problem that I'm running into is on the edit mode displaying the proper control. Everything should not be a textbox. This means the people picker control to dropdownmenus to calendar controls.
MSFT has some pretty good documentation on using the client side people picker control here"http://msdn.microsoft.com/en-us/library/office/jj713593.aspx
The problem that I have is calling this control inside my viewmodel.
Setting the value of the control doesn't look difficult courtesy of this blog post: http://www.sharepointcolumn.com/sp2013-setting-people-picker-value-in-newform-aspx/
I attempted to looking into computed values, but that doesn't seem to work. Does anyone have a blog post that I skipped over? The closest related post that I can find: http://yetanothersharepointblog.wordpress.com/2012/12/11/working-with-sharepoint-lookup-columns-in-knockout-js/
Lastly since it seems that I'm the only one doing this, does anyone think that I should not be reinventing the wheel with my forms and should just link each item to the appropriate SharePoint list item in edit or display view? I suppose that would be easier.
From a SharePoint Professional to another, I would highly recommend you to do that.
Just redirect the user to the item edit/display item page an let SharePoint take the leash of how to handle UI form elements.
Because, assume that you implement your custom form, what if the user decides to add one more site column to the list? Will you update your code to support another field?
From my personal experience with the beast I've come to the conclusion that structural implementation over already existent functionality tends to go wrong.
Also, if you have some kind of listing of items custom made and you want to provide editing, try to do something opening a pretty SP.UI.ModalDialog, its elegant and you use the sharepoint to do the work for you.
But it's just an advise.
Two questions, hopefully with similar answers.
I'll be releasing a JavaScript package in my solution where the error messages are to be displayed. The problems is that I'll be targeting German, English and French. Possibly, also a fourth language TBD. What would be the nicest way to resolve this?
The label names should definitely be localized. Is there a built-in approach to that in CRM 2011? Like a resource table or something like that?
My current solution for (1) is to keep an extra web resource with the strings and distributing a different file for each language. I may rebuild it and distribute all the languages at once and only use a parameter, possibly settable from the GUI if I create a settings-entity. A bit cumbersome.
My current solution for (2) involves a lot of praying and a divine act of some sort. :)
To determine current CRM user language dynamically from Javascript you can use window.USER_LANGUAGE_CODE (this variable exists on all CRM pages) - for example it will be equal 1033 for English. Than based on that info, you can pick needed string resources from your file.
Also in forms context there are two predefined functions, which return current Organization language code and current User language code: Xrm.Page.context.getOrgLcid() and
Xrm.Page.context.getUserLcid() .
If you are talking about custom entities and fields, you can easily add localized display names for them via your solution. You need to edit customizations.xml file from your unzipped solution. For each attribute there you will find such XML containing display names:
<displaynames>
<displayname description="Created By" languagecode="1033" />
</displaynames>
You can just add new display names for each language you need there.
P.S. If someone interested in different aspects of multilangual support for Dynamics CRM 2011 solutions, I strongly recommend to review this page, also here and here is a very helpful reading.
I am creating a series of window mockup templates based on the excellent Mockups library available on CodePlex.
I'm using their BaseMockup as the base for my control as well, and I followed the same outline of the steps listed here for sub-deriving from existing controls (Create a new empty class, add your default style to /Themes/generic.xaml, etc.)
The control is working great - the only thing is that it doesn't show up in the Assets library. I think this is because it's sub-derived, or because I need some attribute (the equivalent of the ToolboxItemAttribute for WinForms controls? ... which didn't work) to get it hooked up.
When I modify the code to derive directly from Control, it shows up - no custom attribute necessary. Of course that defeats the purpose of what I'm trying to do though...
The only thing I can find are several articles telling me to muck with registry keys, and none of them are clear or suggest a definitive way to do this with Blend 4. That last one advertises as a Blend 4 tips article, but admits at the end that it plagiarizes the content from the other two (for Blend 3).
Is that my only option - register my DLL? Is there a better way to do this?
A while ago I wrote a blogpost about this. I've included a .reg file and a .bat file for setting up the register and some directories. I think that's what you are looking for.
I believe you do need to muck with registry keys. Specifically,
32 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET Framework\v4.0.30319\AssemblyFoldersEx
64 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NET Framework\v4.0.30319\AssemblyFoldersEx
Create a new key with the name of your control assembly. Then edit the Default string value under this key and set the value to the directory where the control assemblies are installed. See here for a full example (using the Silverlight paths).
Found it - there is an analogue attribute after all, it's ToolboxBrowsableAttribute.
You have to go through a little more rigmarole to get it set up, but it works great - no registry mucking necessary. It requires creating a designer metadata provider class, attributing your assembly so it's designer-discoverable, and then adding the attributes to your sub-derived controls inside your metadata provider.
Make sure you choose the appropriate version of the page for your version of Visual Studio, because the interface changes a good bit between 2008 and 2010.
This article on CodeProject has some good, real-world examples of setting this up. They're all in the 2008 style though, so bear that in mind if you're using 2010.
Whenever source control in Lotus Notes development is discussed, it is said that an export-import cycle of DXL data doesn't give you the same design as you started with - thus any system relying on DXL will fail.
I have no reason to doubt this, since the DXL format seems to be a moving target and constantly a step behind what the Domino Designer can express, but:
Does anybody have a specific example of what DXL cannot express?
You can use DXL for Source Control right now if you don't want to actually edit anything out side of Domino Designer. Do this by exporting and importing elements as raw NoteFormat.
For DXL in a format that you can mess about with outside of DD you can trip up in quite a few places. I've not done anything too aggressive with DXL, so others might be able to give you better specifics. Quite a few are discussed here
The openntf project Design Catalog can be used for version control. www.openntf.org/projects/pmt.nsf/ProjectLookup/DesignCatalog
At lotusphere the lotus911 people mentioned they used the Design Catalog in combination with Trigger Happy. www.openntf.org/projects/pmt.nsf/ProjectLookup/Trigger%20Happy
I know there was an issue with Web Service script code not being exported in DXL. I'm sure that's only one of many. IBM has stated they have a goal of "someday" making DXL design exports 100% "round-trippable", but even with 8.5 are not there yet. There is a good discussion here, with postings by developers of design elements which do not export in full fidelity.