Think about a "watch" mode for dealing with content

[dazinator]

This might be an alternative approach for the problem of updating client side files to #38

Similar to gulp-watch, think about whether some sort of watch mode that will make DnnPackager "listen" for changes to client side files (js, css etc) in a project (new files, modifications, deletions) and automatically deploy an incremental package update containing the change to the dnn site.

For example, if the developer installs a package:

1. Install-Module [SiteName]

And then they want to "sync" changes to content files, they would do something like

1. Watch-ModuleContent [SiteName]

This would start DnnPackager "watching for file changes in the project.

1. Developer would change somefile.css

DnnPackager would detect the change as it's watching.

I then need to think about the best way to deliver that change to the DnnWebsite. The two approaches would be, either by some way of installing incremental zip packages, or, bypassing Dnn completely and doing file modifications directly in particular dnn folders.

Could I deliver incremental updates purely using zip install packages? If I install a newer version of the install zip package without the assembly dll, does Dnn then delete the original assembly / dll that was installed from the older version of the package (i.e as it works out is no longer part of the module definition?)

This idea needs some more thought and research.

[david-poindexter]

Interesting ideas! I would propose doing the "sync" via direct file manipulation, but it needs to be rock solid so that there is no fear of it just not working right and causing "versionitis" sorts of issues. This would also need to be an "optional" way of developing. I think it would be extremely useful when developing SPA modules, but for traditional user-control based module development, it could be a nightmare due to the reliance on code-behind (compiled).

[dazinator]

Yup I agree.

One thing about the direct file manipulation also is that it implies syncing files based on your project structure, but actually those files can be installed to completely different locations within dnn site - based on the package manifest and the logic of the dnn installer. So if I do go down the file sync route, i'd have to make it clever enough to infer the correct locations of where those files should actually be copied to within the Dnn website folder structure, and even though I might be able to do that (by inferring based on the manifest file), i dont like it because it breaks encapsulation, as that knowledge sits within the dnn installer, so if the dnn installer changes in the future - say perhaps it changes the location of where skins are installed to, then this feature may break. I'm aware changes of this nature are not the norm for dnn, but still i don't like it.

I think for now i will stick to DnnPackager producing and installing install packages only, so unless this feature can be achieved via install zips i'm not interested for now! :)

[david-poindexter]

Again great thoughts. You are technically correct. In my opinion, this is where "best practices" may need to win. Though it is technically possible via the manifest to define a file destination different from the module file origination folder, it is not a "best practice". Perhaps there are edge cases where this needs to be, but for the most part, developers should structure their module code as it will be within the DesktopModules module folder. Do you agree?

That said, it seems like it may be too slippery of a slope to go down and perhaps we should just stick with the basics for now. ;-)

[dazinator]

I agree that generally the structure should be the same. If your package is a module then its under desktopmodules, if its a skin package then its under portals/[x], if its an auth provider it might go somewhere else etc etc but aside from the target folder the structure should be the same in the normal case. However i think what we are describing here is just a general file sync utility that need not be anything to do with dnn. I think it would be useful for spa developers but i think this kind of tool should probs be developed as a seperate tool / package. Non dnn developers could also leverage such a utility. In fact their might already be a nuget package or similar tool out there to do this havent checked yet! :)

[david-poindexter]

Agreed.