CSMVP.Common.DLL

Coordinator
Jun 29, 2006 at 6:24 PM
Should we have a common DLL for these projects for helper functions like putting an email on the queue?

I think it would be good to collect functions that are likely to be used in many CSModules.
Coordinator
Jun 29, 2006 at 6:25 PM
Also of course in hat DLL helper functions for reading .config?
Coordinator
Jun 29, 2006 at 6:39 PM
Why should we read configuration files?
Also we don't need to write code to put emails in queue or for many other situations.
This isn't necessary in my mind at all.
Coordinator
Jun 29, 2006 at 7:00 PM
Both my modules needs to read config files.

In AutoCreateSmarterMail, I need to let the admin fill in the first part of the http URL for his SmarterMail intallation (to find it's webservices), his email domain (since SmarterMail supports multiple mail domains) etc

In NewUserDefaults I need to let the admin specify what to set the different settings.

In AutoCreateSmarterMail, I'd like the admin to be able to get a notifiation when new mailboxes are created, if errors occurs etc, and that configuration would be in a .config file.

Other common functions could be to write to CS's exception log so it shows up in the reports.

Developer
Jun 29, 2006 at 11:53 PM
I'm with J-O on this one. I updated my AutoMedia module to read the default dimensions of the rendered <object /> from a config file; I think a common assembly with helper classes/methods would be a useful thing to have, definitely.
Coordinator
Jun 30, 2006 at 1:07 AM
Why you guys don't use XML attributes?

CSModules has a definition for itself. A part of this definition is it uses communityserver.config <CSModules> section for configuration. Take a look at Teligent employees CSModules, they used this approach all whether they wanted to send a long text (as HTML text) or an integer value.


I think this is a wrong approach to add separate configuration files. As probably we'll want to add all CSModules in one single DLL, having separate configuration files isn't user friendly and this is another reason.

Generally, it's not acceptable by my mind ;-)
Developer
Jun 30, 2006 at 1:34 AM
Dude, you're a genius. Not that I was suggesting independent .config files - but your post just made me realise exactly how the <CSModules /> element is processed. Certainly easier and more intuitive than adding extra configuration sections to web.config.

After a bit of digging, I've realised how I should be defining my attributes. You've converted me!
Coordinator
Jun 30, 2006 at 12:27 PM
Keyvan,

I left my thought's on having separate .configs before coming with the idea of a common DLL. When I said it should have functions for reading .config, I meant the existing config files (i.e. communityserver.config). That is adding sections if needed to them.

But what you're saying about using attributes in the <CSModules /> section sounds great to me. Didn't think about it that way. :-) I am with you on that one.

But the Common DLL idea was not just for reading configs, but to act as a helper resource for things that might be done in more than one CSMoule. I gave the example with putting emails on the queueu, but there are probably others.

Let's say hypothetically that the API for working with the e-mail queue would change in a future version of CS, and we have i.e. five CSModules that uses this functionality. With a common dll, we just change the code in one place. The same could apply for a common exception handling.
Coordinator
Jun 30, 2006 at 2:16 PM
J-O,

I'll try to write a sample code in my one of my modules to see how can you use configurations ;-)

But about DLL. We want to work based on CS APIs to make a CSModule so it's not logical to leave CS APIs and write codes directly even if they change the structure. In that case we have to upgrade our codes.

Due to software developing logic what you say is not common, I think. CS APIs themselves are a common way to do things.
Coordinator
Jun 30, 2006 at 2:31 PM
>>But about DLL. We want to work based on CS APIs to make a CSModule so it's not logical to leave CS APIs and write codes directly even if they change the structure. In that case we have to upgrade our codes.


Due to software developing logic what you say is not common, I think. CS APIs themselves are a common way to do things.

-------------------------------------------

Well, I guess it's a matter of opinions :-) IMO it's not that unlogical if we think of the CSModules as a package (a packaged product, like the MVP CSModule Pack 1, we reuse common snippets of code that is written on the CS API). On the other hand I can understand that it would be a little like building a framework on top of the CS framework. It might or might not be what we want.

But I have no problem to not use a common dll depending on how we look at the CSModule project. Also depening of what functionality that would go in there.

Just an idea to streamline some stuff and make it easier to manage.



Coordinator
Jun 30, 2006 at 3:57 PM
I said it in the past, CSModule has a definition. We can't go out and do whatever we want.

In my opinion and what I have as my point of view for CS APIs, it's not logical at all to do this.

Building a Framework based on a Framework which itself has been created based on .NET Framework! Also I think what you mean isn't a Framework, it's just a set of some snippets which are written before.
Coordinator
Jun 30, 2006 at 4:51 PM
Ok, let's just agree to disagree ;-)

If no-one else has anything to say about it, we'll skip the common dll.