I need to create nodes with bilingual properties, and use all of these nodes as (List constraints) where node property will be label and another property will be value.
So, is this doable ? & how ?
I see sys:localized, and its mean
Localization:
If you add this aspect to a node, then the server will assume that all non-multilingual
properties apply to this locale.
can this help me !
Thanks
Mohammed Amr
Senior System Developer
In order to handle Multi Lingual documents from your code you are supposed to use the MultilingualContentService to:
add a translation
retrieve the available translations
etc.
Multilingual documents have the cm:mlDocument aspect applied. This enables them to be listed as children of the special cm:mlContainer that's created under /cm:multilingualRoot to track translations of a single document. The cm:mlContainer is defined as follows:
<type name="cm:mlContainer">
<title>Multilingual Container</title>
<parent>sys:container</parent>
<associations>
<child-association name="cm:mlChild">
<source>
<mandatory>false</mandatory>
<many>false</many>
</source>
<target>
<class>cm:mlDocument</class>
<mandatory>true</mandatory>
<many>true</many>
</target>
</child-association>
</associations>
<mandatory-aspects>
<aspect>cm:versionable</aspect>
<aspect>cm:author</aspect>
<aspect>sys:localized</aspect>
</mandatory-aspects>
</type>
There are different kinds of localization options in Alfresco:
The MultilingualContentService (with the cm:mlDocument aspect) allows you to store translated content on a single node. You can use this if you have a document that is translated into multiple languages. There is no support for this in Share but you can use it via the Alfresco Explorer or the API.
There are also multilingual text properties. You can use the datatype d:mlText in your content model and to store property values (strings only) based on the user language. The build in properties cm:title and cm:description are of type d:mlText. The usage in Share is a bit tricky though - Alfresco uses the browser language to automatically choose the locale, so users with different browser languages will see different values.
As far as I understand your question, I think what you need are the ml:properties. The Share UI only supports them indirectly, maybe that's ok for you. As for the the List constraints I have not seen any multi language support there, so you probably have to extend those yourself.
Related
I need to enabled files with same name in same folder in Alfresco.
I try to create custom association, but I can't see the files in Share (bellow you can see my custom type code).
I can solve this changing the properties duplicate for true on contentModel.xml, but this type of global change is not recommended.
Any idea when I can enable duplicate files in Alfresco? Is correct create another type and define custom association for this OR do I really have to change the global file in contentModel.xml?
<type name="acme:project">
<title>Project folder</title>
<parent>cm:folder</parent>
<associations>
<child-association name="acme:contains">
<source>
<mandatory>false</mandatory>
<many>true</many>
</source>
<target>
<class>acme:document</class>
<mandatory>false</mandatory>
<many>true</many>
</target>
<duplicate>true</duplicate>
<propagateTimestamps>false</propagateTimestamps>
</child-association>
</associations>
</type>
*PS: Sorry for my English.
You can't configure this. Uniqueness on the filename in a directory is also enforced by a unique constraint directly in the database. You would break a lot of funktionallity if you change that. Alfresco implements the fileserver concepts and a fileserver only supports one file with the same path. Use your custom property instead.
I don't have your use case, so my proposition may be unsatisfying, but :
if you want to see your document in Share, it might be possible to custom your share interface to show another property than the document name, a property on which you can have the same value for nodes in the same folder.
Another proposition would be to categorise your documents and use the classification plan you made (with hierarchical categories instead of folder organisation) to access to your documents.
In Alfresco, if a type name is removed/changed all nodes of that type will disappears but still exists.
Using alfresco 5.0.c I've added some custom types:
eg:
<type name="my:test">
<title>Test folder</title>
<parent>cm:folder</parent>
</type>
now i deploy it and create a folder of this type (a simple folder, then change type)
Now i edit the type like this:
<type name="my:test2"> <!-- from my:test to my:test2 -->
<title>Test folder</title>
<parent>cm:folder</parent>
</type>
Deploying this: any "my:test" folder will disappear, but, if I try to create another folder with the same name I get an error becouse the node still exists.
These nodes will not be not even listed within the folder child:
print(document.getChildren());
How can I recover (if possible using the the javascript console) all the "broken" nodes and be able to change the type?
A little preface: as widely stated by Alfresco, if you want to change your custom content model you should change it only incrementally.
This means that you can't remove any properties, types or aspect at definition level of the model, you only can add new definitions in the content model of Alfresco.
So it is a very bad practice to change types "on the fly".
A good practice is to always start with a model as small as you can and then add features as long as you need them.
In your case you should have deleted all nodes referencing my:test type BEFORE changing the model and then safely remove it and finally you should have performed a full reindex. This could be the reason why the repository tells you that the folder exists even if you cannot see it anymore.
As far as I know it is not possible to delete this inconsistent nodes through the console, so my advice is to perform a full reindex. If the issues come up again then you should consider to start again from scratch.
Another approach next time is to add the new type and programmatically hide the older one.
This question is a reformulation of this question which had evolved in a confusing way. Please refer to this question if you search some in depth details or are interested in workarounds and alternative solutions.
This question is about the call to template folder_full_view_item.pt in folder_full_view.pt, not about other templates in general!
Please avoid workarounds like skin layers, editskinswitcher, etc. I don't want to solve a particular use case here. What I want is to really understand how this actually works.
I present this question in three parts: scenario, result, questions.
scenario
Have a Folder with a Document. The layout of the Folder is folder_full_view. The layout of the Document is document_view:
Folder (layout=folder_full_view)
Document (layout=document_view)
The template folder_full_view.pt calls template folder_full_view_item.pt via item.getObject().folder_full_view_item().
folder_full_view_item.pt calls (e.g. for a Document content type ) the template document_view.pt via use-macro="item_macro" (item_macro being something like here/document_view/macros/content-core). Schematically as follows:
folder_full_view.pt :: item.getObject().folder_full_view_item()
folder_full_view_item.pt :: use-macro="here/document_view/macros/content-core"
document_view.pt
In a plone3_theme have overriden versions of the templates folder_full_view.pt, folder_full_view_item.pt, and document_view.pt. These templates are registered as follows in configure.zcml.
<browser:page
for="*"
name="folder_full_view_item"
template="folder_full_view_item.pt"
layer="example.theme.browser.interfaces.IThemeSpecific"
permission="zope2.View"
/>
<browser:page
for="Products.ATContentTypes.content.folder.ATFolder"
name="folder_full_view"
template="folder_full_view.pt"
layer="example.theme.browser.interfaces.IThemeSpecific"
permission="zope2.View"
/>
<browser:page
for="Products.ATContentTypes.content.document.ATDocument"
name="document_view"
template="document_view.pt"
layer="example.theme.browser.interfaces.IThemeSpecific"
permission="zope2.View"
/>
results
With the theme installed the results are:
Document and Folder get their templates (I guess) via traversal. The (sub)templates though don't go through the traversal.
Folder: uses overriden folder_full_view.pt, original folder_full_view_item.pt, and original document_view.pt
Document: uses overriden document_view.pt
questions
is it the case that item.getObject().folder_full_view_item() doesn't go through traversal? If yes why?
what can be modified (in folder_full_view.pt!) to force a traversal to the overriden folder_full_view_item.pt(!) and subsequently to the overriden document_view.pt? Is this possible?
Again, please avoid workarounds like skin layers, editskinswitcher, etc. I don't want to solve a particular use case here. What I want is to really understand how this actually works.
I am trying to configure cd_storage and getting issue in setting up dynamic component presentation as they get over written by child and published to same folder from every publication.
I know we can define the publication level settings but once we define that then it expect us to define everything inside that publication tag. We do not want to define every thing 50 times in publication tag.
Could any one suggest the best practice for same.
this is for sdl tridion 2011 sp1
Thanks in advance...
Your problem is in how you defined your storage configuration for the storage which you use to store ComponentPresentations. There is a flag in the definition of a storage which sets exactly this type of behavior: defaultFilesystem. You probably have it set to false which causes all ComponentPresentations from all publications to be stored in the same location. By setting this flag to true you will get ComponentPresentations from different publications stored in different locations. I will give an example to show how this works in cd_storage_conf.xml:
<Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" Id="defaultCPs" defaultFilesystem="true">
<Root Path="c:\temp\cpRoot" />
</Storage>
....
<ItemTypes defaultStorageId="defaultFile" cached="true">
<Item typeMapping="ComponentPresentation" itemExtension=".jsp" storageId="defaultCPs"/>
....
This is really easy to maintain and will make the Broker to store ComponentPresentations to locations like: c:\temp\cpRoot\pub109\dcp\jsp\*** (here I have publicationId=109).
Hope this helps.
I'm researching options to synchronize external data to a Category and Keyword list.
I have a metadata field with a states field that uses a category called US States.
When I preview my component with a simple XSLT component template (<xsl:copy-of select="." />), I can see:
<tcm:Content>
...
</tcm:Content>
<tcm:Metadata><Metadata xmlns="http://createandbreak.net/schema/generic">
<states>California</states>
<states>New York</states>
</Metadata></tcm:Metadata>
When I update the keyword and preview, I can see updated values.
<tcm:Content>
...
</tcm:Content>
<tcm:Metadata><Metadata xmlns="http://createandbreak.net/schema/generic">
<states>Californias</states>
<states>New York</states>
</Metadata></tcm:Metadata>
Which is great. It looks like we do not need to synchronize components (open, edit, and save) to use updated keywords. Is that a safe assumption?
If I update a keyword, do I need to update components that use it in order to publish component presentations with the updated values?
Do I need to also be careful when moving components with content porter?
No, you don't need to do anything manually for those Keyword fields to be "Content Porter"-safe. Tridion stores the link from your Keyword field to the Keyword definition (in the category) as a so-called managed link (a TCM URI).
The reason you don't see this value in your XSLT has to do with the way Tridion traditionally exposes the Keywords in WebDAV: it hides the TCM URIs there and instead just exposes the value of the selected keyword. Since Keyword values must be unique within their category, this will always allow you to look up the correct TCM URI if needed.
But when exporting (and in general when you're using the API to access content) you should retrieve the Component XML with the TCM URIs in place. Check the API documentation for your programming language to see which Filter/ReadOption you need to specify for that.