Developing Plug-Ins

  • Thread starter Thread starter Joe Kovac
  • Start date Start date
J

Joe Kovac

Hi!

Is there any recommendation how to develop plugin-like Asp.Net pages?
The use case: We have a framework, where you can administrate employees,
customers, etc. Now, customers always want some specific additional
views, which should be integrated into the web site.
How should I organize the web site(s), the solution(s) and the projects?

Thanks

Joe
 
Hello Joe,

As i understand you need to use WebParts. See there http://msdn2.microsoft.com/en-us/library/e0s9t4ck.aspx

---
WBR, Michael Nemtsev [.NET/C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

JK> Hi!
JK>
JK> Is there any recommendation how to develop plugin-like Asp.Net
JK> pages?
JK> The use case: We have a framework, where you can administrate
JK> employees,
JK> customers, etc. Now, customers always want some specific additional
JK> views, which should be integrated into the web site.
JK> How should I organize the web site(s), the solution(s) and the
JK> projects?
JK> Thanks
JK>
JK> Joe
JK>
 
Michael said:
Hello Joe,

As i understand you need to use WebParts. See there
http://msdn2.microsoft.com/en-us/library/e0s9t4ck.aspx

---
WBR, Michael Nemtsev [.NET/C# MVP]. My blog:
http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and
we miss it, but that it is too low and we reach it" (c) Michelangelo

JK> Hi!
JK> JK> Is there any recommendation how to develop plugin-like Asp.Net
JK> pages?
JK> The use case: We have a framework, where you can administrate
JK> employees,
JK> customers, etc. Now, customers always want some specific additional
JK> views, which should be integrated into the web site.
JK> How should I organize the web site(s), the solution(s) and the
JK> projects?
JK> Thanks
JK> JK> Joe
JK>
Click to expand...

Hi Michael,

no, webparts aren't what I am looking for. The customer shall not have
the possibility to edit or customize views.
Our target is to separate work tasks into main tasks (common to all
customers, maybe 80% of the web pages) and company specific tasks, which
another developer shall develop.
So our problem is, how can 2 developers work together easily? How can I
separate company specific stuff (add-on or plug-in like) from the main
application?

Regards,

Joe
 
We've done this kind of thing both with XML files and with reflection.

With XML files you might have a configuration xml file which defines
some links or lists or controls on a page or whatever you want to be
extensible. The XML file will contain header info and the name of the
page to link to or custom control to call or whatever. Then you just
have to modify the XML file based on installed plugins.

Another way, which I prefer, is to use reflection and attributes. Say
you have a customer view and you want to be able to add extra data,
create an attribute CustomerViewExtensionAttribute and you can have
some data in it to control order or header or whatever you need for
your visuals. Then using reflection you can loop through all the
assemblies in the appdomain (usually skipping gac) and find classes
that are marked with this attribute and include them in the
appropriate page. It's really important to cache this information as
the looping through assemblies part is relatively slow.

With code based plugins (non-visual), then an interface may be
preferred to an attribute since you will need it to implement some api
(with visuals they already implement a web control or page).

HTH,

Sam
 
Hi Sam,

thanks for your ideas. I think all of your concepts are good, but they
might take some time to implement. I guess I might use a combination of
them like follows:

Save general information of the plug-in within Web.config (XML). Save
plug-in classes (which I get told about in Web.config) within a plug-in
directory and use some kind of reflection.
The Web.config might tell me, that "JoePlugin" is a calls that extends
the general Plugin class. This class might be under
/website/APP_CODE/plugin/JoePlugin.cs. It would have to implement
functions like: getPluginPagesForMenu() aso.
Do you think that's a good way?
How would I call this class?

Regards,

Joe
 
Joe Kovac said:
Hi!

Is there any recommendation how to develop plugin-like Asp.Net pages? The
use case: We have a framework, where you can administrate employees,
customers, etc. Now, customers always want some specific additional views,
which should be integrated into the web site.
How should I organize the web site(s), the solution(s) and the projects?

Thanks

Joe
Click to expand...

Take a look at the ASP.Net application called DotNetNuke, which uses a
plugin-type framework and, I believe, common practices for doing such a
thing.

www.dotnetnuke.com

Click on Downloads to get the instructions on how to download :)

HTH,
Mythran
 
Yes that would be good. To call the class use
Activator.CreateIntsance and it will give you an instance of the class
specified in your config file.

Also if your plugin api requires several classes,then really you want
to define a factory as the plugin starting point so you create a
factory for each plugin and then once you have the concrete factory
you create the supporting classes. This is exactly how the new
DbFactory architecture works in ADO.NET 2.0.

HTH,

Sam
 
Mythran said:
Take a look at the ASP.Net application called DotNetNuke, which uses a
plugin-type framework and, I believe, common practices for doing such a
thing.

www.dotnetnuke.com

Click on Downloads to get the instructions on how to download :)

HTH,
Mythran
Click to expand...

Hi,

DotNetNuke seems to be a good project. But I neither plan to rebuild it,
nor do I wan to extend it.
I guess my main task will be to create a solution, that uses another web
site as base and link additional web pages into the base web site. Hope
I can make that work.

Thanks

Joe
 
Back
Top