I am creating a basic Alerts feature which has a AlertDataSource template and Alerts folder. As per Helix where should I put this, in the Project or Feature layer?
As you are creating a feature, the AlertDataSource template must reside with your feature. Otherwise your code should not be able to access any data from it (as it is not aware it exists).
Your folder on the other hand is another thing.. if your feature does not need to be aware of the location of the datasource items you could argue that it can reside in the project layer just to organize your data on project level. But you could also decide that the feature requires that your data is organized (maybe for datasource locations or so) and in that case it should be in the feature as well.
In theory you should use interface (base) templates in your feature and derived templates in your project - but that is the theory. For page templates this is absolutely true. For datasource items, I've seen people being practical and not do that (also because not everything in Sitecore can handle base templates that well). But your are right in your comment - in theory you need to have base templates with the fields in your feature and (empty) derived templates in the project layer.
Related
I would like to do a project with TYPO3 v10 I'm new with this CMS and I need to create different templates for different pages but I don't understand which code I need to change.
I already install a sitepackage from this site https://www.sitepackagebuilder.com/
It work well but I need to create my own templates and I want to edit the content of my templates in the back end administration like in the picture.
I hope I'm clear
thanks for help :)
I am not sure if there is a misconception in the question or if I have interpreted incorrectly. In any case, I hope this helps:
It is important to differentiate between content + template in TYPO3:
content
In the screenshot posted in the question, you see the TYPO3 backend, which is a view for editing content, administration etc. There you see the page module is opened in the left column (1), you see the page tree in the middle column (2) and the page layout for editing content on the selected page in the right column (3). Here, you can insert and edit the content, that will be displayed on a page.
Template
In TYPO3, the template is what makes up the automatically generated parts of the page such as header, footer, menu, breadcrumb etc.
It work well but I need to create my own templates and I want to edit the content of my templates in the back end administration like in the picture.
Editing the template in the backend with a Wysiwyg ("what you see is what you get") editor, similarly to editing the content is not really possible in TYPO3 AFAIK - at least not out of the box. For this, you would need a template builder. The only thing I have seen so far that comes close to this is toujou (I am not affiliated with them, just wanted to mention it). They have something which you could call a website builder. But AFAIK, you can't download it, they provide this as a service.
The sitepackage builder - as far as I know - pretty much just creates a sitepackage based on the bootstrap package extension which you would have to further modify by editing the files.
What you can also do is edit the TypoScript in the backend. Just go to the "Template" module in the left column. But, this made more sense in the past, because a lot more was done with TypoScript. Nowadays, you usually use a combination of Fluid and TypoScript and you can't edit the Fluid files in the backend.
While in the past, a lot more was done in the backend or could be done in the backend, everything is moving towards maintaining changes in files and extensions, where the template is maintained in a sitepackage. For some things both is still possible (backend and extension), e.g. backend layouts, TypoScript etc.
Moving the configuration + templates from the backend (and storing them in the database or as files) to a dedicated extension has several advantages:
Every configuration etc. is bundled into one extension, this makes it easier to install in another site, on a testsystem, exchange it etc.
the sitepackage can be put in a version control system (e.g. git) which has a bunch of other advantages such as easy rollback to a previous version, referencing issues etc.
The downside is that you need more technical expertise and there is a learning curve.
see also:
The Anatomy of Sitepackages
Sitepackage Tutorial
I understand that it might be pretty cool to assemble a template in the backend - just like you can do with the content. Maybe someone else knows how to do that with TYPO3.
You can also check out these resources which seem to go in the direction of what you are looking for:
TYPO3 extension mask (documentation)
T3terminal
in the official documentation you can find the structure of folders where the files for your layout are stored.
More details on fluid templating in this document
Now you want a possibility for editors to select between different page layouts. An often used way is to use the possibility to select different backend layouts and select a frontend layout accordingly.
This is shown in the video on this page or in the documents you can find if you uses the searches on that page.
Management has asked that all teams move to a single Implementation of VSTS (Azure DevOps) and I have a couple of questions that I would like some clarity on.
Please let me know if this statement is accurate:
A single instance (Install) of VSTS can support multiple Projects.
If that is true
Can you roll up reporting from multiple projects or does it stop at the project barrier?
Can a Project support multiple work item templates?
I ask the second question because we have we have multiple teams that do different kinds of work, we would like to have a minimum set of fields for each work item type (Feature, Story, Task, Bug) but that set of fields would be different for the different teams.
using the example of a Task Template,
Can we have a "Base" set of fields that are common to all task templates but each team has additional fields that are unique to them?
Thanks
Kind of. Work item queries can cross Team Project boundaries. You can also use the OData API and make any kinds of queries you want in PowerBI. The built-in tooling pretty much assumes that reporting stops at the Team Project level, though.
No. A given project has a process template. It can change between versions of the process template (as long as they are derived from the same base).
So to answer your more specific question, let's say you choose the "Agile" template. You can create an inherited process template called "Agile Plus My Awesome Customizations" and add additional fields.
Then you can inherit from that and create process templates with additional fields for your individual teams.
So your process template inheritance structure might look like this:
Agile
Agile Plus My Awesome Customizations
Team A's Additional Awesome Customizations
Team B's Additional Awesome Customizations
Team C's Additional Awesome Customizations
However, each of those process templates would have to be applied to a different team project.
I am currently involved in a Django project and I am definitely using Twiter bootstrap for the layout.
Though not actually precise, my question is quite simple: Bootstrap allows me to choose which styles/JS I want to download separately -- forms, tables, responsive, styles for buttons, navigation, etc -- and also together in a single "all-inclusive" file.... and I am not using all the resources at once on the same page.
Additional to that, we have the Django template system, which allows me to build one template over another, so I can basically add the more general stuff to my base template and, as I need in subtemplates, include the other static files.
So, to sum up everything: Is it worth it, to have those styles separated? I think that in terms of organization maybe it is not so clean, because I will have to import and handle more CSS files, but on the other hand I won't be loading unnecessary stuff.
What are the trade-offs of this choice?
Thank you for your time.
Is it worth it, to have those styles separated
No it is not. If you look around, e.g. visitmix, you'll see that the overhead of requestig new files make the difference neglible.
Server you static from a cookie-less domain and you'll users will only have to hit your servers twice: once for CSS and once for JavaScript.
I'm new to Django and fairly confused about how third-party apps are best integrated. In my (possibly naive) interpretation of DRY, I want to minimize copy/pasting not only my own code but other people's code as well, so I'm happy with, for example, the pattern of using contrib.auth as mostly a black box if I needed additional info on auth.User (by extending auth.User with a UserProfile object or inheritance). And this was how I imagined I'd use most third-party apps as well.
However, I quickly found out this was very difficult, so now I've resigned to having "copies" of all of my third-party apps living inside my project folder that are basically entire copies with minimal changes. The final straw was me wanting to add a basic blog (I settled on django-basic-blog) and needing to just change a single template, and I thought of no better solution than just making a copy of that app inside my project with the single template changed.
My questions:
in this specific case where I need to change just a single template, is this (copy the entire app over) the best I can do? If I just needed to change a single model I can keep the third-party app respectfully intact and do a model inheritance in my own app...
in general, this practice of copying the apps under my project and patching each a tiny bit feels crazily wasteful and dirty. It also feels like if I'm using a frequently-updated third-party app it will be a pain to sync the changes. Should I just learn to love the bomb or is there some obvious architectural pattern / Django-provided assistance I am missing?
You should not modify the code of 3rd-party modules, as it's hard to track the changes and it creates a mess with the same code copied into many projects. Typical solution is to have only one version of each third-party module in your python path, not in your project's dir. This single package can then be reused by all of your projects.
However different approach is needed for templates, as they often need to be modified on a per-project basis. That's why Django comes with settings.TEMPLATE_DIRS and settings.TEMPLATE_LOADERS.
TEMPLATE_DIRS specifies list of directories containing template files. TEMPLATE_LOADERS specifies the classes used to load templates. The loaders will be used in order they were defined and the directories will be traversed in order they were defined. So you can look for templates in your project's directory first and in other modules as a fallback.
So basically you do not need to copy the entire python module in order to change one template. Copy just the templates directory of that 3rd party module or even just the single template you want to change. If you'll put in the right place and add have the path in TEMPLATE_DIR Django will use it.
In the project there are two data sources: one is project's own database, another is (semi-)legacy web service. The problem is that admin part has to keep them in sync and manage both so that user doesn't have to know they're separate (or, do know, but they do not care).
Here's an example: there's list of languages. Both apps - project and legacy - need to use them. However, they both add their own meaning. For example, project may need active/inactive, and legacy will need language code.
But admin part has to manage everything - language name, active/inactive, language code. When loading, data from both systems has to be merged and presented, and when saved, data has to be updated in both systems.
Thus, what's the best way to represent this separated data (to be used in the admin page)? Notice that I use ASP.NET MVC / NHibernate.
How do I manage legacy data?
Do I connect admin part to legacy web service external interface - where it currently only has GetXXX() methods - and add the missed C[R]UD methods?
Or, do I connect directly to legacy database - which is possible since I do control it.
Where do I do split/merge of data - in the controller/service layer, or in the repository/data layer?
In the controller layer I'll do "var viewmodel = new ViewModel { MyData = ..., LegacyData = ... }; The problem - code cluttered with legacy issues.
In the data layer, I'll do "var model = repository.Get(id)" and model will contain data from both worlds, and when I do "repository.Save(entity)" it will update both data sources - in local db only project specific fields will be stored. The problems: a) possible leaky abstraction b) getting data from web service always while it is only need sometimes and usually for admin part only
a modification, use ICombinedRepository<Language> which will provide additional split/merge. Problems: still need either new model or IWithLegacy<Language, LegacyLanguage>...
Have a single "sync" method; this will remove legacy items not present in the project item list, update those that are present, create legacy items that are missed, etc...
Well, to summarize the main issues:
do I develop CRUD interface on web service or connect directly to its database (which is under my complete control, so that I may even later decide to move that web service part into the main app or make it use the main db)?
do I have separate classes for project's and legacy entities, thus managed separately, or have project's entities have all the legacy fields, managed transparently when saved/loaded?
Anyway, are there any useful tips on managing mostly duplicated data from different sources? What are the best practices?
In the non-admin part, I'd like to completely hide the notion of the legacy data. Which is what I do now, behind the repository interfaces. But for admin part it's not that clear or easy...
What you are describing here seems to warrant the need for an Anti-Corruption Layer. You can find solutions related to this topic here: DDD, Anti Corruption layer, how-to?
When you have two conceptual Bounded Contexts, but you're only using DDD for one of them, the Anti-Corruption layer comes into play. When reading from your data source (performing a get operation [R]), the anti-corruption layer will translate your legacy data into usable objects for your project. When writing to your data source (performing a set operation [CUD]), the anti-corruption layer will translate your DDD objects into objects understood by your legacy code.
Whether or not to use the existing Web Service depends on whether or not you're willing to change existing code. Sticking with DRY practices, you don't want to duplicate what you already have. If you want to keep the Web Service, you can add CUD methods inside the anti-corruption layer without impacting your legacy application.
In the anti-corruption layer, you will want to make use of adapters and facades to bring together separate classes for your DDD project and the legacy application.
The anti-corruption layer is exactly where you handle splitting and merging.
Let me know if you have any questions on this, as it can be a somewhat advanced topic. I'll try to answer as best I can.
Good luck!