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 :)
Dobry Hint, przyda się. Niech ci Bozia w dzieciach wynagrodzi.
Comments are closed.