Blog posts by Yugeen Klimenko

Blog posts by Yugeen Klimenko2011-06-30T10:33:37.0000000Zhttps://world.optimizely.com/blogs/Yugeen-Klimenko/ Optimizely World How EPiServer URL Rewriting works.It is known that EPiServer transforms the urls in both directions – internal and external. For example when you type in your browser <a href="http:// YourEpiSite / Default">“http:// YourEpiSite / Default</a>” this address is transformed into its internal form  inside EPiServer –   <a href="http:// YourEpiSite / Default.aspx?id=3&epslanguage=se">http:// YourEpiSite / Default.aspx?id=3&epslanguage=se</a> . Anyway you will continue to observe the <a href="http:// YourEpiSite / Default">http:// YourEpiSite / Default</a>  in the address field. From the other side if EpiServer  comes upon a reference somewhere in your .aspx page template –  like …<a href=’<a href="http:// YourEpiSite / en / Default.aspx">http:// YourEpiSite / en / Default.aspx</a>?id=3’ \>, – then this address would be transformed into its external form: <a href="http:// YourEpiSite / Default">http:// YourEpiSite / Default</a> . Two main principles are at the heart of those transformatiions: modifying the HttpContext address and filtering the HttpResponse via streaming. Let us look on these techologies. To Internal Direction. One can change the URL addressed via HttpContext. That is if you address  the <a href="http://…./Default.aspx">http://…./Default.aspx</a> page but you provide your  Application_BeginRequest handler with the following code : HttpContext context = HttpContext.Current; context.RewritePath (“~/WebForm.aspx), - then the WebForm.aspx content would be displayed in browser while the <a href="http://…./Default.aspx">http://…./Default.aspx</a> being displayed in the browser address field. This technique is used in EPiServer URL Rewriting infrastructure. It relies upon two main items : 1) UrlRewriteModule, i.e. http module implementing the IHttpModule interface; 2) FriendlyUrlRewriteProvider – the “working horse" class which really performs converting the URL in both directions itself. This is the correspondent class diagram : <a href="/link/e164f222983a40a6979c4940eda48b97.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="/link/5969c84bb9d74ba584e570b18727245d.png" width="460" height="179" /></a> The core of the process consists in that UrlRewriteModule being the ASP.NET HttpModule performs its Init function in which it sets the HttpApplication.BeginRequest to its own BeginRequestEventHandler. As a result when the request takes place code in BeginRequestEventHandler makes a call to the HttpUrlRewriteToInternal method. The latter one prepares the query parameters namely page id and language identificator. These parameters are passed to the HttpContext.RewritePath method. This is the “magic” place itself where the redirection takes place. The sequence diagram is <a href="/link/afd8bd43232148f88836c628d3cda68b.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="/link/cef73354dc824b7b8c1b8d4a671ac06c.png" width="465" height="539" /></a>   To External Direction. If you want to put neccessary corrections into the whole http response content  (f.e. to turn every letter in uppercase or trim the spces between the words) you should: 1) declare new class inherited from Stream, f.e.: public class TrimStream: Stream 2) implement the Write method in it: public override void Write (byte[] buffer …) { … trim all the spaces …. } 3) set it to the http response filter (you can do it in Application_PostRequestHandlerExecute method in Global.asax): … Response.Filter = new TrimStream (Response.Filter); …   EPiServer uses the same principle. For example, you have <a href=’<a href="http://YourEpiSite/en/Default.aspx?id=3&epslanguage=se">http://YourEpiSite/en/Default.aspx</a>?id=3’ \> in your .aspx page. When displayed in browser url would be transformed into its external form - <a href="http://YourEpiSite/Default">http://YourEpiSite/Default</a>. This is made via streaming – in the HtmlRewriteStream class object. The sequence diagram is given below. <a href="/link/368aca576d2f46088a019bd7932f4fe1.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="/link/c0056ba1503a42168ff3c8d4404b2bbb.png" width="439" height="509" /></a> 1) In UrlRewriteModuleBase.Init PostRequestHandlerExecuteEventHandler is attached: … Init (HttpApplication application) { <blockquote> application.PostRequestHandlerExecute += new EventHandler(this.PostRequestHandlerExecuteEventHandler); … </blockquote> 2) When PostRequest takes place the HtmlRewriteStream object is created in UrlRewriteModule.HtmlAddRewriteToExternalFilter method: UrlRewriteModule.HtmlAddRewriteToExternalFilter (HttpApplication application) { <blockquote> Stream stream = htmlRewriter.GetRewriteFilter; application.Context.Response.Filter = stream; </blockquote> }, where HtmlRewriteToExternal.GetRewriteFilter() returns the object of HtmlRewriteStream class. 3)  Finally HtmlRewriteStream.Close is triggered and HtmlRewritePipe.RewriteToEnd method is called.   Then HtmlRewritePipe parses the html content looking for the special elements – i.e. those which can contain urls as their attributes values – f.e. a, area, script. etc…, – and transforms urls into their external forms. Transformation itself is made the following way: 1) obtain the PageReference object from the current url via PermanentLinkUtility.GetPageReference( string url) 2) obtain PageData object from the PageReference object: PageData pageData = DataFactory.Instance.GetPage(PageReference pageReference, …) Due to PageData hierarchical structure we can call the Parent.SegmentURLs recursively and combine them into the whole external address: http:\\EpiSite\Level1\Level2\…..   You can exclude the part of your HTML markup from this kind of processing by putting it inside the container with EPiNoRewrite=”True” and id=”idNoRewrite” attributes: <div EPiNoRewrite=”True” id=”idNoRewrite”> <blockquote> <a href=’<a href="http://YourEpiSite/en/Default.aspx?id=3&epslanguage=se">http://YourEpiSite/en/Default.aspx</a>?id=3’ /> </blockquote> </div>2011-06-30T10:33:37.0000000Z

