Not sure I'm using the right terminology, but if I have a website, and I make a change to one of the files, the underlying logic C#, whatever, do I have compile the whole application again before I deploy it?
How do I publish a small change?
You keep saying "the whole thing", but you don't really seem to understand what that means.
An MVC application is a Web Application project, which means that it's class files are compiled into an assembly. When you make a change to a class, the assembly that it's in must be recompiled (as well as any assemblies that are dependent upon it) and redeployed.
You don't have to recompile other assemblies that have not been changed, and you don't have to redeploy any unchanged files (like views or css or javascript).
If you have 100 pages, chances are, you probably going to split that up into several assemblies anyways. But even if you don't, it really doesn't take very long to compile even a 100 page web application (the pages themselves do not get compiled, it's only the .cs files). At most this should take 15-20 seconds on a medium powered workstation.
I think you're worrying about something that isn't really that big of a deal. You're probably more concerned about redeploying, but if you setup your publish system correctly, this is a single click, 10 second thing.
That depends on where you made the change.
If you made the change in a .cshtml or similar view file, or other content file (like javascript, css, images, etc.), just uploading the updated file will be sufficient.
If you changed a .cs (or vb, etc.) class however, you will need to recompile.
Related
I have seen Use a single source file for many QtDesigner forms, which is the gist of my question also, - but it simply recommends:
My advice is to use it as Qt way. Use seperate classes and seperate files for each form. This approach is better.
However, I would like to specifically know - is it possible at all to define multiple forms (say, a "Main Window" and a "Dialog with Buttons Bottom") in a single .ui file, and work with them in QtDesigner?
Basically, for an application of mine, I use QtDesigner .ui file to design the MainWindow, and load that from Python (PyQt5) - and it works great. Now, I'd just like to add a window dialog raised on a click of a button, and I'd also like to use QtDesigner for it, but I wouldn't want to maintain two .ui files. I'd imagine, once such an .ui file (with multiple form definitions) would be loaded in Python, the Python code would just set all forms other than QMainWindow to hidden, and then manage when they are shown appropriately.
(I use QtDesigner on and off, so I do not know it very well - however I recall there was some stuff that QtDesigner couldn't do from the UI, but one could do manually in the .ui file, and after such changes, QtDesigner could still deal with them. So, if there is a way to do this - even if it is not fully supported in the QtDesigner UI - I'd love to know about it, or have a definitive answer that it is not doable).
tl;dr
No, you cannot.
Why not?
UI files are intended for individual widgets (it doesn't matter whether they are intended as top level windows or not) and their possible children.
While I can understand your request, it seems more related to a "project" concept than an UI one. That's not the intent of Designer, which cannot imagine the possible extent of your project; and even if that was the case, it wouldn't be very practical: what if your project could potentially have hundreds of windows? Suppose that you have a main window, open your program, but then you decide to close it: your program would be loading hundreds of windows, but use none of them, causing an unnecessary overhead in the program loading.
The concept is similar to the modularization of OOP: not only you just "load" what you actually need, but you also should "split" the project in different files (modules, not unlike python modules) for better maintenance , reusability and overview. What if you want to have two separate "main" UI files for some reason, and, coincidentally, they use a similar dialog? You should copy that dialog every time, and if at some point you forget that step, you might even cause your program to crash as it's trying to access objects that don't exist or have been just slightly renamed.
Furthermore, some interfaces can be really complex, and automatically loading them at startup would be pointless: if you're using the uic module, you're requiring unnecessary parsing of the whole xml tree of the UI, and that would be for every time a new instance for a window from that file is required.
Maybe, someday, developers at Qt will decide to allow "projects" in Designer (which is probably what Qt Creator does, but I've never used it), but ui files will still be individual, as they should.
So, don't worry too much, it's more a question of habit and a slightly annoying aspect: if your project is well conceived, and you also properly name your files, it won't be a major problem and it will have its benefits anyway (even if you don't consider them as you could).
PS: yes, UI files are XML files and can be edited; you could even create/edit an UI file and do things Designer couldn't. But that's just an "unexpected feature" (or smart hack), for which you can never be always sure about the outcome. In future (or just different) versions the parser could be[come] more strict, with the result that your UI becomes completely unusable. That's not unlike editing pyuic files: the programs that use them expect a known behavior (the XML output of Designer), and common, accepted usage. As the recent pyuic file headers (which, I'd like to mark, was added after a personal suggestion of mine) report: "Do not edit this file unless you know what you are doing" ;-)
When you have a server side blazor app and you reference a razor class library directly (at the moment I am using dotnet5) it seems to automatically add the /_content/.bundle.scp.css by adding an #import to the .styles.css. This appears to work well enough at least in debug just by adding the reference and hitting F5.
I see conflicting documentation adding the links manually in many places and they are generally being added in the head as links, not as an #import. I am guessing this is maybe something that has changed since core3. I also have not figured out where the bundled files are supposed to "live" while you are still developing, when you publish you end up with a \wwwroot_content folder, but a development that appears not to exist on the filesystem and actually be mapped onto the \obj folders of the individual RCLs.
In the app I am currently working on the razor class libraries are loaded at run time, so this does not work automatically, for the time being I have the bundles referenced as individual links programmatically added in the head of the _host.cshtml after I copy them from the individual RCLs' obj<BuildFolder>\net5.0\ as that seems to be the only place they exist on disk. I am also serving them with an app.UseStaticFiles out of another folder since I am still unclear on how the inbuilt folders are meant to operate.
When I first figured out that the runtime load was an issue I was able to get confirmation there was not inbuilt support beyond direct references here https://github.com/dotnet/aspnetcore/issues/33284 and I started looking for how to re-implement the existing work-around more properly.
I would prefer this to work as similar to a directly referenced RCL as possible, but I am not finding any information on if the bundles are meant to be referenced globally at all times or conditionally, I do not see any obvious way to get them to be added as an #import programmatically, and I have no idea what the implications of trying to manually create the _content folder from the bundle files found in the various \obj folders would be.
How this is really supposed to work in development and when publishing? Is what i am doing even close or is there some glaring issue I will be encountering down the road?
This is the default MVC 5 project's BundleConfig.
As you see in debug mode, EnableOptimization by default is disabled.
First two bundles dont make any sense to me, because each one will include whole bunch of duplicated scripts (minified and non-minified, including intellisense, validate-vsdoc etc...).
What is the point including all these JavaScript files and have Optimization disabled? Even with Optimization enabled, if I set BundleTable.EnableOptimizations = true;, it still doesnt make any sense to include all of these JavaScript files.
Or, if I set BundleTable.EnableOptimizations = true;, then why would I ever need to have minified JavaScript files at all, they all will be minified, no?
Am I missing something here? Many Thanks.
This Microsoft Blog can explain a lot of what your asking but to sum it up, when you use bundeling asp.net is smart and if your in debug mode it will only include the full .js file so if you have to do any debugging on it you can see the normal code and read it. If your in release mode (BundleTable.EnableOptimizations = true;,) then it only includes the .min.js file as to serve up a smaller more stream lined copy. The other files (intellises, map, etc) are there just to help developers code easier.
As for why you need the .min.js files it is to save on server resources. ASP.Net will automatically do minification for you but that eats resources as well as it is a modertate minification. If you want to save those resources OR do a heavy minification you can make your own .min.js file but you are not forced to include one.
We have been using Yii for building web applications. Once in a while, themes comes to our discussion table.
But, if we have a web application and we wish to change the look and feel only, we may, as well, change the public_html folder, since the structure will be similar.
The only point we see on having themes is for those cases where we may want to dynamically (user choice by clicking on a "change layout button") change the look and feel of an application.
Does anyone uses themes for any other proposes, or configurations?
We use themes to great effect. We operate 6 sites using as single instance of a Yii application. The theme is then selected based on the domain name.
Yes we could have just used 6 different application folders and served them separately. This comes with several advantages though, which you've probably already dismissed if they're not relevant to you, but here they are:
Shared code, updates and maintenance are far easier
Adding a new theme is much cleaner IMO (just a new theme folder rather than a whole application directory)
Global assets, which are then overridden easily in the theme, rather than wiping over them completely, you'r expanding them.
Shared Cache, the whole application caches to a single directory, view cache, data cache etc.
Shared Assets directory, assets are only published once ( although this could in theory be set up in a copied environment)
I much prefer this set up, it looks far cleaner just to override rather than overwrite. Plus really, I can't think of a reason why copying the whole directory would be better than this method, yes there are issues in theming that have to be worked out, but copying the whole source doesn't solve them.
Here is what I'm looking for:
I'd like to separate pieces of functionality into modules or components of some sort to limit visibility of other classes to prevent that each class has access to every other class which over time results in spaghetti code.
In Java & Eclipse, for example, I would use packages and put each package into a separate project with a clearly defined dependency structure.
Things I have considered:
Using separate folders for source files and using Groups in Xcode:
Pros: simple to do, almost no Xcode configuration needed
Cons: no compile-time separation of functionality, i.e. access to everything is only one #import statement away
Using Frameworks:
Pros: Framework code cannot access access classes outside of framework. This enforces encapsulation and keeps things separate
Cons: Code management is cumbersome if you work on multiple Frameworks at the same time. Each Framework is a separate Xcode project with a separate window
Using Plugins:
Pros: Similar to Frameworks, Plugin code can't access code of other plugins. Clean separation at compile-time. Plugin source can be part of the same Xcode project.
Cons: Not sure. This may be the way to go...
Based on your experience, what would you choose to keep things separate while being able to edit all sources in the same project?
Edit:
I'm targeting Mac OS X
I'm really looking for a solution to enforce separation at compile time
By plugins I mean Cocoa bundles (http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingCode/Concepts/Plugins.html)
I have worked on some good-sized Mac projects (>2M SLOC in my last one in 90 xcodeproj files) and here are my thoughts on managing them:
Avoid dynamic loads like Frameworks, Bundles, or dylibs unless you are actually sharing the binaries between groups. These tend to create more complexity than they solve in my experience. Plus they don't port easily to iOS, which means maintaining multiple approaches. Worst, having lots of dynamic libraries increases the likelihood of including the same symbols twice, leading to all kinds of crazy bugs. This happens when you directly include some "helper" class directly in more than one library. If it includes a global variable, the bugs are awesome as different threads use different instances of the global.
Static libraries are the best choice in many if not most cases. They resolve everything at build time, allowing code stripping in your C/C++ and other optimizations not possible in dynamic libraries. They get rid of "hey, it loads on my system but not the customer's" (when you use the wrong value for the framework path). No need to deal with slides when computing line numbers from crash stacks. They catch duplicate symbols at build time, saving many hours of debugging pain.
Separate major components into separate xcodeproj. Really think about what "major" means here, though. My 90-project product was way too many. Just doing dependency checking can become a very non-trivial exercise. (Xcode 4 can improve this, but I left the project before we ever were able to get Xcode 4 to reliably build it, so I don't know how well it did in the end.)
Separate public from private headers. You can do this with static libs just as well as you can with Frameworks. Put the public headers in a different directory. I recommend each component have its own public include directory for this purpose.
Do not copy headers. Include them directly from the public include directory for the component. Copying headers into a shared tree seems like a great idea until you do it. Then you find that you're editing the copy rather than the real one, or you're editing the real one, but not actually copying it. In any case, it makes development a headache.
Use xcconfig files, not the build pane. The build pane will drive you crazy in these kinds of big projects. Mine tend to have lines like this:
common="../../common"
foo="$(common)/foo"
HEADER_SEARCH_PATHS = $(inherited) $(foo)/include
Within your public header path, include your own bundle name. In the example above, the path to the main header would be common/foo/include/foo/foo.h. The extra level seems a pain, but it's a real win when you import. You then always import like this: #import <foo/foo.h>. Keeps everything very clean. Don't use double-quotes to import public headers. Only use double-quotes to import private headers in your own component.
I haven't decided the best way for Xcode 4, but in Xcode 3, you should always link your own static libraries by adding the project as a subproject and dragging the ".a" target into your link step. Doing it this way ensures that you'll link the one built for the current platform and configuration. My really huge projects haven't been able to convert to Xcode 4 yet, so I don't have a strong opinion yet on the best way there.
Avoid searching for custom libraries (the -L and -l flags at the link step). If you build the library as part of the project, then use the advice above. If you pre-build it, then add the full path in LD_FLAGS. Searching for libraries includes some surprising algorithms and makes the whole thing hard to understand. Never drop a pre-built library into your link step. If you drop a pre-built libssl.a into your link step, it actually adds a -L parameter for the path and then adds -lssl. Under default search rules, even though you show libssl.a in your build pane, you'll actually link to the system libssl.so. Deleting the library will remove the -l but not the -L so you can wind up with bizarre search paths. (I hate the build pane.) Do it this way instead in xcconfig:
LD_FLAGS = "$(openssl)/lib/libssl.a"
If you have stable code that is shared between several projects, and while developing those projects you're never going to mess with this code (and don't want the source code available), then a Framework can be a reasonable approach. If you need plugins to avoid loading large amounts of unnecessary code (and you really won't load that code in most cases), then bundles may be reasonable. But in the majority of cases for application developers, one large executable linked together from static libraries is the best approach IMO. Shared libraries and frameworks only make sense if they're actually shared at runtime.
My suggestion would be:
Use Frameworks. They're the most easily reusable build artifact of the options you list, and the way you describe the structure of what you are trying to achieve sounds very much like creating a set of Frameworks.
Use a separate project for each Framework. You'll never be able to get the compiler to enforce the kind of access restrictions you want if everything is dumped into a single project. And if you can't get the compiler to enforce it, then good luck getting your developers to do so.
Upgrade to XCode4 (if you haven't already). This will allow you to work on multiple projects in a single window (pretty much like how Eclipse does it), without intermingling the projects. This pretty much eliminates the cons you listed under the Frameworks option.
And if you are targeting iOS, I very strongly recommend that you build real frameworks as opposed to the fake ones that you get by using the bundle-hack method, if you aren't building real frameworks already.
I've managed to keep my sanity working on my project which has grown over the past months to fairly large (number of classes) by forcing myself to practice Model-View-Control (MVC) diligently, plus a healthy amount of comments, and the indispensable source control (subversion, then git).
In general, I observe the following:
"Model" Classes that serialize data (doesn't matter from where, and including app's 'state') in an Objective-C 1 class subclassed from NSObject or custom "model" classes that inherits from NSObject. I chose Objective-C 1.0 more for compatibility as it's the lowest common denominator and I didn't want to be stuck in the future writing "model" classes from scratch because of dependency of Objective-C 2.0 features.
View Classes are in XIB with the XIB version set to support the oldest toolchain I need to support (so I can use a previous version Xode 3 in addition to Xcode 4). I tend to start with Apple provided Cocoa Touch API and frameworks to benefit from any optimization/enhancement Apple may introduce as these APIs evolve.
Controller Classes contain usual code that manages display/animation of views (programmatically as well as from XIBs) and data serialization of data from "model" classes.
If I find myself reusing a class a few times, I'd explore refactoring the code and optimizing (measured using Instruments) into what I call "utility" classes, or as protocols.
Hope this helps, and good luck.
This depends largely on your situation and your own specific preferences.
If you're coding "proper" object-oriented classes then you will have a class structure with methods and variables hidden from other classes where necessary. Unless your project is huge and built of hundreds of different distinguishable modules then its probably sufficient to just group classes and resources into folders/groups in XCode and work with it that way.
If you've really got a huuge project with easily distinguishable modules then by all means create a framework. I would suggest though that this would only really be necessary where you are using the same code in different applications, in which case creating a framework/extra project would be a good way to effectively copy code between projects. In practically all other cases it would probably just be overkill and much more complicated than needed.
Your last idea seems to be a mix of the first two. Plugins (as I understand you are describing - tell me if I'm wrong) are just separated classes in the same project? This is probably the best way, and should be done (to an extent) in any case. If you are creating functionality to draw graphs (for example) you should section off a new folder/group and start your classes and functionality within that, only including those classes into your main application where necessary.
Let me put it this way. There's no reason to go over the top... but, even if just for your own sanity - or the maintainability of your code - you should always endeavour to group everything up into descriptive groups/folders.