Is it possible to have different website project solutions with different file structures to be deployed on the same Sitecore instance?
If so what changes need to be done in Sitecore setup?
You can do this so long as the solutions are using different namespaces and various files are named differently. Make sure references, etc. are the same so there are no conflicts.
Yes, you can do it. That is what layered architecture and Helix & Habitat about.
Start by watching 20 min video to catch the basic ideas about layering.
It is totally fine to deploy different solutions/sites to the same physical Sitecore instance as long as each project plays by rules:
Does not override basic templates
Does not override basic system behaviors
Related
I'm very new to django and web dev in general. I'm following tutorial https://www.youtube.com/watch?v=n-FTlQ7Djqc&index=1&list=PL4cUxeGkcC9ib4HsrXEYpQnTOTZE1x0uc create a blog by 'The Net Ninja'. His django version is 1.x but I'm using 2.1
I have completed it and have successfully emulate it on my own by following along.
But I wanted to make another on my own.
After I created it the files in my static files(the pictures for background) are clashing with my previous project.
Now background photo of my new project shows in previous project (both projects have static files in similar named folder )
So am I supposed to use virtualenv and is this kind of clash normal??? please help
It depends on what you mean with "clash". If you configure both installations to point to the same static files location, then, yes, you might have some "clashes". You can just make them point to separate folders.
As for virtual environments, it's generally a good idea to have a separate one for each project. This way you can isolate your dependencies better. This is especially important if you're going to run different versions of Django concurrently where some third party apps might not work on all versions.
I'm currently reviewing an existing Sitecore installation where the two websites have separate Visual Studio solutions. I've never seen this before, and it doesn't seem like a great way of doing it. Is there any advantages at all to keep them separate or should they be merged into one solution?
In most situations, multiple SLN files will only add confusion, as adam suggested, but depending on the specific setup of how these SLN files are being used, there are benefits in specific situations.
For example, multiple SLN files is very useful if you start getting into a large number of projects, especially if not all projects apply to both websites.
Suppose you have a common business logic layer that handles integrations to back end systems for all websites. This would be a single project referenced in both Site 1 and Site 2 SLN files. However, you might have site-specific logic for Site 2 that is in a separate project and does not need to be visible to the team working on Site 1. That other project would only be referenced in the Site 2 SLN file.
If your project plans involve anything more than editing xslt/css/js, then I think you should merge into one solution. Sitecore has a large codebase for the CMS core, and when you get to the point where you're writing sublayouts, creating xslt extensions, extending the pipeline, creating custom field types etc you'll need to use VS to build the project. Having two solutions will just confuse this.
Best of luck! Adam
I am aware that we can make templates of domains in weblogic very easily using config_builder script. Is there a similar thing in websphere?
I know nothing about WebLogic, but fix pack 9 for WebSphere added something you may find useful. The wsadmin command AdminTask.extractConfigProperties with GenerateTemplates and PortablePropertiesFile options set to true will generate a portable, editable file transferable to another cell. AdminTask.applyConfigProperties is used to read your edited output and apply the properties to a new cell, server, etc. I haven't tried this yet outside of a controlled sandbox environment; so, I'm not sure what pitfalls may await you. But if you have a ton of servers to build, it may be worth your time to do some experimentation.
Here's the IBM doc on the topic.
As far as i know i don't think there is such a capability.
You can use the default product shipped profiles to start with and create the servers and configure them the way you want.
These servers can then be used as a template to build other servers.
I am not sure if this helps you but i thought i would point this out.
Manglu
I would like to reuse one installation of Sitecore every time I need to make code changes. I currently have a branch to fix a problem, but now I need to create another branch to fix another problem. The problems are in different websites so I need to keep the seperate branches. I really do not want to create another Sitecore installation for this second branch. Is there a way to "swap" out these solutions and "reuse" the same Sitecore installation?
Mark Ursino's comment about removing the code got me to thinking. Since the solution binded to the Sitecore installation resides in the Website folder, I'll map both solutions to somewhere arbitrary, like "Sitecore Dev Folder", and then map the branch I'm working in to the Website folder of the Sitecore installation. When I change the mapping, the solution will download from TFS into the Website folder (blowing away the existing solutuion.) And that's how I can achieve the "swapping" of solutions.
Yep, we need more info here to really answer the question.
But... in general, I would advise you not to do this. Creating a new Sitecore installation is a piece of cake with the installer, and not exactly resource intensive. You could have it use the same DB if necessary to make things easier.
Mixing two different branches with the same Sitecore instance... it seems inevitable that something would get "F'd up", to use the technical term.
Let me first say I am aware of this faq for Mach-II, which discusses using application specific mappings as a third option when:
locating the framework in the server root is not possible and
creating a server wide mapping to the Mach-II framework directory is impossible
Using application specific mappings would also work for other ColdFusion frameworks with similar requirements (ColdSpring). Here is my issue however: my (I should say "their") production servers are all running ColdFusion MX7, and application specific mappings were introduced in ColdFusion 8. I most likely will be unable to do option 1 or 2 because they involve creating server wide changes that could conflict with other applications (I don't have a final word on this but I am preparing for that to be the case).
That said, is there anybody out there who was in similar bind and has done an option 4, in any ColdFusion version, or with any similar framework? The only option 4 I can think of is modifying the entire framework to change this hardcoded path, and even if that worked it would be time consuming and risky. I'm fairly sure that if there was a simple modification or other simple solution it would already be included in the framework (maybe it's included in version 1.8 of Mach-II and I don't know about it yet).
Any thoughts on solving this problem or even unorthodox setups with libraries that have specific path requirements would be appreciated. Any thoughts from Team Mach-II would especially appreciated...we're on the same team here Matt! ;-)
EDIT
Apparently, the ColdBox framework includes a refactor.xml ANT task which includes a target that refactors the ColdBox code to use a different absolute path as a base along with several other useful refactoring targets. So problem solved for ColdBox users.
Looking at the build.xml for Mach-II (1.6 and 1.8) I don't see any target in there that would allow me to refactor the code. I thought about creating a feature request ticket for such a task for Mach-II but frankly I don't think creating such an ANT task is a big priority for the MachII team since the need really only relates to either
a) users of ColdFusion versions below 8
b) someone who wants to use multiple Mach-II versions in the same application, a use I doubt they want to support
The ColdSpring code I have doesn't come with any ANT tasks at all, although I do have unit tests, and I bet if I poked around the SVN I'd find a few build scripts.
Using Ant tasks to refactor and retest the code, or the simpler (and sort of cop out) solution of creating a separate ColdFusion instance for the application are the best answers I've been able to come up with. I don't need this application to exist in the shared scope of other applications, so my first solution is going to be to try and get a dedicated CF instance for this application.
I'm also going to look at the ColdBox refactor.xml ANT task however and see if I can modify it to work generically to recognize and refactor CFC references with modified absolute paths. If I complete this task I'll be sure to post the code somewhere and edit create an answer to link to it. If anybody else wants to take a crack at that or help me out with it feel free.
Until then I'll leave this question open and see if someone comes up with a better solution.
Fusebox is not so strict, I think.
In XML mode (maybe I call this not 100% correcly, just mean using the Application.cfm) it's just proper include in index.cfm, something like:
<cfinclude template="fusebox5/fusebox5.cfm" />
In non-XML mode it will need proper extending in the root Application.cfc:
<cfcomponent extends="path.to.fusebox5.Application" output="false">
All you need is to know the path.
Perhaps you could create a symbolic link and let the operating system resolve the issue for you?
I've been playing with FW/1 lately, and while it may look like you need to add a mapping and extend org.corfield.framework, you can actually move the framework.cfc file into your web root and just extend="framework". It's dead simple, and gets you straight into a great framework with no mess and very little overhead.
It should be as simple as dropping the 'MachII' folder at the root of your domain (i.e. example.com/MachII). No mappings are required to use Mach-II if you just deploy at the root of the domain of your website.
Also:
Please file a ticket for the ANT task you mentioned in your question. Team Mach-II would love to have this issue logged:
Enter a new ticket on the Mach-II Trac
If you want to tackle an ANT task for us, we can get stuff like this incorporated into the builds faster than waiting to for a Team member to work on the ticket. Code submissions from the community are welcome and appreciated.
We don't keep an eye on Stack Overflow very often so we invite you to join our official community group at called "Mach-II for ColdFusion" at Google Groups. The Google Group is the best place to ask questions or comments like this if you want feedback from the Team.