OpenSlx Library
Posted By: nicocrm on March 22nd, 2010 in Uncategorized
No Gravatar

Just wanted to do a quick post to introduce the OpenSlx library I mentioned in the previous post about SimpleLookup. The library is available from GitHub at http://github.com/nicocrm/OpenSlx. It is free to use in your own customizations, or you can rip code out of it and put it into your own stuff, though as it is placed under the GPL license there are a few limitations:

  • you can take the OpenSlx library, modify it, and redistribute it as part of a customization, without having to publish it (though you would have to make the source code available to the customer, at their request, which is the usual business model anyway). The same apply to ripping out code – you can rip the code and put it into your own customizations, without having to publish those (other than to the user of the code, i.e. the customer – this does not include the actual end users, either SalesLogix users, or their own customers accessing SalesLogix via customer portal)
  • you can take the OpenSlx library, unmodified, and include it as part of a proprietary component – you would have to make available any modification you make to OpenSlx, or any derived work (e.g. if you were to create a subclass), but other parts of your package would not be affected
  • you can’t take the OpenSlx library, add some controls to it (or fix some of the existing ones), and resell it as a proprietary component – this is the kind of change that I hope would be redistributed
  • you can’t rip some code from the OpenSlx library, and include it into your own, proprietary component which you resell as a software package – you have to leave the code separated. However you can rip some code, and include it into your own open source components – they will have to be released under the GPL as well, though

2010-06-27: I changed the license to Apache, so most of the restrictions above do not hold anymore, even though I still hope that you would contribute improvements back to OpenSlx. Without getting into details, this was the only practical way for me to be able to keep contributing to the code.


Simple Lookup – for Slx Web
Posted By: nicocrm on March 15th, 2010 in Uncategorized
No Gravatar

This is going to be another quickie because I am in a hurry!

One of the most boring tasks when creating custom smart parts is setting up the lookups. There is next to no help from intellisense, so it takes a while to get right in the first place, but worse than that, if the user wants to add a column to a lookup you have to go through ALL the forms that have that lookup and add it by hand (this is actually a problem with QuickForms too, not just custom smart part). What a huge usability setback from the LAN client where they can just design their lookups in the Administrator.

In order to (partly) remedy that I created a component called “SimpleLookup” that runs through the Lookup table meta-data and populates the LookupProperties collection accordingly. So basically you create the lookup as:

<OpenSlx:SimpleLookup LookupName="ACCOUNT:ACCOUNT" 
   LookupEntityName="Account" ID="lueAssignDistributor"
   LookupBindingMode="String" AutoPostBack="true"
   LookupEntityTypeName="Sage.SalesLogix.Entities.Account, Sage.SalesLogix.Entities" 
   runat="server" />

The LookupName part is the important part – you can either put the Lookup Name (as defined in the lookup manager) or the search field (similar to how we used to reference lookups in the LAN client). Now when you want to add a column you can add it in the familiar lookup manager (though it is cached for efficiency so it may still not show up for a few minutes or until the application pool is recycled).

This SimpleLookup is part of a growing collection of components that I am able to make available as open source – it is available on GitHub at http://github.com/nicocrm/OpenSlx, along with a few other pieces like the SimplePicklist I blogged about before. Note that it won’t handle the more exotic lookup definitions (in particular any link used in the lookup must also be defined as a relationship in the Application Architect) so be sure to test the particular configuration.


Validation of SalesLogix Lookup Controls
Posted By: nicocrm on March 8th, 2010 in Uncategorized
No Gravatar

OK so I am really, really loving JQuery lately. This is a neat use of how to add a custom validator for a lookup control in SalesLogix. The lookups have this “Required” property which you can turn on to make them required, but this has 2 major flaws:

  • Can’t specify the validation group, in case you want the lookup to only be validated in certain cases
  • More importantly, can’t specify an error message, so you are left with the default tiny-ish red asterisk. I don’t know about you but I like my error message to be big, bold, and explicit.

So we have this RequiredFieldValidator, part of the standard ASP.NET controls. This is so handy for validating textboxes but if you try to have it validate a lookup you will get this beautiful error message:

Control 'luePurchContact' referenced by the ControlToValidate property of '' cannot be validated.

There is a customvalidator that lets you specify your own validation function, and you can do that. This would look something like:

 <asp:CustomValidator ID="CustomValidator2" runat="server" ValidationGroup="SubmitCredit" Text="*" OnServerValidate="luePurchContact_Validate"
                ErrorMessage="Please select Purchasing Contact"/>

and then in the code behind:

    void luePurchContact_Validate(object source, ServerValidateEventArgs args)
    {
        args.IsValid = (luePurchContact.LookupResultValue != null);
    }

The big problem here is that this requires a postback. Postbacks are slow. You want to avoid them as much as possible. They waste bandwidth, server CPU, client CPU, they look ugly, they cause the control focus to be lost, and they mess up Javascript customizations. They suck. Furthermore, if some controls require a postback to validate, and some don’t, the users will only get a partial validation at a time, which is annoying.

Anyway, Microsoft thought the same thing of postbacks, and they provided an extension to these customvalidators that let you do the validation in Javascript. So the only difficulty is, how do we retrieve the lookup’s value in Javascript? It’s very easy if you know the client id, but ASP.NET has this nasty tendency to mangle those. Not a big deal though, as JQuery is still able to find controls based on the last characters of the id (assuming there is no other control with that same id in the page). This lets me write the following for validation:

<asp:CustomValidator runat="server" ValidationGroup="SubmitCredit" Text="*" 
 ErrorMessage="Please select Purchasing Contact"
 ClientValidationFunction="(function(s, e) { e.IsValid = !!$('input[id$=luePurchContact_LookupResult]').val(); })" />

If you are suspicious about another lookup with the same id on another part of the page, use the following instead:

<div id="frmAccCredit">
<!-- 
  "frmAccCredit" would be a unique identifier for the form.
  You can use anything that is going to be unique, and put it at top level of the form.
  This is also handy for designing css rules that should not affect other
  parts of the page.
-->

...
more stuff
...

<asp:CustomValidator runat="server" ValidationGroup="SubmitCredit" Text="*" 
 ErrorMessage="Please select Purchasing Contact"
 ClientValidationFunction="(function(s, e) { e.IsValid = !!$('#frmAccCredit input[id$=luePurchContact_LookupResult]').val(); })" />