Ile razy podczas pisania stron dla SharePoint musieliście pisać kod do Redirect? Tak by działał on zgodnie z zasadami SharePoint – parametry query string – ? Osobiście nie jestem wstanie tego zliczyć, pamiętam jeszcze jak w IT Core, pisałem to dla Publishing Pages (tam dochodzi parametr CancelSource czy coś w tym stylu jak dobrze pamiętam – choć mogę źle pamiętać ;)).

Dziś miałem dość, i napisałem taki o to kodzik:

#region Hack na Internal Method
 
public static string GetRedirectUrl(HttpRequest request, SPList list)
{
    Type type = typeof(SPUtility);
    MethodInfo method = type.GetMethod("GetRedirectUrl",
        BindingFlags.Static | BindingFlags.NonPublic,
        null,
        new Type[] { typeof(HttpRequest), typeof(SPList) },
        null
    );
 
    object obj = method.Invoke(null, new object[] { request, list });
 
    if(obj == null)
        return string.Empty;
    else
        return obj.ToString();
}
 
#endregion Hack na Internal Method

Przez co jest on wykorzystywany w MOSS/WSS? Np.: przez przyciski Save/Cancel na formularzach. Pamiętajcie, że nie łapie tutaj żadnych wyjątków!! Oraz zwracam string.Empty jak nie uda mi się pobranie URLa.

Teraz pytanie, które mi się nasuwa od razu, czy tego jest więcej? Jak najbardziej. Obejrzyjcie sobie klasy w .NET Reflector SPUtility, SPHttpUtility, SPUrlUtility, SPUtilityInternal, czy SPStringUtility. Tego tak naprawdę jest więcej :)

1 KOMENTARZ

Comments are closed.