Design ideas please

[David]

Hi all,

I have built a CMS in C# (.NET 1.1, I started it ages ago and it works well,
so there is no point yet in upgrading it)

I have URL Re-Writing which is handled by the global.asax rather than a
httphandler. The idea behind all the functionality of the CMS is that it is
as portable as possible, i.e. it will be able to be hosted on whoevers
webserver, wether they allow isapi filters or whatever. I have also coded it
to work as much as it can on MONO though I have not tested that side yet.

I have a multi-tiered architecture. I have a database layer that has been
written to interact with different databases should it need to, for example,
Sql Server, MySQL and even Access. I guess at one stage, I will make it work
with Oracle, Sybase and other types of DB, as well as using XML as a data
store. However, this is not my question...

I have my CMS code class, my page code-behinds inherit from this class
instead of system.web.ui.page. This keeps all of the CMS logic out of the
way.

Each page is a templated page. The templated page has placeholders put in
there for the things like the wysiwyg editor. It is the template that is
inheriting from the CMS class.

When each page is created by the CMS, it has a custom-properties feature.
This could be used for anything, for example, to load a different
stylesheet, use a specific picture or whatever. The custom property is
exposed to the higher level page so that the page programmer can use them.
There is no limit to the number of custom properties a page can have.

What I am currently using the custom property mostly for though is to
dynamically load User Controls. I have used this method on other CMSs as
well as my own with great success.

Now, I want to create like a plug-in architecture. My first plug-in will be
a shopping basket, but don't let this put you off. It is the architecture
that I need rather than the basket itself, as I intend to create a number of
plug-in items, once I have the architecture resolved.

I could use a user control to host the shop, but then each item in it will
only be able to be referenced by parameters on the URL. I wrote the
URL-ReWriter to get away from that. In this case, I want each product in the
shop to have its own unique URL, done via the re-writer.

The way I am thinking this will work is to have a control that is loaded (if
available, i.e. the DLL for the shop is in the bin folder) and it will show
itself in the administrative side of the interface. Each product will
basically be its own regular CMS page (to allow for url-rewriting plus be
searchable without having to use a spider on the site) but somehow linked
into the shopping system (add to basket, checkout, stock availability etc.)

The control will also interact with the page itself, for example, to put a
"You have X items in your basket - Checkout" link.

The control will also inject itself into the CMS based menu structure.

As I said above, I am not after the shop itself, I am after an idea to
create the plugin architecture. I am using the shop as an example, but many
of the features will be used by other plug-in ideas.

There is quite a lot to think about here and you might not be able to answer
all of the question, but if you can answer only even a little of it, it
would help tremendously.

--
Best regards,
Dave Colliver.
http://www.AshfieldFOCUS.com
~~
http://www.FOCUSPortals.com - Local franchises available

 

[Nathan Sokalski]

Idea #1: Upgrade to 2.0 or 3.5, because there is a point to upgrading. The
point is that many webhosts will soon stop or already have stopped
supporting 1.1, and I wouldn't be surprised is a future version of IIS
didn't support it (at least not by default without some extra effort and
tweaking), so you'll just be digging yourself into a big hole by using 1.1.
Also, a very important feature new in 2.0 is Master Pages. The importance of
Master Pages is consistancy as far as layout, as well as code reusability.
In fact, if almost sounds like the functionality you were trying to achieve
with your CMS class is pretty much what the MasterPage is for. Another
important reason for using 2.0 is support for ASP.NET AJAX, which is
becoming a very significant part of web design. I know you say there is no
point to upgrading, but I think you are just trying to procrastinate, and
you are only going to regret that in the future, because 1.1 to 2.0 is one
of the most important steps in ASP.NET development. The differences between
2.0 and 3.5 are much less significant and important, so there is rarely a
need to do that upgrade if you don't want to, and on most sites, the code is
pretty much the same anyway, so when the time comes, it won't be a problem.

 

[Patrice]

Hi,

If I understood the questionb you may want to see if MEF could fit your
needs (http://www.codeplex.com/MEF).

 

[David]

With respect, I didn't ask for a lecture about upgrading my version of .NET.
There is a valid reason that I am still writing in 1.1 and I am not yet
ready to upgrade this project to 2.0 or above. There were breaking changes
in 2.0 and if I was to upgrade, I would have to go through a heavy testing
program to ensure it works. I started developing the CMS a few years ago and
it has become quite a powerful tool, many thousands of lines of code and
works very well (I have a page render time and have seen other CMS with page
render times and mine is MUCH faster, due to the way I have thought about
its implementation)

I will upgrade it, but at this point in time, I have a heavy workload and an
upgrade will just add to that.

I have been programming in 2.0 for a while now and have started with 3.5
about 6 months ago. I know about master pages, but I wanted to write my
system the way I have written it, mainly for the knowledge it has given me
in learning and overcoming specific issues. Master pages didn't really fit
my model very well.

Ajax is all well and good, if my CMS needs to implement it, but mostly, CMS
is for CONTENT, not usually for dynamic forms. When the time comes, it will
support Ajax as well, probably by upgrading it, but as yet, it doesn't need
it.

However, the solution for my plug-in architecture will still be (mostly)
transportable and that is still an open question.

Patrice has mentioned MEF as a possible solution. The first thing I saw when
I went onto the codeplex site was MEF is for .NET 4.0. While it might work
for me, I will look into it, but it could be just too much for what I need.

I am after ideas or pointers to being able to write my plug ins. I have been
thinking about this for a while and have decided that where a plug-in can
use the CMS to store its content, it will... but how do I get it working? I
have been considering Interfaces, but will an Interface do what I need it to
do? Are there any pitfalls? If I go the Interface route, I could do with
some ideas for how to push the plug-in into my CMS, for example, into the
URL-ReWriter, hook into the page handler etc. (Now, I know you don't know
how I have written my handlers, but if there are any generic ideas that I am
missing that might be able to point me in the right direction, it would
help)

--
Best regards,
Dave Colliver.
http://www.AshfieldFOCUS.com
~~
http://www.FOCUSPortals.com - Local franchises available