Blog post

The EPiServer Pages and Properties From the Database Point Of View.The database diagram describing relations between EPiServer pages and their properties is given below.<a href="/link/1fda545c5c0248de8cb499893628de31.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="/link/a575dda46330463aa5309515db76742a.png" width="366" height="300" /></a> As you can see the tables tblPage and tblWorkPage are connected with “one – to - many ” relation. The main record about the page is stored in tblPage and the page  versions records are saved in the tblWorkPage. The query getting all the versions for the page with id = 49 looks this way: select * from tblPage p join tblPageType pt on p.fkPageTypeID = pt.pkID join tblWorkPage wp on wp.fkPageID = p.pkID where p.pkID = 49 When you create new page new record is added to the tblPage table. Everytime you publish  new version of the page the correspondent record is inserted into the tblWorkPage. Information about the page current version is stored in tblPageLanguage.PublishedVersion field which can  contain one of the tblWorkPage.pkID values. Evidently, if you need to get the properties values for the given page version ( f.e.130)  you should execute select * from tblWorkProperty where fkWorkPageID = 130, where fkWorkPageID is a foreign key to tblWorkPage. So in much the same way the tblWorkProperty table keeps the history of properties values and tblProperty contains just a single record about given property – the value when created.2011-02-18T10:05:10.0000000Z

Blog post

