I have a page that inserts some predefined components in the placeholders, when user creat it (like gallery and header for example).
I also want web masters to give a freedom to insert other possible components to the placeholders around the predefined components, but I want to prohibit somehow to edit/delete the predefined components (gallery and header) from the page.
However, a content editor can add another gallery component (technically possible) to the same page, and delete it if he wants to. But predefined components should just not be touched (at least be removed from the placeholders. In other words - I don't want to have a delete button in the Experience editor next to the predefined components).
There is a way to fully prohibit editing the component rendering, but I still want web masters to insert components by themselves if they want. I just want them to do not modify the components that come when page is created.
As I understand this can be done somethere on the RenderingReference level, but I cannot figure it out how. Could you give a tip please?
Okay, I have found a way to do this.
Just in case if somebody will need it.
First, we need to create a Processor to catche page renderings in the Experience Editor.
public class CheckLockedComponentsHandler : GetClientActionsChromeData
{
public new void Process(GetChromeDataArgs args)
{
if (args.ChromeType == "rendering")
{
if (args.CustomData["renderingReference"] is RenderingReference rf && !string.IsNullOrEmpty(rf.Settings.Parameters))
{
var rmParams = WebUtil.ParseUrlParameters(rf.Settings.Parameters);
args.ChromeData.Custom["editable"] = string.IsNullOrEmpty(rmParams["editable"]) ? "true" : rmParams["editable"];
}
}
}
}
When, we add a property editable = false when creating a locked component.
And finally we need to register our processor in the configuration
<pipelines>
<getChromeData>
<processor type="CheckLockedComponentsHandler,MyLib" patch:after="*[last()]"/>
</processor>
<getChromeData>
</pipelines>
Related
I am using APEX 20.2.0.00.20. apex.region(region_static_id).widget() method should return a jQuery object according to the documentation. I am trying to figure out how to know what the object's properties and methods are, especially when they are not mentioned in the documentation. I tried running apex.region(calendar_region_static_id).widget() to return the object and inspect what properties and methods it has but I got S.fn.init [div#CAL_calendar.fc.ui-widget.fc-ltr, prevObject: S.fn.init(1)] 0: div#CAL_calendar.fc.ui-widget.fc-ltr length: 1 prevObject: S.fn.init [document] __proto__: Object(0)
I did not get the object. I do not know what s.fn.init or the rest of the returned code is?!
I see code like apex.region("calendar_static_id").widget().fullCalendar("getView"), so I assumed I should have gotten the jQuery object which has the "fullCalendar" method and more when I ran apex.region(calendar_region_static_id).widget(), but I have not.
Is this not the right way to inspect a jQuery object's properties and methods?
APEX integrates the FullCalendar widget, but it doesn't duplicate its documentation. Have a look here for a list of the FullCalendar methods and options.
In general, most (interactive) APEX regions are implemented as jQuery UI widgets. That means you can use them like this:
$('selector').widgetName('methodName'); //invokes said method
$('selector').widgetName('methodName', 'param1'); //invokes said method with a parameter
$('selector').widgetName('option', 'optionName'); //gets a specific option
$('selector').widgetName('option', 'optionName', 'newVal'); //sets a specific option
What's more, you can inspect all available options by running:
$('selector').widgetName('option');
And even have a look at the internal object, see all methods, public and otherwise, via:
$('selector').widgetName('instance');
Moreover, via its region interface, APEX offers an even easier way to reach those methods and options, even without having to know a region's widgetName:
// this
$('widgetSelector', 'staticId').widgetName('methodName');
// is equivalent to
apex.region('staticId').widget().widgetName('methodName');
// is quivalent to
apex.region('staticId').call('methodName');
The last way is the shortest and doesn't require knowing the real widget's id or widget name.
All of this helps when dealing with regular APEX widgets, such as the Interactive Grid.
apex.region('emp').call('instance'); //inspects all methods
apex.region('emp').call('option'); //inspects all options
This however does not work on the FullCalendar region, for reasons that are beyond me. It should help you navigate all other APEX regions, but for the FullCalendar you'll have to resort to their API docs.
Hope this helps a bit.
(I'm using Sitecore 8.1 Update 3 with Glass Mapper.Sc version 4.1.1.66)
I've run into an issue where some of the properties of a Sitecore item are not being populated in code through Glass Mapper. The values in our Content Base item (Id, Name, Display Name, typical Sitecore fields) seem to be getting populated correctly, but the child item's fields (I'll call it Overview) aren't mapped at all. They're all strings but they all end up null, even though the Content Base's values look to be correct. We also have child class maps working in other areas of the same, so that may not be the cause here.
Earlier in this project, we had an issue with Glass Mapper where field names that included spaces were not being read. However, I've made sure to leave out any spaces in field names, but this doesn't solve the issue.
Another possible contributor to the issue is that we have multiple languages on the site, so it's conceivable that language fallback may be complicating things. However, we have fallback enabled and working properly across the site without issues.
I can post code if needed, but for the most part, it's just POCO's and mapping classes.
Any ideas on what other parts I should be looking into?
You need to use the VersionCountDisabler(), you can find more details about it in this previous question and this blog post.
The use of the disabler is not supposed to be required on Sitecore 8.1 and when using Language Fallback, but I can confirm that this is an issue and using the VersionCountDisabler() solved the issue for us.
Internally Glass will check if a version of an item exists, if not it returns null. It seems that Sitecore will return a version count for Items with Layout, but not for datasource Items.
We have wired out the disabler slightly different than using the global.asax file, instead patching into the http request pipelines:
using Glass.Mapper.Sc;
using Sitecore.Pipelines.HttpRequest;
namespace MyProject.Custom.Pipelines.HttpRequest
{
public class ItemVersionCountDisablerBegin : HttpRequestProcessor
{
public override void Process(HttpRequestArgs args)
{
Sitecore.Context.Items["Glass::VersionCountDisabler"] = new VersionCountDisabler();
}
}
public class ItemVersionCountDisablerEnd : HttpRequestProcessor
{
public override void Process(HttpRequestArgs args)
{
VersionCountDisabler disabler = Sitecore.Context.Items["Glass::VersionCountDisabler"] as VersionCountDisabler;
Sitecore.Context.Items["Glass::VersionCountDisabler"] = null;
disabler?.Dispose();
}
}
}
And then patch this into http request begin and end pipelines:
<pipelines>
<httpRequestBegin>
<processor type="MyProject.Custom.Pipelines.HttpRequest.ItemVersionCountDisablerBegin, MyProject.Custom" patch:before="*[1]"/>
</httpRequestBegin>
<httpRequestEnd>
<processor type="MyProject.Custom.Pipelines.HttpRequest.ItemVersionCountDisablerEnd, MyProject.Custom" />
</httpRequestEnd>
</pipelines>
After some experimentation, I found the cause of the issue.
In my mapping class, you'll see this line:
config.Field(f => f.HeaderPrefix).FieldName("AssetOverviewContentHeaderPrefix");
The field name seems kinda long, right? We were prepending the category name onto the field name in order to avoid any duplicate names in items since we do a fair amount of inheritance.
That's where the problem lies. When I removed the "AssetOverviewContent" from the field names, everything worked fine. Based on this, I did some more experimentation.
I found that field names up to 23 characters long worked just fine. 24 or more and they won't map. I have no idea why this number in particular is the limit, but my guess is that there's some other mapping going on somewhere that's hitting a limit.
A little more experimentation also found that mapping using FieldId also doesn't work. Guids are going to be more than 23 characters long, so that makes some sense. However, you can't really do a guid in less than 23 characters so I can't confirm.
I may end up looking at the Glass Mapper code sometime soon to see if I can track down the answer. But now that I know there's a problem, I can avoid it.
This question already has answers here:
How to generate custom unique ID
(2 answers)
Closed 8 years ago.
I am working on sitecore multisites . I have multiple websites ex test1, test2, test3, test4. All are configured in webconfig. Means test1, test2 ,test3 and so on . So URL //test1 will always point to there local home folder which will be inside of test1/home.
But as per my requirement i have one global folder which are separate from all websites but pages inside of this will be common for all websites.
Ex:
sitecore/Root/Global/Category/A
sitecore/Root/test1
sitecore/Root/test2
sitecore/Root/test3
Now i am not able to get page A if i am in //test1 , and want to access page A and URL should be to //test1/Category/A.
Please help.
I'm not usually a fan of re-posting an exact answer that I posted previously, especially when I posted the original barely over a week ago, but the following is from this post.
Every page that is managed in Sitecore is a Sitecore Item. As such, you should be able to just navigate to the name of the player item. If you were trying to say in your post that category items are stored in globals and not as pages, then you are left with the following options:
Query String: test1/Category?categoryId={ID of Category}
If this is the route that you choose to take then I would suggest using the category item's Sitecore ID for the value of the query string parameter.
If you have other IDs then put the specified ID there, however it would be easiest with Sitecore IDs
What you would then do is get the item with the ID specified in the query string parameter (or get the item with the category ID specified in the query string parameter, depending on which route you take) and display the data for that category on the page
Sitecore.Context.Database.GetItem(Request.QueryString["categoryId"])
categoryItems.FirstOrDefault(categoryItem => categoryItem["Category ID"] == Request.QueryString["categoryId"])
Note that this assumes that the Category ID is a field, not the Sitecore ID
If it is the Sitecore ID then change the lambda to use categoryItem.ID == new ID(Request.QueryString["categoryId"]
Regardless of which one you use, I suggest adding null checks to the QueryString getter
Sublayout Parameters
If you use this method, the query string will not change and people will not be able to get to the page from the direct URL
The process is the same as for query strings, except that you are using Sublayout parameters instead
Note that you must set these in a parent sublayout or in Sitecore (which means that you have a separate page for each player - i.e. this would be a bad solution)
Virtual Items
This is really what I think you are looking for
This can be a lot of work if you do it from scratch, or you can use the Wildcard Module
If you do it from scratch, you will need a custom pipeline and/or processor for handling the requests
If the Wildcard Module isn't going to work, and if this is the case for all sites in your Sitecroe instance, you could write a custom item resolver and insert it in the httpBeginRequest pipeline right after the built in item resolver.
This is sort of from memory, but should get you started:
namespace Example
{
public class CategoryItemRewsolver : Sitecore.Pipelines.HttpRequest.HttpRequestProcessor
{
public override void Process(HttpRequestArgs args)
{
if (Sitecore.Context.Item != null) return; // Item has already been resolved
if (args.Context.Request.Path.StartsWith("Category"))
{
Sitecore.Context.Item = Sitecore.Context.Database.GetItem("sitecore/Root/Global" + args.Context.Request.Path);
}
}
}
}
You'll obviously want to replace paths with your own (And possibly allow them to be configured through the .config file).
Then patch this into the pipeline:
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<pipelines>
<httpRequestBegin>
<processor patch:after="*[#type='Sitecore.Pipelines.HttpRequest.ItemResolver, Sitecore.Kernel']" type="Example.CategoryItemResolver,Example" />
</httpRequestBegin>
</pipelines>
</sitecore>
</configuration>
I'm just starting out with ColdFusion OOP and I am wanting to make a DIV which shows different links to users depending on what page they are on and what login rights (role) they have. Basically a 'context' menu.
Should I put this toolbar/navigation DIV in a .cfm or .cfc file?
To reiterate; The cfm or cfc file needs to know what page the user is on and will also check what role they have. Depending on these two pieces of information it will display a set of links to the user. The role information comes from the database and stored in a SESSION variable, and to find out what page they are on I guess it could use #GetFileFromPath(GetBaseTemplatePath())#.
My first thought was to have a normal .cfm file, put all the presentation and logic in that file (the HTML and lots of <cfif> statements) to ensure the correct information is displayed in the DIV, and then use <cfinclude> to display it on the page. Then I started thinking maybe I should make a Custom Tag and ask the calling page to pass in the user's credentials and the #GetFileFromPath(GetBaseTemplatePath())# as arguments and then have that Custom Tag return all the presentational data.
Finally I guess a CFC could do the above as well, but I'd be breaking the 'rule' of having presentational and logic data in a CFC.
Any suggestions on the best practice to achieve what I'm trying to do? It will eventually serve thousands of customers so I need to make sure my solution is easy to scale.
Anything that outputs HTML to the screen should be in a .cfm file.
That being said, depending on your need, you could have methods in a CFC that generate HTML, but the method simply returns the HTML as a string.
In programming, there are very few absolutes, but here is one: You should NEVER directly output anything inside of a function or method by using output="true". Instead, whatever content is generated, it should be returned from the method.
If you will have a need to use this display element more than once, a custom tag might be the best way to go rather than an include.
I see security as being a combination of what menu items I can see and what pages can be ran.
The main security function is inside of the main session object
On the menus
I call a function called
if (session.objState.checkSecurity(Section, Item) == 1)
then ...
For page security
function setupRequest() {
...
if (session.objState.checkSecurity(getSection(), getItem()) == 0) {
location("#request.self#?message=LoginExpired", "no");
return;
}
...
}
The particulars of what checkSecurity can do varies from application to application, but it is tied into how FW/1 works. The following security variations exist:
session.objState.checkSecurity(getSection())
session.objState.checkSecurity(getSection(), getItem())
session.objState.checkSecurity(getSection(), getItem(), Identifier)
None of the presentation files know anything about security.
Rules by which I live:) :
No CF business logic in CFM files. Just use some service which will serve template and provide needed data.
navService = com.foobar.services.Navigation(form, url);
and later output #navService.GetNavConent()#
No direct output from CFC files, functions should always return content. For example, make one function which makes one link based on some logic, second which wraps that and returns to cfm template.
Also one more hint, avoid using application and session scopes in your services.
This makes refactoring, testing and debugging too difficult.
For session you can make session.currentUser , CurrentUser.cfc which provides all things you need. e.g. session.currentUser.isAuthorized("backend/administration") and if true, show link to backend/administration.
Same for application, if you need locale, applicaiton wide setting or some singleton, make application.applicationSettings, ApplicationSettings.cfc and use that to retrieve all info you need in cfc's.
These rules will make your application to be easier to test and debug, and really easy to migrate tomorrow on some javascript based UI like Angular or backbone.js since all th edata you need is already in CFC and theoretically you just need to put remote in CFC or make some remote facade in the middle and you're done.
Within an xslt render I call the following
<xsl:value-of select="di:inject()"/>
The corresponding class retrieves the current page object and attempts to modify the page header
public class XslHelper : Sitecore.Xml.Xsl.XslHelper
{
public void inject()
{
Page page = HttpContext.Current.Handler as Page;
// page.GetType().FullName tells me that I have successfully got the reference
page.Header.Controls.Add(new HtmlLink { Href = "/style.css" });
}
}
However the header does not get updated? Why is this and is there another way to achieve the same result?
EDIT: We ended up extending the XslRender template and storing dependencies there instead, which can then be picked up and added to the session by overriding the InsertRenderings class in the renderLayout pipeline. The session object can then be accessed on Page_Load in the layout, which can access the header of the page.
I suspect that it is too late to add anything to the head part when XSL rendering is being rendered. And also, the only option could be to switch to sublayout and do this in Page_Load or something.
Can't prove my answer - it's just a gut feeling. That's why +1 to the question and added to favorites ;-)
You'd probably be better off just having all your classes in a single static CSS file. The additional overhead of HTTP requests and CPU load makes it hard to justify the benefits gained from dynamically loading CSS.