I need to localize a bunch of content components for testing to prove the different sites I have created for each support language is pulling from the correct content.
I see Core services (CoreService2010Client) has a method Localize, but, in general, how do you use it? Specifically, I'm wonder if calling it just localizes the component and then I can modify the component? Do I still need to call CheckOut and CheckIn on the TCM Id of the language item?
public RepositoryLocalObjectData Localize(string id, ReadOptions readBackOptions)
Once I get all the components localized and acceptance testing passes, what is the easiest way to UN-Localize everything I did?
The id parameter stands for "The identifier of the item (TCM URI or WebDav URL)". This means that you are localizing the item in the context of the Publication you specified as part of that ID.
For unlocalizing you can use method RepositoryLocalObjectData UnLocalize(string id, ReadOptions2010 readBackOptions) on the same client interface ICoreService2010.
You can find the API docs on SdlTridionWorld.com (log in) -> Downloads -> Documentation -> SDL Tridion 2011 (or SDL Tridion 2011SP1).
Localizing an item has nothing to do with CheckIn CheckOut. Localizing will simply create a 'local copy' of that item, which later on you can choose to modify, save, etc, or unLocalize.
Related
I've to list, in specific folders or collections, objects expired also to anonymous users.
You know, portal_catalog returns only brains not expired. It's a useful behavior but not in this case...
To force the Catalog to return also expired contents, we've to pass a specific parameter: show_inactive.
Browsing the folder_listing (&family) code I noticed that it's possible to pass, via request, optionals parameters (contentFilter) to the query/getFolderContents. It's a nice feature to customize the query avoiding the creation of very similar listing templates.
I suppose it's necessary to create a marker interface to mark context (folders or collection) where I want to list also expired contents. For ex. IListExpired.
I imagine to ways:
1) to make a subscriber that intercepts before_traverse and , in the handler, a test to verify if the context implements the IListExpired. In positive case I made a
request.set('folderListing', {'show_inactive':True})
2) to make a viewlet for the IListExpired that in the call set
request.set('folderListing', {'show_inactive':True})
What's the best way? I suppose the first one could be an unnecessary overhead.
Vito
AFAIK, these are two separate thing: folderListing uses a method available to all CMF-based Folderish content types; show_inactive is an option of the Plone catalog, so you're not going to make it work as you're planning.
I think you should override these views and rewrite the listing using a catalog call.
you better use a browser layer for you package to do so or, a marker interface as you're planning.
I have some pages created in a structure group in one publication.
I want to unpublish all those published pages using core services.
Can anyone help me out?
You can use the .UnPublish method of the CoreService client, passing it the URI of the StructureGroup you wish to unpublish the Pages from. This is what the CoreService API reference (well worth a read...) says:
Un-publishes the collection of IdentifiableObjectData instances from
given target(s).
IEnumerable<PublishTransactionData> UnPublish(
IEnumerable<string> ids,
UnPublishInstructionData unPublishInstruction,
IEnumerable<string> targets,
Nullable<PublishPriority> priority,
ReadOptions readOptions
)
Parameters
ids
Type: System.Collections.Generic.IEnumerable<String>
Collection of identifiers of the items to unpublish (TCM URI or WebDav URL).
unPublishInstruction
Type: Tridion.ContentManager.Data.Publishing.UnPublishInstructionData
The instruction for the un-publish action.
targets
Type: System.Collections.Generic.IEnumerable<String>
A collection of target identifiers representing Publication Targets or Target Types to un-publish from. This cannot contain a combination of both.
priority
Type: System.Nullable<PublishPriority>
The priority of the un-publish action. Passing null will use the priority from the Publication Target.
readOptions
Type: Tridion.ContentManager.CoreService.ReadOptions
Specifies how the Publish Transaction(s) are read back after un-publishing. If the parameter is null, the items are read with None.
Return Value
A collection of PublishTransactionData
I don't have a copy/paste snippet for you, but it should not be very difficult given Jeremy's excerpt from the API documentation of the relevant method and these example that publish items:
http://blog.building-blocks.com/publishing-components-using-the-core-service-in-sdl-tridion-2011
http://blog.building-blocks.com/sdl-tridion-2011-component-publisher
Unable to get Core Service client working
Keep in mind that Stack Overflow works best if you first do some of the work yourself and then show us where you're stuck.
Can we have different publication targets on the basis of structure groups, so if we have two structure groups in my publication [07 Global English] as below:
1) My Website
2) My Mobile
So whenever user tries to publish the pages/structure group from "My Website" he can see the publication target "Webiste LIVE" and " Website Staging", however same user if he tries to publish from "My Mobile" structure group he will not see the above publication targets instead he will get "Mobile - LIVE" and "Mobile - Staging".
Please suggest if above scenario is possible
Thanks.
Best Regards,
MS
I would strongly advice to create a sibling Publication for the Mobile website, next to the default website. Then you don't need to imitate functionality from the content manager, and in particular blueprinting that's standard out of the box.
I concur with Arjen on this one, the scenario you describe should be solved with a separate Publication and BluePrinting rather than trying to hack the Publishing Security model and make it apply to Structure groups instead of Publications (as it is designed).
But next to Rob's answer on trying a UI extension which would hide the non relevant targets based on the Structure Group, I think the only other option is to write a custom resolver which would remove the items from the Publish Transaction.
Now if memory serves me right a custom resolver was already possible in SDL Tridion 2009, but for safety reasons I will indicate this solution for SDL Tridion 2011 only (that I know is working).
A custom Resolver is a class which implements the IResolver interface through a Resolve() method, some example code of a resolver which removes items will be like:
public void Resolve(IdentifiableObject item, ResolveInstruction instruction, PublishContext context, Tridion.Collections.ISet<ResolvedItem> resolvedItems)
{
List<ResolvedItem> itemsToRemove = new List<ResolvedItem>();
foreach (ResolvedItem resolvedItem in resolvedItems)
{
// check if resolved item belongs here
if (MyResolvedItemCheck(resolvedItem.Item.Id))
{
itemsToRemove.Add(resolvedItem);
}
}
// remove all items that we need to discard
foreach (ResolvedItem itemToRemove in itemsToRemove)
{
resolvedItems.Remove(itemToRemove);
}
}
Please note that even though the resolver code is probably easier to write and less expensive than a UI extension is, I still think it is going to be more costly than using Publications and BluePrinting (even if your current SDL Tridion license contains a Blueprint limit which you have reached). You will have to do quite some coding in the MyResolvedItemCheck() method and depending on which targets are chosen by the publisher, you might end up with empty Publish Transactions and unclarity for the Editors this way.
I believe you can only set Publication Targets on a Publication (someone with more experience than me may say otherwise).
However, you may be able to add all 4 targets to the publication and write an extension which hides targets based on whether the TCM ID of the parent Structure Group matches a configured ID for mobile / website. This would be a hack though and I wouldn't recommend it.
I wanted to create a blank Component in SDL Tridion 2011 using the Core Service. The only information I have at the start of the process is the Schema URI. The Schema may contain any kind of field (text, rtf, number date, embedded etc), some of which may be mandatory.
I understand that for the mandatory fields, I will need to save some dummy value in them, and this is acceptable as they will be changed manually later.
How can i achieve this?
First - you make sure all fields are set to optional in the schema, otherwise this will never work.
Second - You save.
When an optional field has no value, it will have no XML representation. If you have a schema that defines a component like this:
Field1
Field2
Field3
When all fields are optional and you save a value in Field 2, Tridion will store the following:
<Content xmlns="yourNamespace"><Field2>SomeValue</Field2></Content>
If one of your fields is not mandatory, then you'll have to provide a value. If you're using the CoreService then you can use ReadSchemaFields class to get the fields and some information about them - what type, mandatory/optional, etc.
Looking at your question/requirement to understand what you're exactly looking for, so we can answer the best possible and relevant.
Are you asking for "How can you write a generic code for component creation using core service?" instead of creating a component with a specific schema knowing all the fields upfront.
If that is what you are looking for, here is what you need to do:
You need to read the schema fields with CoreService (since you know the schema URI)
Now you know what type of fields (embedded/component link etc) you need to create content for
use the links pointed by "Puf" in his answer.
Please note that, if the field is marked as required in Tridion Schema you must have to fill a value and it has to match the field type defined in schema.
Reading schema fields via Core Service sample code can be found here
Updating a Component's field through the Core Service is already answered here: Updating Components using the Core Service in SDL Tridion 2011
That post points to a helper class you can find here: Updating Components using the Core Service in SDL Tridion 2011
If those don't help you in creating a Component, I suggest you post your code instead of asking us to write it for you.
We ask about use case, because code to fill in specific fields for a specific schema only works in one environment. Code that can automatically determine fields is re-usable.
If the use case is for an Tridion setup that has Inline Editing (Experience Manager or SiteEdit), then the correct approach is content/component types. These define a reference component with "junk defaults," instructions to the author, and even save location context.
If the use case is to allow authors the ability to create dummy components, this is out-of-the box with:
CTRL+C
CTRL+V
One-time setup required to create a "reference component." Of course we can mimic this behavior (in case "Copy of Untitled" isn't an appropriate name) by copying items with the core service.
In that case, I'll also do a copy--see a general solution for creating Tridion items using the Core Service.
Fields that require a default can have an actual default in the schema.
"Junk values" don't help authors much, always consider good defaults such as an appropriate selection or instructions in the case of fields (maybe). A 10 second change costs development practically nothing, but impacts all future components and the authors that create them.
The Nlog has some ASP.NET logging features (see the list of layout renderers), for example
${aspnet-request}
For log form item, I need to know name of item.
${aspnet-request:form=myVariable}
But how to log all from items, which hames in unknown?
For example
${aspnet-request:form}
I'd write my own LayoutRenderer, myself (in fact, just did something nearly identical, recently) - one of the best parts about NLog is how extensible the framework is. Depending on how you're doing configuration will determine how you reference/load your custom layoutrenderer, but the sky is really the limit in terms of what you can do.
Off the top of my head, you could take one of two approaches with a custom renderer: wrap/extend the existing asp request renderer and just proxy all calls, or get a hook to the request object the same way the nlog one does (which is tricky; it calls out to grab the COM instance, if memory serves).
The approach I took was to embed the NameValueCollection in the outgoing LogEventInfo object itself (in the properties dictionary), then use a custom layout renderer to extract that collection and render it.