Are there any resources with information creating a self contained, reusable module?
I need to create modules that I can drop into projects quickly and easily. An example would be a news module that would contain an admin area, news listing page, It supporting CSS & JavaScript, etc.
Am I smoking my socks or is this even possible?
You need plugins for your application.
I've got a plugin library (in development and in Spanish) that you might use as an example or a starting point. I don't know how good google translate will be but you can check a C# plugin tutorial in http://translate.google.com/translate?hl=es&ie=UTF-8&u=http://www.thealphasite.org/es/sistema_de_plugins_con_c_y_net&sl=es&tl=en
A plugin allows you to plug in :P functionality into your application and, with a proper design, it will allow you to move functionality dinamically from one application to another.
Anyway, plugin just provide with ease of use but require a design specifically thought with them in mind. On the other hand, basic "take this module and use it in another project" is just proper encapsulation and good design. If a module is well designed the it should be able to be ported to another site or application with very little effort.
Keep in mind that, specifically for web, "theming" is a complex subject, that is, adapting your plugin to the way an specific web looks is another step of customization which has to be included into the module itself. You can see an example in the Drupal theming functions and the theming api documentation.
Look at www.allnewsmanager.net, maybe is what you are looking for. It is a reusable module, free and open source.
Not sure about any resources - but I've done this myself by writing a CMS from scratch using a combination of user controls for the modules, and a templating system with common code file which loads said user controls into placeholders.
The templating system allows you to create an aspx file, with a bunch of placeholders (as many as you need) - then you need a database or similar to manage what controls go to what placeholders, on what page. A template can handle many pages.
Downloading and studying the architecture for dotnetnuke can enlighten and give ideas for structuring your own approach, even though it's VB, the data structure is just as interesting.
Related
I have some business logic that monitors user activity, badges, audits and ranking. I plan to show the data in a admin and public webpage, so has its own web views.
I am trying to package this into Orchard. While I understand that orchard had modular architecture, but its unclear on what the differences are, or are they the same thing? So, my question is - how should this be packaged this as a widget or a plug-in, or does it not matter?
What would be the different from a) user perspective and b) developer perspective? or are they the same thing?
A module is a bunch of code that relies on Orchard's APIs, (and possibly on the API of other modules), packaged to be easily installed. Widgets are reusable pieces of UI. They are a part of a module, so the question sounds a bit like a category error ;)
Your features have to be packaged in a module, that's the only way to extend Orchard, but what's in that module seems to be the real question here. I'd advise you read more documentation to understand the basic concepts in Orchard, and then it should naturally click into place, and you should be able to figure out what concept to use for each part of your design.
These are good places to start:
http://docs.orchardproject.net/en/latest/Documentation/Basic-Orchard-Concepts/
http://docs.orchardproject.net/en/latest/Documentation/Getting-Started-with-Modules/
I recently attended a demo of a large-scale enterprise system, whose web pages may be customised to the point of including fields added by the client. The way I understand it, their architecture is made up of the following layers:
Database
Web service API
XML files that dictate layout
The web pages that are generated from the XML files.
When I was asked to investigate building a web portal which could be easily branded, that struck me as a good way of going about it. The question now, is how one would design it.
I understand the database and web service layers, but I am a little confused by the various possibilities for building web sites in .NET.
Considering the requirement for customisability and the architecture from above, here is how I understand the options:
Webforms - the option I am most familiar with, but it is essentially enriched HTML with code-behind. I think there will probably be a lot of work to make it work with the idea of an XML layout.
WPF - the XAML middle layer is built-in, but as I understand it, WPF can only really be used in browser applications and not websites.
Silverlight - more for building applets than websites, right?
MVC - This looks interesting, but all the demos I have seen use Entity Framework as well. It seems to me like Entity Framework with all its automatic code generation is much more suitable to applications that are all new. In my case, I have a very large database that already exists.
If none of the above are suitable, I thought of an alternative. One could do a stock standard Webforms site with a web service that returns the branding elements. That isn't quite the same as what I described at the top, but is sufficient for my needs.
Or am I barking up the wrong tree?
I think you're off on your criticism of MVC. First, you don't need to use Entity Framework, and secondly even if you did, you can do it database first to generate your entities.
Your assessments of WPF and Silverlight is pretty spot on imo.
You could do this with webforms, but I think you'll probably find doing it with MVC architecture will be cleaner. Very simply, if you use clean HTML and put all branding elements into an external CSS file (logos, colors etc), then you are half way there to a custom brand. Even a different layout could potentially be defined by the CSS file (although it might be harder for your end users to customize that look since they would need to know css pretty well)
Building additional fields is potentially more difficult:
Off the cuff, the way I'd be looking at implementing this would be a combination of my predefined fields in a standard database layout (users table with username, password, first name, etc etc) and additional support for the "customizable fields" using the Entity-attribute-value pattern
From there you will need to develop an extensible system to 1. generate a page from xml with the appropriate form elements (select, text input, textarea, etc). 2. Generate a generic model that will read the same XML file and be able to receive data from a posted form and know how to save that to the database (note in this case if it was ALL entity-attribute-value that would probably be easier to manage than a combination of standard relational and EAV).
You'll probably want to look at .NET Data Contracts as serializable entities to get an understanding of how you might design your XML files to be extensible to allow for things like "select menu has the following 3 options" or text input must match this regex.
Really keep an eye towards extensibility, because you can't build it all at once.
I have read many articles and questions here on SO about this, however I am still not comfortable. I am planning to develop a plug-in based GUI desktop application based on MEF technology.
I would like to provide a localization support for the application. The problem is that even if I localize the host application, the third party plugins which are basically DLL files and can be installed any time, will also need to be localized.
I think having all localizable controls in a dll is not an option for me. I can store the international texts in a database, have a caller function which is retrieving the text from DB in the host applciation, and ask plugins to call this caller function. Or I can ask the developers to have different resource files in their applications, but this way, they will not benefit from already translated texts.
What is the best practise to provide multilingual interface for this case?
I'm not sure that there is one best practice that applies, but I can talk you through the options as I see them. If you develop a central database with your different translations for everything, all of your tools can benefit from the translations. However, the downside is that now all of your plugins will also need to know about the database (in some way). That adds a more direct coupling that I prefer to avoid when using third party plugins.
If you use the resource files, you gain more flexibility but lose the ability to reuse the same text (which feels like you are violating DRY).
Personally, I would go down the resource file route for your localization. It provides you the simplest way to get everyone working without major dependancies. However, if you can figure out a way to have the plugins call the central application for their localization text, the central database would be a better option (again, in my mind).
Here are a couple links that might help you out as well:
Is there a best-practice approach for internationalization of an application?
http://www.businessandprocess.com/2010/11/why-application-localization-should-start-in-the-design-stage/
http://expatsoftware.com/articles/2010/03/why-internationalization-is-hopelessly.html
I am in the process of designing a web application which will have multiple installable modules that provide different functionality. There's a lot of common stuff going on here and I have 3 C# class libraries that I know will be easy to use on different projects.
The bit I am stuck on is the actual website itself. Ideally I'd like to make an ASP.NET page library that can be re-used over multiple projects but I understand that this is not possible.
How do you guys structure your website projects so that pages can be re-used across multiple projects? So far the only solution I've come up with is to create a repository in SVN and have it referenced in the svn:externals properties of the main project. This allows me to add pages to that directory that are common to all websites, and I know I will be able to use this to check them out to other projects. However, I feel this is a bit clunky and will cause problems when creating new projects (there'd be a number of steps to creating the new solution, ensuring that the right externals are in place).
Is there a better solution? What is the best way when you want to share common ASPX files across multiple client projects? How do you manage changes against them?
Thanks in advance!
EDIT:
Many thanks to David for his response. I've had more thought on this and thought I'd list some of my more concrete ideas/concerns. Firstly, a bit more about the project(s). Primarily, it's a CMS. However, we also have clients that will want CRM, and there's also clients that want neither and want an entire bespoke system from the ground up.
In my original post above, I spoke about having subdirectories of the main root (e.g, cms), using svn:externals to allow easy re-sharing of web pages across multiple projects. I am beginning to think this is the only way to do this. One thing that bothered me was if the client's url was:
http://www.shotgunanddribble.com/cms/content.aspx
However, I think I can use the Application_BeginRequest to mitigate horrible urls by rewriting them according to the configuration of the client's site. E.g, if a customer was just a CMS I could rewrite their Top-level-domain to /cms/. Same with if they were a CRM. If they were both:
http://www.shotgunanddribble.com/ -> /cms/
http://crm.shotgunanddribble.com/ -> /crm/
Is there any downside to using these kinds of rewrites? I think that, unless anyone else has any magical ideas, svn:externals is my only hope.
The actual code is easy enough to put in other assemblies and inherit from, but the ASPX files are definitely a different story. How about a common library of user controls to contain most of the display content, and each project would have its own pages which mostly just frame the user controls? I've never tried it, so there may be some "gotcha" that I'm just not picturing right now.
Im building a CMS (ASP.NET C#) and I am currently looking at how to implement a module system. How is it done with most modularized systems on the web? The most important thing is that I dont want the modules messing with any of the core files.
Example of a case:
I have an ajax search method that is using a webservice method named Search; how can a module "add" its search results to the result list? If the core search only searches webpages and I want the search to also search products in the e-commerce module, how can it add the product search, and its contents, to the original search method's return list? Is that even possible?
Ive been looking at reflection a little bit, and it seems to be useful with running module code from within the core, is that correct?
I have no experience with this kind of stuff, so a push in the right direction, and/or links/guides/tips would be very appreciated.
What you're looking for sounds very much like a plugin-based architecture. I would research some different open source projects and see how they do it, find the one that most similarly resembles what you would like to do, and use their methodology to design your CMS.
One of the largest open source, plugin-based projects is Eclipse, but I would look at some others as well.
You may also do some searches on Google for "component pattern", "module pattern", and "plugin pattern".
I agree with Topher in general.
In the context of ASP.NET and the example you gave, I think the best approach would be for all your modules to implement their own search logic, and expose it through a method. Then the search result would call the method to get the results from all components/modules in the system that implement search.
Generally you should have some kind of framework for the core system and components should be abstracted (interfaces for common functionality). An easy rule of thumb is that "a component gets called, while a framework calls components".
Since the search would be implemented differently depending on the component, it's the job of the component to implement it and the job of the framework to call the implementation.
As an end note, I think you should have an architecture for the whole system before you start thinking about concrete examples, as Topher said.