I'm coming from a ASP.NET Webforms application. I'm using a third party control from which I created a descendant to set some default values. I then registered that class as a tag and I'm ready to go without setting the options ever and ever again.
Now I want to go to a MVC based application. I'm curious how to do that. Is there a way to "subclass" an extension there, too?
Edit: Done this with DevExpress MVC Grid extension
The third party control is another story entirely, and the vendor would have to release an ASP.NET MVC version.
However, in simple terms of creating re-usable code in ASP.NET MVC one option you have is to create custom HTML helpers. It basically ends up being a method that you call which outputs markup, which can be made fairly powerful fairly quickly.
There are a lot of resources on various HTML Helpers, and keep in mind that the "documentation" you find on Google has changed significantly over the versions of ASP.NET MVC, so take care to ensure you're not limiting yourself to "an old way" of doing things. There are also a number of commercial as well as free products and open-source projects with handy helpers and extensions.
The third party control uses a Settings class. I have created a new settings class, which sets the default values in it's constructor.
Then I have written an extension method that reads like this:
public static GridViewExtension GridView ( this HtmlHelper html, Action<CustomGridViewSettings> settings ) {
var mySettings = new CustomGridViewSettings();
settings( mySettings );
return html.DevExpress().GridView( (GridViewSettings)mySettings );
}
Usage is then analog to the samples online #DevExpress page and I omitted the sample class here.
Related
I have a new multi-tenant web application in ASP.NET Core 2.0, single DB.
I've established a method of determining a particular request's 'TenantId' by examining the domain in a simple piece of middleware.
I've also established a DataContext which applies TenantId filters to applicable tables as needed.
The last thing I'm unclear about is how I can differentiate Views/partial views based on the TenantId whilst sharing the controllers.
I think some scheme where the app first looks in some kind of TenantId sub-folder for the customized tenant's view and if it can't find it, it goes through the regular steps to locate the view... might work okay? Is this a reasonable approach? In other words, it should use the specialized tenant view if it exists, otherwise use the default view.
Would this involve building a custom view engine of sorts?
I've tried something similar with tenant based Html fragments, but it was a pain maintaining it, so I'm looking for something more straight forward on this project.
I'm open to other suggestions of how to implement this functionality as well.
Thanks in advance!
You don't need a whole custom viewengine, you can implement an IViewLocationExpander to make it check various locations for views.
In my project I have mutliple tenant support with both shared themes and tenant specific themes. I can override any view by dropping a copy below the theme folder, ie the main view could be Views/SiteAdmin/Index and I can override it in /pathtothemes/themefolder/SiteAdmin/Index
You can see my implementation of IViewLocationExpander here.
How you register your IViewLocationExpander is like this:
services.AddMvc()
.AddRazorOptions(options =>
{
options.ViewLocationExpanders.Add(new cloudscribe.Core.Web.Components.SiteViewLocationExpander());
})
.SetCompatibilityVersion(CompatibilityVersion.Version_2_1)
;
What I want to develop....
I am currently developing a SaaS-solution (Symfony2) to build HTML-presentations or better slide shows. Users can log into an administration UI and create presentations. This presentations can be played later. A presentation consists of elements. The elements can be images, texts, videos, pdf and more.
This element types should be encapsulated from the user interface. So extern developers can develop such new modules (element types) with defined interfaces and inject it into the system.
If a new module is finished, we move it to a specific directory in the symfony2 directory and the system detect the new module. No hardcoded-changes in the administration ui system should be neccessary.
Each module has a own "product-number". So we can use a database to enable or disable modules for different users.
What functions must be implemented by a module?
In the administration ui the user has the possibility to create a presentation and add elements of different types (the modules). User sees a timeline with the elements. When he clicks on an element, the editor for this element will be shown under the timeline (Parent-Child-View). Each module has different editors. A text-module needs other configuration-possbilities than an image-module.
So, in admin UI we need functions to edit elements:
createNewElement() creates new entry in the database (module has own tables, e.g. mod_text_elements)
renderEditorView() generates HTML which will be shown in the administration ui with module-specific inputs. E.g. image-upload/crop, WYSIWYG-editor, ...
saveEditorInputs() the module needs to handle the data entered in the editor and save it to the elements entry in the database
deleteElement() to delete an element
The output for the presentation:
Later we want to play this presentation. So a loop goes through the presentation elements and asks the modules of the element what and how to show it.
renderPresentation() to render (HTML) an element for the presentation
Database
I've made a little er-diagram of a possible solution to save the information about modules and elements in a database. The yellow entities are module-specific tables.
How to realize this in Symfony2?
My frist idea is to define an interface which have to be implemented by the modules. But which class has to implement this? Controllers?
Are modules = bundles?
How to realize the View-in-View of the editor? The editor of the module (e.g. renderEditorView()) should be viewed in the user interface of the administration ui.
I'd do it by hooking in to the EventDispatcher Component.
Your 'Master' Controller would define a set of events which correspond to the standard CRUD actions you've defined above ... onCreateNewElement(), onRenderEditorView(), etc. You'll probably find a dozen more to provide hooks for as you build your application (allowing plugins to add tools to a toolbar for example).
You'd define a Service (this doesn't HAVE to be a Controller Class), which looks for new 'modules' and adds their correctly-named methods as listeners for your custom application events.
Are modules = bundles? Well, that's entirely up to you. Are you going to provide a method for users to 'install' new modules specifically for your application? Then what a module needs to look like is entirely up to you. Are you going to slip Composer into the mix and allow modules to be installed that way? Places a couple of constraints on the structure, but still pretty much up to you.
How to realise the View-in-View? Again, that comes down to exactly how you define the interface for your 'Event Plugins' and what kind of access they have to resources like TWIG and YAML config.
The question you're REALLY asking is How do I add functionality to an application without hacking existing code ... and the answer is EventDispatcher. The rest is up to you.
There is another way to expand codebase with custom "modules": Dependency Injection Tags.
It works like this:
You create core of the app, which implements basic functionality and registers compiler pass which handles code extension
Modules can be part of the core app OR moved to external bundles
Each module must be registered in DI container with tag supported by your core app, so can be handled properly (adding menu positions, new element types as in your example)
Symfony DI compiles all services and stuff so all modules are available within app instantly (so you can for example iterate over collection of prepared items without need to dynamically building it)
In my opinion EventDispatcher is better for handling real-time actions, like sending notifications when new entity is created (e.g. controller/service dispatches event, some bundle subscribes it and send notification).
When you want to extend core I would recommend DI tags. Of course you have to build all the core (interfaces and whole architecture) so modules can extend existing services' data, then you only use your services.
Whole Symfony full-stack framework is based od this tags, so there is a lot of existing code to investigate for getting the concept.
Please let me know if it's clear enough what I wrote and what's in Symfony docs. If you need some additional info, I'll try to help.
We are building a Page with dynamic functionality using ASP.NET + Sitecore 7.0.
Is it practical and appropriate use Sitecore templates for:
SQL Stored Procedure Name to be invoked
JavaScript to be invoked
ColumnNames to be used etc (related to coding customization)
Or should these configuration properties remain inside the ASP.NET Project itself?
What is the primary purpose of Data Templates in Sitecore?
Are they for developer customization or customer-level customization?
The purpose of a data template in Sitecore is to define the set of fields for content items which inherit from that template. - Think of a data template as a class and the content items (pages) as instances of that class.
Templates are usually used to define the user-editable content of pages within a site, that being said you can have items to store information which is not managed by regular content editors. The question is where do you draw the line between things which should be put into Sitecore and things which should be a part of the solution. My advice is only put things in Sitecore if they need to be there. If you have to have the ability for editors or admins to configure those settings/properties.
I would say that putting SQL/ColumnNames is probably a bad idea unless you are building some sort of report builder interface in which case it may be essential?
Likewise with placing JavaScript into Sitecore; this can be OK in moderation (e.g. snippets of analytics code which content editors may want control over?). If you're placing whole libraries of JavaScript into Sitecore, you're probably doing it wrong.
One final point to note is findability/re-factorability of code: if you have code spread between Sitecore and your solution, it can make it very difficult to maintain as it is difficult to get a complete overview of code involved.
I am looking to create a widget that can be used with other solutions. The widget is a competition widget that can be placed in different parts of the site.
What is the best way to do this? Should I create a new solution to hold this in?
Create a new class library project (you can have it within your current solution if it suits) and create your server controls in there. You can then reference this library from whatever websites you need.
You need to create a Web Control, not a User Control, if you want o use it in other projects. This question details the different control types, you may find it useful:
What is the difference between UserControl, WebControl, RenderedControl and CompositeControl?
Here is relatively simple tutorial on creating a custom WebControl:
Create ASP.NET Server Controls from Scratch
And here some more advanced example from MSDN:
Developing Custom ASP.NET Server Controls
It depends if you will be using it in other solutions really. If you are, then if might make more sense to create a new widgets solution with each widget in its own user control and compile it into an assembly.
Then you just reference that assembly and use it in your markup.
If your widget is only going to be used in a single solution then I wouldn't bother with the above. Just create a user control in the same solution.
As opposite of some answers, you should create user controls with embedded resources.
It is complex to do it, but once you do you will be able to develop controls like RadControls from Telerik.
If you open up their controls you will see that they are all embedded resources on the Telerik.Web.UI.dll.
Here is an old answer of mine that shows how to load the control and how to handle embedded resources (virtual path provider)
Unless you have a good reason to do so (like creating a generic control as a calendar, grid or something like that) don't go this way, it is dark, complex... But as you can see it might be worth it, Telerik.Web.UI is the live example that this can work out.
I have written a data browsing library that is being used in several projects. The library or component includes some classes as well as some ASPX pages.
Until now, we copy all the files into each project to reuse it, with the obvious drawbacks and updating nightmares. I want to encapsulate all the library into a component that the projects can use.
What's the best way to do it? I know I can create a DLL, but I think it's only for the classes, don't know how to go with the ASPXs pages.
We are using Visual Studio 2008 and Framework 2.0
Thanks in advance
This is a perfect case for custom controls.
Change the pages into user controls, and embed the new user controls back into pages that have nothing in them but the reference to the user control.
Once that works, you can change the user controls into server controls, little by little. They will be composite controls, as the user control already is.
There's a trick you can use at this stage: I'm not recalling the details this late at night, but someone else will fill those in: when ASP.NET compiles a page, it first "compiles" the markup into source code, then compiles the source code. You can get ASP.NET to not delete the temporary source files. That allows you to copy into your project code that creates precisely the same HTML as the user control did.
The difference will be - it's now your code and you can refactor it as much as you like, or even include it in a custom control library.