How plugin settings are saved?To extend UI functionality you can use plugins. One of their marvelous feature is the ability to store data entered by admin or editor. As to myself I was in curiousity about where and how these data are saved.  So I’d like to save the values of two parameters somewhere in the button click handler:     protected void btnSave_Click(object sender, EventArgs e)          {              DataSet dataSet = new DataSet();              dataSet.Tables.Add(new DataTable());              dataSet.Tables[0].Columns.Add(new DataColumn ("Parameter1", typeof(string)));              dataSet.Tables[0].Columns.Add(new DataColumn("Parameter2", typeof(string)));              DataRow dataRow = dataSet.Tables[0].NewRow();              dataRow["Parameter1"] = HttpUtility.HtmlEncode(txtParameter1.Text);              dataRow["Parameter2"] = HttpUtility.HtmlEncode(txtParameter2.Text);              dataSet.Tables[0].Rows.Add(dataRow);              PlugInSettings.Save(typeof(CustomAdminPlugin), dataSet);          }   OK - With a help of .NET Reflector I dug into depth of PlugInSettings.Save(typeof(MyAdminPlugin), data) call.   It applies for PlugInDB in EPiServer.DataAccess namespace – namely to its SaveSettings function: public void SaveSettings(int plugin, string xml)     {       base.Execute(delegate {         IDbCommand command = this.CreateCommand("netPlugInSaveSettings");         command.Parameters.Add(this.CreateParameter("PlugInID", plugin));         command.Parameters.Add(this.CreateParameter("Settings", xml));         command.ExecuteNonQuery();       });     } In my case plugin is equal to 141 and xml is <NewDataSet>   <Table1>     <Parameter1>value 1</Parameter1>     <Parameter2>value 2</Parameter2>   </Table1> </NewDataSet> As you can see the working horse is the netPlugInSaveSettings stored procedure. Let’s look on it: ALTER PROCEDURE [dbo].[netPlugInSaveSettings] @PlugInID         INT, @Settings         NTEXT AS BEGIN         UPDATE tblPlugIn SET             Settings    = @Settings,             Saved       = GetDate()       WHERE pkID = @PlugInID END Conclusion : plugin’s settings are saved in tblPlugIn table , namely in xml field. This is in consistency with SDK which says “PlugInSettings is used to store plug-in settings and information in a DataSet, these will be persisted as xml together will the plug-in definition in the EpiServer database.”  2011-02-10T09:47:56.0000000Z

Blog post

Common properties amongst the pagesInstead of using a lot of dynamic properties one can create a special settings page. On this page all site-wide settings are saved all together. Then you make only the name of this page to be a dynamic property (ref. to <a href="http://www.meadow.se/wordpress/?cat=12">http://www.meadow.se/wordpress/?cat=12</a>). This is a common solution. However, code in the code-behind files becomes a little more complicated if you want to retrieve the settings from the settings page. For example: PropertyCriteriaCollection         propertyCriteriaCollection = new PropertyCriteriaCollection(); PropertyCriteria criteria = new PropertyCriteria(); criteria.Condition = CompareCondition.Equal; criteria.Name = "PageTypeID"; criteria.Type = PropertyDataType.PageType; criteria.Value = PageType.Load("SettingsPage").ID.ToString(); criteria.Required = true; propertyCriteriaCollection.Add(criteria); PageDataCollection pageDataCollection                 = DataFactory.Instance.FindPagesWithCriteria                     (PageReference.RootPage, propertyCriteriaCollection); if (pageDataCollection == null || pageDataCollection.Count == 0)                 return;                        if (pageDataCollection[0]["SomeProperty"] != null)                 TextBox1.Text =                        pageDataCollection[0] ["SomeProperty"].ToString();   You see how many actions should be performed with a single aim – to get the SettingsPage’s SomeProperty value. Evidently it’s tiresome and error prone. Instead you can force the page to load properties values from some other page. For this just open the Shortcut/External Link tab in edit mode, assign  “Fetch data from page in EPiServer CMS” to Link type , and choose the page the properties are loaded from (f.e. SettingsPage): <a href="/link/bb307e2264f0498e99d346a42ca50836.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="/link/a88159bb8ea8468faa0beed0602998fb.png" width="363" height="216" /></a> From this time you can apply to SettingsPage as if they belonged to the w1ef page: string someProperty = CurrentPage["SomeProperty"] as string; or: <EPiServer:Property PropertyName="SomeProperty" runat="server" />2011-02-08T14:20:38.0000000Z

Blog post