Duplicity restriction for component availability - magnolia

Within an area in Magnolia template, we could create 2 components. We should restrict the user in a way that they don't create duplicate components. Can we achieve this through configurations or this requires a custom property created? Any pointers would be of great help!
areas:
myArea:
availableComponents:
maxComponents: 2
renderType: freemarker
type: list
Component1:
id:
Component2:
id:
When we have created content with component1 then it shouldn't be available for selection later.

You have already limited number of components to 2. What you can do extra is to autogenerate each of the components at area creation time and mark them as not delete-able so that editors can't remove them and can't add more of the same (due to maxComponents restriction either). This effectively limits everyone to use of max 1 component of given type, but also forces exactly 1 component of given type.
If you want anything more sophisticated, you need to code it yourself.

Related

How to restrict/customize the Resource Group Region in ARM templates

When we deploy a Custom template in Azure then a few parameters like Resource Group and Region are automatically popped up in the Azure portal (see the attached screenshot). I want to know how can we customize or restrict the list of regions using ARM templates.
Edit
The first "region" dropdown is for the resourceGroup's location - it's required when creating a new one, disabled when using an existing one. For a custom template, you cannot customize or remove that control unless you provide your own ui definition file.
That said, there's also nothing that requires you to use the value from that control in your deployment. If you want to use that value you'd reference it using resourceGroup().location in your template. That would allow you to remove the "duplicate" but also requires that the resources are deployed to the same region as the resourceGroup.
For your own "region" control, you can use the allowedValues property on the parameter in the template and that will restrict the items in the list to what you provide - that's the link that Jim provided in the comment above.
If you supply your own ui definition file there are more things you can do to restrict the list, but requires you to write a bit more code. This would be the starting point:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/create-uidefinition-overview
The docs talk about managedApplications, but the ui is a generic construct that you can use for template deployments, here's a generic example:
https://github.com/Azure/azure-quickstart-templates/tree/master/100-marketplace-sample
[edits post comment]
If you want to leverage the "built-in" region control you can customize the list of locations that appear there by setting the config in the createUiDefintion.json file. More on that here:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/create-uidefinition-overview#config

Listenerconfigurations in the observation module of magnolia - best practices question

I would like to trigger a custom command that extends BaseRepositoryCommand when someone adds, removes or changes a node or property for mgnl:page, mgnl:area and mgnl:component node types.
I was thinking of using the magnolia observation module for this. Do I have to create separate listenerConfigurations for each node type and event type? In my case it would be 6 event-types for 3 node-types or 18 different
listenerConfigurations. Does that have implications on performance?
Please have a look at: info.magnolia.cms.util.WorkspaceObservingManager
There you can use the method #registerChangeListener which you can specify the workspace you want to observe as well as the list of node types you wish.
Performance-wise, it should be smooth since it uses directly JCR observation mechanism under its hood.

Tridion 2011 with DD4T - no MetaData fields available on Component entity

I'm using Tridion 2011 (with DD4T, feeding an MVC webapp).
It seems that MetaData fields for Multimedia Components (specified on the Metadata tab of my Images Schema in Tridion) are not populating the corresponding property on the DD4T "Component" object. e.g. LinkedComponentFields[0].MetadataFields is empty and Multimedia.AltText is null.
Specifically the field I'm after is the AltText. But as the entire MetadataFields collection is empty on the Component, it's obviously not pulling through any metadata properties. i have tried using TemplateBuilder to set parameters in the Component Template (I set "resolve width and height" to yes, and the MergeAction to Merge) - this did not help.
Any ideas?
It is possibly caused by the linklevel. By default, links are followed for one level from the page or component that you are publishing.
You can increase this by adding a parameter to the template invocation, called linklevel. Try it with a value of 2 first, then increase until it works.

Creating blank dummy Components which contain mandatory Fields with the SDL Tridion 2011 Core Service

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.

FLEX: How can I share components IDs through modules?

Are IDs attributes shared between different modules in Flex ?
i.e. I have a text area with id="text1" in my menu.mxml file.
And I want to write on it from another module mainArea.mxml
The debug gives me error, so how can I share different components ?
thanks
I'd suggest you create a central model object that contains the text instead of trying to access elements by ID. If you access elements by ID -- and I'm not sure if this works cross-module -- you tightly couple your code as opposed to having a central model that takes care of that. Then the calling code does not need to know about the text area or label or whatever you happen to bind to it.

Resources