I'm looking for a SiteMap provider for use in an MVC 5 application that can support sub areas.
The folder structure in my project notionally looks something like:
Project Root
Areas
Area A
Controllers
Models
Views
Areas
Area A1
Controllers
Models
Views
I need an MVC SiteMapProvider that allows me to use controllers located in the A1 directory.
I've played with the MvcSiteMapProvider (https://github.com/maartenba/MvcSiteMapProvider), and it does not seem to support sub areas in the sitemap file. Is anyone aware of a solution for creating breadcrumbs with this type of setup?
Since MVC doesn't support sub-areas without advanced customization, MvcSiteMapProvider does not support them either.
However, there is a project called MvcCodeRouting that supports multiple levels of controllers as an alternative to MVC areas, and MvcSiteMapProvider has support for it.
Found a good enough answer for the time being:
Using MvcSiteMapProvider, initially I was trying to use the Area, Controller, and Action properties in the mvcSiteMapNode to reach the A1 controller. This was unsuccessful. But if I used the URL property, that worked.
https://github.com/maartenba/MvcSiteMapProvider/wiki/Defining-Sitemap-Nodes-in-XML
Related
In Kentico 11, in a custom module you are developing, when using a custom Page Template (portal mode) for the UI Element, where is the appropriate place to host Transformations used by web parts of that template? "Appropriate" meaning the transformations can be bundled with the module for import/export operations or at least grouped with it logically in Kentico admin?
The Kentico Custom Module app doesn't contain a Transformations tab for its Classes.
Repeater web parts used on the UI page template only list Custom Tables and Page Types when looking for transformations. Transformation doesn't seem to be supported for a Custom Class.
I could create a standalone container Page Type to host all transformations for the module, however this would be outside the module. These transformations would use data from Classes in the module (through repeater web parts and query data sources for example). It seems odd to put them outside so I am suspicious of doing this.
Up until now I've only used the out-of-box tab and listing web parts to create custom modules. Now I need to get into more customization, and prefer the portal mode to easily build templates using web parts. Transformations seem to be the missing consideration in this development flow.
Neither can I find Transformations mentioned in the Custom Module documentation. Kentico Documentation I'm referencing is:
Creating custom modules
Manually creating the interface for custom modules
Martin Hejtmanek's Module development articles like this one
I can find a place to put my transformations. I'm looking for thoughts about where to best put them and bundle them with my custom module work.
Your findings are a shortcoming in the module documentation. The documentation talks in great detail on how to build the module and display it within the Kentico UI but talks little to none on how to display that content outside of Kentico on the public facing website.
What you mentioned, using a custom Page Type as a container is a simple easy approach and I believe you can bundle this with your module. Yes it doesn't make sense but using this approach will allow you to have your custom queries to access the module data and display options (transformations).
You have another option to create custom webparts for this and package them with your module but I'd recommend against this because it takes away from the basic usage of Kentico and will require code maintenance and modifications for simple changes.
If you look at page types you will see that Kentico does the custom page types to hold transformations. They have ones like RSS Transformations, E-Commerce Transformations, etc.
That is the way I have always done it also.
I suggest you to take a look at the custom table module as example, i.e. user interface part of it: there is transformation menu item under edit custom table in the interface. Take a look on how it is done and try to clone/modify it for your own custom module. If you check the DB: cms_transformation table has TransformationClassID field. So transformation is attachable to a class - so you custom classes can have transformations attached. Honestly i've never done it, but this is the way how I would approach. I would keep apples with apples, oranges with oranges... yeah sure you can always create "container page type" and it will work, but i would play around with the custom module. You might need to create and extender in this case.
#John,
As per Brenden post, you can achieve this using custom web part with your custom logic.
Refer below URL:
https://docs.kentico.com/k10/developing-websites/defining-website-content-structure
I am about to develop one liferay projects and have some query regarding that as follows..
should we create a different portlet project per section or we should combine all section in single portlet project?
we have a different section like "Campaign","Advertise" etc now each section is interconnected,
i mean to say in i would be able to display list of advertise mapped with particular portlet. can please guide me?
I think by section you mean Categories in the Add more section that appears in the dockbar at top-left corner of the portal page.
It is not mandatory to create different portlet projects that go in different categories. It is purely your choice keeping in mind future management.
Following are some considerations to keep all the portlets in one project:
If the portlets are going to use each others services
The portlets will depend on each other for showing the same or similar data, like take for eg: Documents & Media portlet and Documents & Media display portlet would go in one project.
I would say to keep in mind the Software Design Principle of Cohesion and Loose coupling.
This is what I can think at the moment. Hope this helps you in taking your own decision.
Try and put all Portlets under one Project. So that deploy is easy because basically the config files (like, liferay-portlet.tld, liferay-portlet-ext.tld) will be same.
You might wanna make different projects for code that's not about portlets.
I mean different project for Theme, or UI class, different one under Services/Server Side Java code, different for database config/connections etc.
All portlets could go under one project for above mentioned reason.
And you can still have separate space / loose coupling inside this one big portlet project because your (javascript/whichever tech you're using) code will be in separate folders.
About your question of displaying a particular list inside of the portlet, I guess it depends on how you want to code inside that portlet to show your list.
I agree with Prakash K.
Moreover, you should need to have two portlets in the same project (and with "project", I hear "war") if you need to share private portletsessions. So, as Prakash said, if you need interactions between 2 portlets, use one single project.
You can find more information about this particular point in this great blog (not mine): Liferay session sharing demystified
I am making several web applications. What I want to do here is:
Applications should stand alone in IIS using differnt application pool.
There is one main application used solo as front page, allowing log in/out and navigate users to other applications.
I want other applications to use the layout of the main application.
The structure I was thinking was to deploy the main application under root folder of the website and host other applications under it in seperate folder (seperate application and pool). Something like:
IIS
|
|__Main app (web site)
|
|__App1
|
|__App2
However, I just got confused here:
How can I reuse the layout/dll acorss apps/pools without copying them into each application (Maybe it's a silly question)
How can I use MVC3 controller/action feature instead of directly using hard coded <a/> to navigate users to each application. I actually tried it. Looks like the Main app (MVC3) can only recognize controller and view in it's own project.
In summary, what I try to do is: Deploying my applications in the tree sturcture above and let the main app bring views from sub apps and display in main app's frame.
Maybe it's not a good practise, but any suggetion is welcomed!!!
Thanks a lot
It really sounds like you would want to make use of Areas in MVC. This wouldn't allow you to run the nested "applications" in their own App Pool, but it would accomplish everything else you are looking to do (shared layouts, dlls, Html.ActionLink, roles based access to each Area, etc). You can easily share top level navigation across all Areas and have different sub navigation for each. I have a 2 part blog post about using a single layout that is shared across Areas that might give you some help (or ideas).
Single Layout for Areas with ASPX and Razor views (Part 1) - Using the ASPX View Engine
Single Layout for Areas with ASPX and Razor views (Part 2) - Using the Razor View Engine
If you felt that having sub apps in Areas in a single project was too rigid you could also look into using MvcContrib to make your sub apps in Portable Areas and then consume them in your top level app.
I have Orchard CMS and I want to integrate my MVC site with it. Can anybody tell me how to do this?
It depends on how complex your MVC app is, but in most cases it is straighforward. The easiest way is to wrap your existing site into Orchard module. Writing a module is described here. These are the necessary steps:
Copy your site to a subdirectory under ~/Orchard.Web/Modules along with the .csproj file so that the .csproj file should be in your application root (eg. ~/Orchard.Web/Modules/MyApplication/MyApplication.csproj)
In the root of your app create a Module.txt manifest file. This small file describes your application - its syntax is described here
Set appropriate routes so that existing controllers' actions can be hit. It's also described in the article above. By default, your application URLs will look like /MyApplication/Controller/Action - you're free to change it as you wish. Be careful though not to interfere with existing routes, eg. /Admin, /Users and so on. The routes you specify have higher priority and will override every exisiting ones. Btw - Area name, where necessary, would be the name of your application (eg. MyApplication).
Run Orchard and enable your application in Modules/Features admin menu.
Add necessary changes to web.config file.
Remember though that Orchard is based on ASP.NET MVC 4 and uses Razor view engine. If you use some other view engine, you have to specify it appropriately in the web.config file.
I understand the pros of using namespaces within the actual application layers but when it comes to the front tier, I am not so sure.
My project is a Website (not WebApplication) and I get all sorts of problems (missing references, for one) when I try and include "namespaced" user controls. Despite explicit declarations in web.config under system.web - pages - controls - add.
When it comes to the actual views, the webforms: when you create a new page, Visual Studio creates the codebehind classname from the path where you chose to create the file. So most times, I'd say that class names will be unique. If you move around pages, then it will become strange to see say Start_DefaultPage but under another sub folder.
To summarize: Is it recommended to put namespaces into the web tier? What are the pros and cons?
Yes. In the future, you may decide to include external libraries that (coincidentally) use the same class names, and you do not want to have a namespace collision, as you very well know can occur. In addition, you may have web applications in a virtual directory that will inherit the properties outlined in the parent web.config. You do not want to mess with namespace conflicts there, either. Generally speaking, it is just a good programming practice.
Your problem is that you are using a web site "project". Stop doing that, and you'll stop having these problems.
Web Sites are a mistake that Microsoft made. There's no need for you to make their mistake into your mistake.