There is one other item of particular interest to some that came out of our core team chat. That item is regarding the scope of what I'll call the “Core DataProvider” for lack of a well defined term. Each private assembly requires a DataProvider for each supported DBMS. The “Core DataProvider” is the one that facilitates the guts of DotNetNuke.... rather than, say, a PA. The term could also encompass a particular DBMS implementation (e.g. “mySQL Core DataProvider“) or the abstract contract for any DBMS implementation. Enough with definitions.
There has been considerable discussion within the core team (and without) about building DotNetNuke “lean”. By that I mean abstracting wherever possible to create looser coupling, thereby allowing other developers to extend DotNetNuke in ways which will not necessarily be impacted by upgrading (e.g. PA's). One simple way to initiate a change like this is to take all the current “default modules” and build them as their own PA's. This is a good idea in concept. But it has complications.
For whatever items will continue to “ship” with DotNetNuke (including default modules) a 3rd party developer of a DBMS DataProvider would have to provide support. The more instances of actual DataProvider components are separated... the greater the support responsibility and complexity for any 3rd party provider. However, the fewer the instances of actual DataProvider components... the greater the likelihood of frequent change and thus increased support responsibility and complexity for any 3rd party provider. Hmmmm.... a balancing act? Third party module developers will always have their own DataProviders and support RDBMS's based on market demand for their tools. But the conundrum for encouraging and supporting 3rd parties to implement the DotNetNuke Core (!) on different DBMS platforms is different.
A solution approach which is on the table is to separate the current default modules from the rest of the core into a single PA. This would provide a compromise between flexibility for continued development and support requirements for “Core DataProvider” vendors. So what is now one “Core DataProvider” would become two. Both shipped with DNN. But the business logic required for the current default modules would no longer be embedded in the DataProvider which should rightly contain architectural functionality. And improvements to the default module collection could proceed on a separate track from the true core.
This is the current train of thought. But, as I stated earlier... it is tabled until Beta II is released (as is scope for 2.1). Until Beta II is out the door we won't even discuss... juking with DataProviders.
re: Juking With DataProviders 2/10/2004 7:12 PM
I think each PA should be separated into its own separate PA. Yes I agree that the has its complications but I also feel that its benefits outweigh the complications. I have seen numerous posts on how to update existing modules but many users do not want to perform the modifications as it touches the core. Separating these modules into there own PA will enable many more users to become involved in the project. IF someone wants to improve the HTML module they do it and submit the PA. NO need to worry about recompiling the module PA. This would be a good place for new people to get included and the core team can just work on the core
My .02
Bert
re: Juking With DataProviders 2/11/2004 2:18 AM
I agree with Bert. The standard modules are great starts, but simply cannot provide for every littl nuance a developer requires for a client. Even if Core decides not to do it, it is already being done, why not make it official? Focus on the framework, and keep it private.
re: Juking With DataProviders 2/11/2004 11:03 AM
I also think they should be in separate PAs, if only to allow as lean a system as possible. Nobody uses ALL of the default PAs. There should be an uninstall process for ones that aren't necessary. That will also allow for complete replacement of modules that have improved over the default ones. No duplication.
But beyond that, I also think that the admin modules should be pulled out into their own PAs as well, why not allow modification and improvement to the host and admin modules without effecting the core.
re: Juking With DataProviders 2/11/2004 11:57 AM
Make one separate provider for the standard modules.
In the long run ther will be enough with providers and dll's. If someone will change a standard module its easy to copy parts and make a new seperate one. Maybee the design for multilanguage solution have impact on the question to. If too many dll's it will be hard to maintane the application. With 40 modules it will bee 82 dlls with one database. 166 with 3!
Jan O
re: Juking With DataProviders 2/12/2004 2:35 PM
I agree,
for example I'd like to change a lot of the default modules to avoid excessive postbacks/roundtripping eg when expanding a faq item, since all version4+ browsers can handle the javascript to do this.
Now I could take a copy of each default module and release as a new module or PA and disable use of the standard module within my site, that way I could take updates of the core without breaking my mods, but would be better to submit changes to core mods.
re: Juking With DataProviders 2/12/2004 11:15 PM
I definately think all the core modules should be made into seperate PA's. I am also for the core administration modules being made into seperate PA's. This would allow seperate modules to be updated without updating the core.
Plus, with certain modules it will allow more flexibility. For instance, I could write a customized login and registraiton page that uses a company authen database, while at the same time also store the user information in the DNN user database to maintian referential integrity, and still use the standard DNN roles.
S. Shawn Mehaffie.
P.S. Make the tags for the Privacy Statement and Terms of Use definable for each portal. This is the only place where text is hard coded and by storing the text in the database the portal can easily be used for web-sites in other lanquages.
re: Juking With DataProviders 2/12/2004 11:18 PM
Another advantage of seperating all the core modules to PA's is that the core dll would be smaller and each module DLL would be smaller. That means that the memory usage would be better managed, since only the core modules on the page would be loaded into memory. Plus, the smaller the assemblies the faster they compile and run.
re: Juking With DataProviders 3/12/2004 3:27 PM
Separating admin modules from the core is excellent idea. It would make many admin's life easier.
Mine registration is for example heavily modified and localised - upgrade is becoming a major undertaking.
I yearn to move to 2.0 but fear the problems involved in that move and subsequent (frequent) core changes and upgrades.
re:Juking With DataProviders 4/10/2005 6:44 AM
^_^,Pretty Good!