Alfresco offers both dynamic and static deployment of custom content model [1]. However, it is still not very clear to me why would one renounce to the dynamic deploy advantages.
When should one go with bootstrap deployment? What are functional differences between the two?
[1] http://docs.alfresco.com/5.0/concepts/content-model-deploy.html
Both approaches have it's pros and cons.
In case of dynamic deployment your model is stranded away from all
other customization related code. So, whenever you deploy all your
customization on particular instance you will not be able to include
them in your amp file.
In case of bootstrap deployment if you have any syntactical error in
model you will get to know during bootstrap with information on
possible cause of issue. So, it's easier to rectify.
Dynamic deployment seems to be better suited for your development environment if you want to quickly implement your model and check changes.
As stated in the Alfresco documentation:
There are restrictions on what changes you can make to a content model XML file and when you can delete a content model XML file. Only incremental additions are allowed; i.e., changes that do not require modifications to existing data in the content repository, or do not modify existing definitions and their properties. You can delete the content model only if it is not used by any data in the content repository.
I do not think that dynamic deployment is a good option during development because you will likely need to modify your content model often with changes that are not incremental (such as removing a property). There are steps that you can follow to remove a property from a model dynamically loaded, but they will be much slower and error prone than a restart.
Dynamic deployment is good only in some particular use cases (for example if you need to add a new content type on the fly).
To test that a content model is well formed, you do not need to deploy it. Instead, use the "TestModel" class as described in
https://forums.alfresco.com/forum/developer-discussions/development-environment/orgalfrescorepodictionarytestmodel-11172011-2133
and in many other forum posts
Related
I have an application build with Symfony 3.3 and Twig that will be distributed to more customers. I'm using parameters.yml to customize its behavior and it seems to work well.
Where I have an issue is with twig templates: although the customers will use most of the templates as they are, they'll need to customize some parts like CSS styles, general layout and do occasional design overrides.
The options I have identified are:
Have a full set of templates for each customer. The issue is that the upgrades will be a nightmare as we have to patch each template and account for differences
Customize templates via YML files. The problem is that it gets too complicated soon and the number of parameters is potentially huge
Deliver a set of templates in app/Resources/views and allow the customer to override any of the templates by creating another file with the same name in another folder
Deliver a set of templates in AppBundle/Resources/views and let customers override them in app/Resources/views
Create the application as a Symfony bundle (ie. MyAppBundle) and deploy the application to each customer by including the MyAppBundle via composer. I like this solution a lot, but I do not know whether it is possible to implement is easily.
Do you have any suggestion on how to approach this problem?
I think the best way in your case is to think about the main parts and the customer parts and then build blocks and overwrite all parts that are relevant for the customer for example the CSS or anything else. If you know that there are special part you can build macros for example.
With the Block concept you can predefine the template but the customer has the ability to overwrite that part you've defined with it's own.
With Twig you have a lot of possibilities to solve such a problem.
Drupal 8 use that Theming concept.
https://www.chapterthree.com/blog/twig-concepts-drupal-8-themes-part-ii
Perhaps you can take a look how they have solved that and you can find a good solution for your problem.
I'm working on a small team of around 10 developers, all using Rhapsody. We've recently noticed source artifacts in some of our classes, which aren't visible in the browser by default. They usually only change the ordering in generated sources, but some override changes to the model. In some cases we've lost time debugging new changes that didn't seem to work, only to discover the changes were being replaced by an implementation in the source artifacts.
Is there a way to disable or avoid generating source artifacts in Rhapsody?
I've seen them generated when saving with the active code view focused, but there may be other ways our team is inadvertently creating them. I checked SO to see if anyone else had a similar issue, and IBM's documentation didn't mention anything about disabling them or what actions implicitly create them. We're using Rhapsody 8.1.2.
The Source Artifacts in Rhapsody are created to preserve data from the code which is not mapped to UML model element. Such as ordering as you have mentioned, and more.
In case that you do all your changes from model, and not from code, you can disable the update of the model from code. In the Code menu, select Dynamic Model Code Associativity and then Code Generation. So Roundtrip will not run and update your model with changes from the code. Unless you run it manually from menu.
In case that you do want to update the model with changes from code, but less then the default. You can change the Roundtrip scheme from Respect to Advanced. This will allow you to add/change code elements in the code, but not to; change order, add global comments or pre-processor directives.
There is also Basic scheme which allow you to only modify functions body.
See the property [C/Cpp]_Roundtrip::General::RoundtripScheme
We are building a Page with dynamic functionality using ASP.NET + Sitecore 7.0.
Is it practical and appropriate use Sitecore templates for:
SQL Stored Procedure Name to be invoked
JavaScript to be invoked
ColumnNames to be used etc (related to coding customization)
Or should these configuration properties remain inside the ASP.NET Project itself?
What is the primary purpose of Data Templates in Sitecore?
Are they for developer customization or customer-level customization?
The purpose of a data template in Sitecore is to define the set of fields for content items which inherit from that template. - Think of a data template as a class and the content items (pages) as instances of that class.
Templates are usually used to define the user-editable content of pages within a site, that being said you can have items to store information which is not managed by regular content editors. The question is where do you draw the line between things which should be put into Sitecore and things which should be a part of the solution. My advice is only put things in Sitecore if they need to be there. If you have to have the ability for editors or admins to configure those settings/properties.
I would say that putting SQL/ColumnNames is probably a bad idea unless you are building some sort of report builder interface in which case it may be essential?
Likewise with placing JavaScript into Sitecore; this can be OK in moderation (e.g. snippets of analytics code which content editors may want control over?). If you're placing whole libraries of JavaScript into Sitecore, you're probably doing it wrong.
One final point to note is findability/re-factorability of code: if you have code spread between Sitecore and your solution, it can make it very difficult to maintain as it is difficult to get a complete overview of code involved.
My dilemma: My small team has been pegged with the task of refactoring/redesigning a rather large Drupal site. The site is littered with unused modules and content types, CSS/JS/HTML/etc hacks, and has a myriad of strange work-arounds for external data imports. I am currently the sole backend developer for the team, and our Drupal expertise is beginner level. We cannot build a custom CMS because of the amount of content that the site has combined with the complexity of Drupal's DB structure, it would be impossible to export it reliably; as well, content is being constantly added and modified on a daily basis.
My question: Is there any best practices, tips, advice, or any suggestions that anyone can provide that might aide us in our attempt to refactor this site?
Specifically...
Detecting, disabling, uninstalling, and removing unused modules and QAing afterwards.
Updating modules and QAing (systematic approach?).
Detecting and deleting unused content types.
Detecting and removing unused PHP code (tpls mostly).
Detecting and removing unused CSS/JS.
On modules back-end page you have dependencies shown for every module. Is some other module using it and what other modules current module uses. So, if you see that module is not used by any other module and that it's feature is not needed you can try disabling it first, check if everything works well and finally remove the module.
About content types - go to content, check is there some node of specific content type you doubt it's not needed. If there are nodes of that type try viewing them. It they are not styled well...might be that they are not used/needed.
Php - hmm...you can i.e. add some line of your code writing out some thing, or even saving some text to the file and then open page...see if you'll get some output or something saved into your file. You can even call exit() function and check will it break the site.
Similar with JS - alert something or write to console to see will it be called.
And most important thing - make a backup of all files and database first!
We often need specific items (schemas, templates, or components) in Tridion-related code. Template, Content Delivery, Workflow, or the Business Connector (Core Service) regularly need references to Tridion Content Manager URIs. We can link to components, but I typically see either hard-coded values or WebDAV URLs for everything else.
Hard-coded values
I understand hard-coding Tridion Content Manager (Native) URI's is a bad practice except for a few scenarios:
To simplify example code and make it clear what a variable is
When generated for use in Content Delivery (CD) API logic
Whenever possible we use the given API or WebDAV URLs to reference items, otherwise we must avoid using Content Porter on anything that references TCM URIs (or somehow make these references "configurable" outside of Tridion).
WebDAV URLs
WebDAV URLs seem to be better for a few reasons:
Hard-coded values in design template building blocks (TBBs) or other template formats remain intact with SDL Content Porter (breaking a relationship when moved through CMS environments, with an exception described below)
"Configuration" components that refer to specific items also do better with SDL Content Porter, though differently-named paths can "break" relationships
Use cases
In addition to having template that work well with Content Porter, I would like to localize folders and/or structure groups in lower publications. This can help with:
CMS authors that read different languages
translate item names and paths to appropriate languages
maybe help users navigate better (e.g. I suspect different-named folders may reduce confusion for where authors are in the BluePrint)
One Approach
To make references "Content Porter-friendly," at least for Template Building Blocks, I know we can use WebDAV Urls in components making sure to localize each path to the right locations in children publications. For example:
Code checks Publication Metadata
Publication Metadata points to a "config component"
Config component has paths as WebDAV URLs
As long as we set the Publication Metadata and localize the fields to the correct paths per publication, this will work for most scenarios.
Questions
Did I get this right? Is there a simpler or easier-to-maintain setup?
I believe we can alternatively use includes or map unmanaged URI in template code.
Anyone have an example of the #include approach? Do I use that at the top of a TBB and/or DWT and do references get replaced regardless of Template Mediator (e.g. will this work with XSLT Mediator, Razor Mediator, etc?)
Does the included reference work in lower publications or is this just for Content Porter? In other words, if I reference "tcm:5-123" will the template correctly reference "tcm:17-123" in publication 17?
I tend to follow a few simple rules...
There is no single valid reason to ever use a TCM ID in anything - template code, configuration components, configuration files.
If I need webdav URLs in configuration, I try to always make them "relative", usually starting at "/Building%20Blocks" instead of the publication name. At runtime I can use Publication.WebDavUrl or PublicationData.LocationInfo.WebDavUrl to get the rest of the URL
Tridion knows what to do with managed links, so as much as possible, use them. (managed links are the xlink:href stuff you see a bit all over Tridion XML).
I also tend to use a "configuration page" for content delivery, with a template that outputs the TCM IDs I may need to "know" from the content delivery application. This is then either loaded at run time as a set of configuration variables or as dictionary or as a set of constants (I guess it depends how I'm feeling that day).
Although we commonly refer to a Template Type implementation as a Template Mediator, that's not the whole story. A Template Type implementation consists of both a Template Mediator, and a Template Content Handler, although the latter is optional. Whether a given implementation will process "includes" correctly depends not on the mediator but the handler.
A good starting point in the documention can be found by searching for AbstractTemplateContentHandler.
SDL Tridion's own Dreamweaver Templating implementation has such a handler. I've just looked at the Razor implementation, and it currently makes use of the Dreamweaver content handler. Obviously, YMMV for the various XSLT template type implementations that exist.
As this is an extensibility point of SDL Tridion, whether included references will work "correctly" in lower publications depends on the implementer's view of what that would mean.
One interesting possibility is to implement your own custom handler that behaves as you wish. The template type configuration (in the Tridion Content Manager configuration file) allows for the mediator and content handler for a given template type to be specified independently, which means you could potentially customise the content handling behaviour for an existing template type.