Hey,
i’m glad to say that I got picked to participate at the Crestone beta program. Unfortunately we are not allowed to publish any information about Crestone, but I will try to get some facts and post them on my blog. I’m looking forward to get some really nice new and cool features developed by Lars and his gang 
(maybe that’s the point to go 
)…
so stay tuned .. cheers chris
Hey folks,
some guys want to use .html extensions instead of .aspx extensions; maybe it’s better for search engines, but that will be always a miracle.
For incoming requests we use ISAPI_Rewrite with a regular expression. And in fact of that we don’t want to replace all sc:link / sc:path functions in the renderings I overwrite the XslHelper function. A very tricky thing is the <sc:link /> method, which only converts the request to a xsl:value-of select and pass it to sc:StartLink().
Here we go:
You have to create a new class and inherit it by the sitecore’s XslHelper:
public class ScXslHelper : Sitecore.Xml.Xsl.XslHelper
You have to override three methods:
public override string path(System.Xml.XPath.XPathNodeIterator iterator)
{
string path = base.path(iterator);
string newPath = path.Replace(“.aspx”, “.html”);
return newPath;
}
public override string link(string fieldName, System.Xml.XPath.XPathNodeIterator iterator, string parameters)
{
string path = base.link(fieldName, iterator, parameters);
string newPath = path.Replace(“.aspx”, “.html”);
return newPath;
}
public override string StartLink(System.Xml.XPath.XPathNodeIterator iterator, string parameters)
{
string path = base.StartLink(iterator, parameters);
string newPath = path.Replace(“.aspx”, “.html”);
return newPath;
}
This solution is just basic, and should demonstrate the way you have to go. There is just one more function where you can generate a link and that is item.Paths.GetFriendlyUrl(), I suggest you should create a new class which extends the Sitecore.Data.ItemPath class.
Happy coding cheers chris
//update:
I forgot to mention that you have to change the web.config entry for the helper under the xslExtension node:
<extension mode=”on” type=”Sitecore.Xml.Xsl.XslHelper, Sitecore.Kernel” namespace=”http://www.sitecore.net/sc” singleInstance=”true”></extension>
to your class name and your assembly name. Leave the namespace the same.
Hey,
I got some free time and want to catch up with everything I could not effort in my last weeks, so here we go. I talked to Jimmie Overby, he’s the Shared Source Coordinator at Sitecore and I want to publish my Placeholder Dropdown Solution for every sitecore developer and not only at my blog.
Well, I finished it and got a solution for getting all placeholder in the current layout and all already definied sublayouts.
The next step is to write the wiki, and create a enviroment where anybody can step in and help to develop some cool features for the dropdown. So I will finish it in the next days hopefully, and if you want to participate, just write me a message. Come back in the next days and I will inform you about a URL to the sources and a package for installing it on your system.
Thanks to Jimmie Overby at this point, and if you have a cool sitecore application, just write him a message or read the SDN post about shared source.
Hey guys,
a current project reminds me of one post in 2007 at the Sitecore developer network.
If you want to restrict access to one particular field for a special template you have to use the “Field Security” field at the template. The explanation comes from Kerry Bellerose:
The difference in setting field security from item security reflects the fact that field security is actually different from item security.
In general, users who are given read/write access to an item, automatically have read/write access to all the fields in that item.
This covers the great majority of items and fields, so it’s nice that things work this way.
On the other hand, when business rules suggest that only a limited set of people who have read/write access to an item should also have read/write access to a given field, Sitecore’s approach is designed to limit the number of security configuration changes required.
For example, lets say we have a field called Foo that Authors should not even see (even if they have read/write access to an item), the Sales People should see, but should not be change, and that Managers should be able to see and change.
When we define the field Foo, the field inherits the Read / Write access rights assigned to the user, be it Author, Sales Person, or Manager.
When we begin assigning field security to Foo for any role, however, this breaks the inheritance of access rights from item to field. In other words, as soon as we assign field security to Foo for any given users or roles, read and write access defaults to denied for all other users and roles.
This may seem complex until you understand it, but you do understand it you can see that the following is true:
Generally you can ignore field security and focus on item security (assuming that having access to an item also gives the same access to fields).
When a limited group of users/roles should have access to a specific field, you only need to grant access to those users/roles, you never need to deny read/write access to a field (because as soon as you explicitly Allow access for anyone, everyone else defaults to Denied access).
So in our example above, to meet our business requirements, we would do the following:Allow Read access on Foo for Sales People
Allow Read and Write access on Foo to Managers
This would implicitly deny read and write access to authors and deny write access to Sales People.
I just want to remind you of that fact, because a bunch of new sitecore developers joined the sitecore world, and I stepped over this problem yesterday. Maybe good to know. cheers