I need to develop a web application of hotel. Some hotels have lodge system as well. How can I make lodge as pluggable module. I went through many links and found that area might be a good solution but I couldn't find out the best solution. The foremost thing I need to check whether the lodge module is present or not. If lodge is present then in main project I need to add a button to go to lodge system. How is that possible? If so then please share me a tutorial or a link.
Look at MVC Razor Precompiled Views to keep views and code in another project. Use dependency injection to share common infrastructure code.
This github repo should contain what you need https://github.com/RazorGenerator/RazorGenerator
Potentially you can make Lodge a night package and share it between projects that way. Alternatively look at making code base multi tenated and make parts of application customizable per customer
Related
Why are models not in a separate Model folder in the api template? The original template comes with WeatherForecast.cs as a separate file just by itself.
Are we not supposed to have a folder for models?
In this template you actually get minimal settings for ASP.NET project as program.cs and startup.cs with minimum configuration.
Then you choose how your folders will be located, depending on what you are going to do. If you want to make a couple of controllers with couple of methods, and you are not going to expand the functionality, you can write all the functionality of your program there and create two folders: controllers and models. In the case where you need to build a large application with a lot of logic, you need to use common web application architectures.
You can read this article and find a right direction for searching, but it is more than just "separate file and folders", this is a very big topic for thought.
Let's say that I'm building a social networking web site. Should I put the whole web site under SocialNetworking module should almost each page have its own module like ProfileModule, MessagingModule, and GalleryModule?
Or it is somethink differen like AvatarModule, UserToUserConnectionModule like FriendshipModule, PrivacyModule?
Modules are not containers of different "pages" of a website.
A module can literally be anything, but in most cases it provides "features" (services, listeners, events, classes, generally logic) for your application.
Don't separate modules thinking at them as separate URLs in your web application: instead, think of them about containers of reusable code.
As a rule of thumb, a Zend Framework 2 Module can be separated from the other functionality on your application if it provides logic that you may want to reuse in another project.
As you can see, it's all about producing reusable and decoupled portions of your application.
Just to add something to the good answer of #Ocramius, the examples you've given can ALL be modules.
You can have a "BlogModule". This module would handle BlogPosts. Then you could have an additional "CategoriesModule" that adds the option to give each BlogPost a Category. Then you could write another Module "MediaModule" that adds the functionality to attach Media to your BlogPosts
I developed a couple of modules for OpenERP and want to make them available to others.
The obvious VCS choice is Launchpad (even if I feel tempted to use GitHub).
I have a development environment with all these modules, but people should be able to download/branch only the ones they want. As you may know, each a module is a separate folder inside de addons project folder.
Should I:
...create a branch of lp:openobject-addons for each module? That seems to generate a lot of duplicate files in my dev machine. And will people be able to extract only my module from the full branch?
... create an empty "host" Project and then a branch for each module? Does this follow best practices? Will this make it difficult for people to download a few, or all, of the modules?
.. or do something else I'm not considering?
Creating a separate project and branch for each of the modules is probably the most sensible thing to do.
This allows people to check out just those projects they care about, and submit changes for just the projects they care about. The overhead of creating a new projects is pretty low.
If you want to publish your modules to the OpenERP Apps site, you don't want to create a branch of lp:openobject-addons. The page for registering a branch specifically says not to do that.
Other than that, your choice seems to be between one branch per module, or several modules within a single project, each in its own subfolder. Personally, I would lean towards the second option because you don't have to create and register a new branch every time. Customers can download each module independently as a zip file from the apps site, or download the whole branch directly from Launchpad.
Note that this just covers your own modules. If you want to submit bug fixes to the core modules, see this question on merge proposals.
I am thinking there must be some libraries out there that people have developed which can be used as "plugins" or whatever people call them to do simple and common UI types of things.
I am using the message board idea as just an example, but I am looking for a general solution. For example, is there a place where I can browse "gems" for RoR that just take care of some UI component?
How do people usually integrate such pieces as a message board present at the bottom of every page, or some other ui tool without writing their own, or using a CMS?
Thanks,
Alex
Two good places to browse gems are http://ruby-toolbox.com/ and of course http://rubygems.org/
I am rather new to Sitecore and would like to know a bit more about the regular approach to a new project. I'm therefore willing to listen and try out some of the experienced Sitecore developers solutions. I have alot of questions, i won't ask them all. I am just very curious to the approach other people have.
What would be the best approach to start a Sitecore project?
How would you set your project up?
What will be your approach looking at the recycling of code in future projects?
In short: What experiences do YOU have (if you have worked with or are working on Sitecore projects) and how would you recommend other people to work with Sitecore.
Right now we are busy on building Sitecore blocks that we can just recycle in other projects but i know for sure there are 1001 handy tips and tricks out there. I hope we have some Sitecore pro's # stackoverflow that could help a bit.
Here is some general setup info, based on how we do things.
Subversion
This is not Sitecore specific but we set up our repository like this
branches - This is used for working on big updates to the site that may take a while. Say for example I wanted to update how all of the sidebars on the site worked, and this was going to take a few weeks to complete. What we do is create a new branch, and set up another sitecore instance for this dev branch and do what we need to do. When it is complete we merge it back into the trunk for testing and deployment.
tags - This is used for keeping a copy of code that will never be merged back into the trunk (that is the difference between this and branches), so for example when we deploy an update to a site we can create a tag of said code so we can go back to it if necessary.
trunk - The active code, anything checked in here should always be deployable.
The Trunk
This is where we are actively developing/fixing bugs, depending on which part of the project that we are on. We set it up something like this (as an example the project is called TheProject)
We keep our solution file at the root of this folder, this will reference the various libraries in the src folder as well as the web project in the website folder.
docs - A place to put documentation about the site. I strongly suggest that as you complete features/sections you write up a little guide about any special knowledge needed for it to work. So say I am working on a featured content box on a landing page. This box will automatically pull some content unless it is explicitly overridden. What I do when I complete something like this is I write a guide for the customer, using a lot of screenshots. I send the guide to the customer as well as put it in the docs folder. This both helps the customer train their staff, as well as helps new developers come up to speed with how things are done.
lib - This is where we keep any DLLs we are going to need to reference in our projects.
test - A place to put unit tests.
src - This is where we keep our project specific library code. So in here we would have a folder called TheProject.Library, and in there would be the visual studio project for said
web/Website - This is where we have Sitecore installed and is the root of the site. In here we have a project called something along the lines of TheProject.Web. In the project we add all of the general stuff like the web.config/layouts folder and so on.
General Sitecore Code Library
One the best things you can do is from the start setup a general Sitecore library that can be added onto over time. Then when you write any code for a project that is not only applicable to the project, you can add it there. It may seem obvious, but this will really help in the long term. You will end up with much more solid code, see link text .
So when we are done with all this we have something like this as a solution/project structure
TheProject (The solution)
TheProject.Library
TheProject.Web
MyCompany.SitecoreLibrary (our general sitecore library)
Tools
This is another general thing, but I find it can really help speed up Sitecore development. If you find yourself doing something over and over in Sitecore, using API write a tool to do it for you. This not only helps with solving whatever problem you are tackling, but also helps to get you more familiar with the API.
Resharper
This is more of a general .NET development suggestion, use Resharper(http://www.jetbrains.com/resharper/index.html). I am sort of a a Resharper fan boy, it makes so many things with development easier and quicker. In my mind the biggest advantage though is how easy it makes refactoring code, which is really important to do over time to keep things clean and understandable.
I hope some of this helps.
Gabe
This is, as you said, quite a big question. Here are some of my thoughts:
Developing Environment
First of all when I start a new project I install Sitecore on my developing environment and I make sure everything works. Either during installation or after I place the databases on a separate SQL-server and change the connectionstring accordingly.
I open up Visual Studio and create a solution and include the files needed. I create some kind of HelloWorld rendering and try building the solution so that I can verify that everything is working as it should.
When everything is up and running I create a zip-file of the whole solution, including the data-folder. Now it is time to add this to some kind of version control system, in my case Subversion.
I add the zip-file to subversion and also add all files that I think will be changed during the project, usually I tell subversion to ignore the sitecore folder, this speeds up performance drastically when checking in files.
After I perform a commit-action the other team members of my project can check out the code and start developing (after unzipping the zip-file, off-course)
We all work towards the same database although this goes against Sitecore recommendations, we havent had any problems with this approach however items in GUI created/changed by one developer take some time before it is created/changed for all the others.
We could off-course develop several different projects using the same Sitecore installation but since almost all customers use different versions of Sitecore we have found this approach a bit cumbersome.
Often we set up an automated build-server but this is a whole other issue.
Reusable code and renderings
I would like to say that we create neat packages based on the same codebase that gets reused between projects but unfortunately we are not there yet. Today it is a lot of cut and pasting between solutions.
Uploading code to customer
This is done via sitecore packages, normally with some kind of dynamic selection for what files to include, say all ascx-files in a specific folder changed the last 5 days.
There you have it.
Take a look at this series.
Especially the component architecture part have increased our level of reusability.
When you create your Visual Studio's project in Sitecore's web root folder and you will keep all Sitecore's dlls files inside bin directory, don't forget to add to project's references all these files:
bin\ComponentArt.Web.UI.dll
bin\HtmlAgilityPack.dll
bin\ITHit.WebDAV.Server.dll
bin\Lucene.Net.dll
bin\Mvp.Xml.dll
bin\Newtonsoft.Json.dll
bin\RadEditor.Net2.dll
bin\Sitecore.Kernel.dll
bin\Sitecore.Logging.dll
bin\Sitecore.NVelocity.dll
bin\Sitecore.Zip.dll
Because when you CLEAN your project and you will have reference only Sitecore.Kernel.dll (in most of cases), you will lost most of dlls from bin directory!!