I've been looking for tutorials on making modules for DNN, and all of them seem to suggest starting from a huge template and then adding what you need to it, but I'm sure there is a way to build a very small, lightweight module with just the barebones. Just use an ASCX view, and show it on the screen. What is the simplest hand-written "Hello World" DNN module? If you really do need a whole lot of extra stuff in a module for it to work, what is the cleanest way to get a module template?
Background: I've come from front-end development, and I'm looking for a way to package my front-end scripts and styles together, then just use a single file as an AJAX endpoint to query to retrieve the data.
Depending on your DNN version, there is an easy way to create a simple module within DNN itself.
When you go to "Host > Extensions", there is a button with something like "Create new module". Fill out the fields and it will create a module for you that you can use like any other.
When the module is added to a page you can edit the source code (C# / VB) in the module itself.
This is the fastest way to create a basic module. But I would still recommend the template from Chris Hammond. It is slightly more complex but will be easier to maintain and can be packaged as a standalone installer for other DNN installations.
Related
I want to use ReactJS for the front end of our new system.
The back end system (in C#) has different modules which can be toggled on/off. Each module has its own set of DLLs, meaning the product can be "shipped" without unnecessary module DLLs. "You need chat functionality? Here's the DLL, drop it in your bin folder, good to go!"
Each DLL is pretty much standalone with no dependency on an other, apart from it's main parent abstraction.
I would like to know, is it possible to create something similar in a React front end? I don't want to have hundreds of react components listed with a bunch of 'if' statements to show/hide them.
I would like each module to be responsible for its own rendering & actions. Adding a brand new feature would be as easy as 'building the extra module' (not updating the 'core' system files to tell it about the extra module).
Gah, I hope that makes sense! Could anyone point me in the right direction? Is this a fools errand? Is it achievable?
Thank you in advance.
This is more question of how to split your frontend code than react specific question. Good news is, it's certainly possible. Take a look at webapack - bundling tool often use with react. I am not sure how exactly modules and DLLs work in C#, but I imagine you have some way how to include different js bundles into them. If so, webpack will help you create these bundles.
I'm making a module to import CODA files. It is a Belgian banking standard. I have seen around on the internet, and as of now, there is no existing module for DNN. There are snippets here and there and there's ODOO, but I need it in DNN.
I'm not new to programming, but I am however new to web dev. I am trying to first import the file and then parse it. However, I can't seem to find any straightforward way of importing it. I tried to see the code here but was not able to adapt it for my need.
How to parse a text file with C#
Any help is appreciated.
You probably will need to create your own module to handle such specific requirements. There are tutorials out there, but I'd start by either create a simple module at Host > Extensions > Create new extension within DNN itself.
Or use the Christoc's Module Template.
A third but more ugly solution would be to create a standalone aspx page and iframe it.
As we're making our initial move into DNN and setting up projects, I need clarification on the Web Application Project model for creating DNN modules.
Should/can all modules live inside one web application project? Or, should each module be its own WAP?
What would best practices dictate for the project structure in the solution containing DNN modules?
You can do it either way. I've heard people do it both ways.
Do your modules depend on each other at all? If so, you might want to keep them all in the same project so if one gets built, they all do.
If not, I like to keep each module in a separate project just from a separation standpoint. Each module/project will be smaller and easier to manage. Just build the project and it will give you the install file.
It's just a personal preference. I know a lot of people create one solution, then keep a separate project for each module.
in qooxdoo desktop you usually have to develop using the SDK and then "build" your app.
Is there a way to generate something like a qooxdoo.js file with the whole library inside so that you can script script it as you like (like jqueryui or dojo)?
Actually it could be nice to have every widget loaded at runtime like dojo's require("dojo.button") but both the approaches would be nice, just avoiding the build phase.
I hope the question is understandable :)
Thank you everybody!
Don't use the output of the build job to run your code as you develop - as among other things - will minify your code and make debugging very difficult.
If you want to code freely without needing to rebuild when you reference new classes then source-all is the build job for you.
In the root directory of your application, type:
python generate.py source-all
If will include the entire framework in the HTML file generated (you'll find it under source/index.html). This would work well if you are composing the UI from scratch and referencing many new qooxdoo widgets with each browser refresh.
If you add a completely new class of your own, you will need to run the source-all job again to include it.
I use the source build job however for a few reasons:
Habit: source-all didn't exist when I started using qooxdoo
Speed: You can notice a bit of lag it when you refresh the browser to view
your app
References: For a mature app, enough of the framework is
included in the application and its rare to add a new reference and
when you do, its probably in a new class of your own which would
require a re-run of the source job anyway.
I suggest you also look at Default Action Jobs as all the possibilities are explained in detail. Hope this helps.
Please check that thread for a detailed answer: http://qooxdoo.678.n2.nabble.com/Using-qooxdoo-desktop-without-having-to-build-it-td7585015.html;cid=1387453759247-228
I am working on DNN 4.09.03. I want to modify the look and feel of a links module. I know how to change the outer looks with containers, but I want achieve a mouseover effect for the links itself.
Looking closely it appears that the links are placed into a table datacell. I want to set the background of that cell to and image, and on mouseover swap it for another image. Can this be done with skinning?
If not, I need some assistance in extending/customising the links module source. I need to know how to set up the development environment to do this first. I have the DotNetNuke solution (with source code) working in VS2008. How do I integrate the source of the links module, so i can customise it (and rename - maybe mylinks)?
I don't think you can do this by containers. If you can do it by any chance, I bet doing it by modifying the code is easier. You have to remember that you might have problems upgrading the links module in future if you modify it.
Just add the Links module to DNN VS2008 solution as a web application. You can do whatever change you won't to do in it. And then use a nant script to just package it and copy to DNN/Install/Modules folder. And then hit the DNN installation URL:
http://<dnn_url>/Install/Install.aspx?mode=installresources
Alternatively you can write some post-build commands in VS2008 it self to copy stuff. Have a look at the existing modules and where each different part files of a module (.ascx, .dnn, .sqldataprovider) is stored in DNN after installation.
This is possible with some creative CSS and maybe even a little jQuery - i did a lot of this sort of thing for the Blog module without having to touch the core module -