Rick Strahl's FoxPro and Web Connection Web Log
White Papers | Products | Message Board | News |

Some new features coming in Web Connection 5.37


Friday, May 30, 2008, 9:04:00 AM

The next update to West Wind Web Connection will include a handful of enhancements to the Web Control framework that some of you might find useful. I'm posting about the new features now for some additional input in case I'm missing some obvious usage scenarios. For this release I'm also considering running a short 1 or 2 week beta given the amount of enhancements and also a fair number of fixes and minor framework adjustments. The last couple of Web Connection releases have come with a few small bugs that were caught nearly immediately (and fixed and updated) and I'd like to avoid that this time around. I hope that those of you working actively with the Web Connection Web Control Framework will try out the quick beta and check things out with your own applications for feedback and to catch any latent issues I overlooked.

 

wwWebControl::ControlSourceType Property

Most of the new features have to do with providing better control for Databinding in controls. The first is a new wwWebControl::ControlSourceType proeprty that explicitly allows you to set the type of a ControlSource expression. This can be quite useful if you provide an expression and reduces overhead for Web Connection's internal type checking as well as allow you more control over the expressions you use which now don't have to return only strings but can return any type. It'll become apparent how this might be useful in the next new property.

 

This property is optional and will not effect existing applications. Web Connection simply checks whether this property is not empty and uses the value, otherwise uses the same processing as before. Specifying this option always reduces code by a TYPE() check statement so supplying it certainly improves performance.

 

wwWebControl::ControlSourceUnbindExpression

This property is a result of a question that's come up a few times on the message board and now for me recently while working with a customer that uses business objects that bind through setter and getter methods (rather than property getters/setters). Currently you can provide a ControlSource property which is a binding expression, but that expression is used both for binding and unbinding. This works well for properties and fields, but won't work if you have two different methods for binding and unbinding.

 

ControlSourceUnbindExpression is optional and if specified will be used to manage unbinding of the control into the specified expression. The expression can contain a placeholder {0} to specify the unbound value of the control.

 

For example, imagine you have a GetField("BillRate") and SetField("BillRate",lnValue) to read and write values to a business object. You can bind declaratively with markup like this:

 

<ww:wwWebTextBox runat="server" id="txtBillrate"

                 ControlSourceType="N"

                 ControlSource="GetField('BillRate')" 

                 ControlSourceUnbindExpression="SetField('BillRate',{0})" />


Note that ControlSourceType in this case is required as Web Connection has no way to determine the type from either of these expressions reliably. Actually it does by looking and evaling the ControlSource expression, but it may return NULL and it'd be fairly slow. Providing the type explicitly is much more reliable and definitely more efficient.

 

wwWebControl::OverrideNamingContainer

This property allows you to override the automatic naming container generation that container controls automatically create. If you've ever wondered about how you get names like Panel1_txtName – you're looking at a naming container generated tag name that includes the name of the previous container up the chain plus the actual control name. Panels and UserControls are the most common naming containers, but also template controls like Repeater templates.

 

NamingContainer naming is used by default to ensure unique names of controls. If you didn't have these it'd be possible to create a txtName property on the main page and another txtName property in a panel which would result in only one of these controls being accessible during PostBack or for client scripting.

 

In some scenarios however, the naming container can be a royal pain. For example, if you use client scripting having names like Container1_txtName is painful and so the OverrideNamingContainer property can be set to .T. to force the container control to not add its own name into the control hierarchy. This means when you set this property to .T. on a Panel control for example, and you add a txtCompany field that field will generate simply as txtCompany rather than Panel1_txtCompany.

 

Note that you are responsible then for ensuring unique names for all controls on the page – by disabling naming containers there's the possibility of duplicate names existing on the page.

 

wwWebPage::StopEventProcessing

Another useful helper method is the Page.StopEventProcessing = .T. flag. Typically when you want to stop a request you can call Response.End() to tell the processor to stop all further processing. This works great if you want to manually generate your output, but if you still want to display the page, after some sort of abort operation you'd have to add a property like RequestEnded=.T. and then check in each event that you have code in to exit (ie. If RequestEnded  RETURN ENDIF)

 

This new property essentially handles this for you and lets you exit the current page without processing the rest of the outstanding events. Unlike Response.End() though (which also bypasses further events) with StopEventProcessing set Render() still fires so the page still displays the markup code and controls.

 

The only page events that fire after StopEventProcessing has been set to .T. are Render(), SaveViewState() and Dispose().

 

wwWebTabPage::OnClientActivate

There's also a new method on the Tab Control that allows you to capture activation on particular tab pages. You can use this code to detect and override activation requests.  

 

The following example demonstrates how to prevent page 4 (0 based index) to be activated for example:

 

function onClientActivate(index)

{

    alert( "Activated tab: " + index);

    if (index == 3)

    {

        alert("Tab 4 cannot be activated!" + TabControl[1].) ;

 

        // *** return true as completely handled'

        return true;

    }

 

    // *** Return false to continue to activate tab       

    return false;   
}

 

The tab control client code has also been refactored with a single ActivateTab(tabId,indexOrCaption) function. This should make it easier to create multiple tab controls on the same page.

 

Miscellaneous Fixes and Tweaks

There have also been a ton of small bug fixes and tweaks as a result of a recent project I've been working on that excercised some fairly intense parts of the framework. A number of these enhancements have now found their way back into the framework.

 

 

Posted in:

Feedback for this Weblog Entry


Re: Some new features coming in Web Connection 5.37


Nice Rick! I am using OnClientActivate a lot!
 



© Rick Strahl, West Wind Technologies, 2003 - 2018