Is it possible to assign templates to pages (_template.js) in Gatsbyjs some other way than having them reside in the same folder as the pages being transformed by them? I can imagine wanting to use common templates across folders, but not necessarily always the same templates. I'd rather just have a "templates" folder and have them assigned in some way.
This will be fixed in 1.0 with the new programmatic routes where you'll be able to directly set the "layout" (not using template name anymore as it was wrong) for routes. In 0.x you're a bit stuck. With sufficient effort you could hack something like this into place but it'd probably mean forking Gatsby somewhat.
Related
I'm working on a structure for a React application. We have ./src/Assets/Images folder, but should I put all component assets there? or I should put each component's assets to it's folder?
I mean: ./src/Components/Loading/animation.gif
or: ./src/Assets/Images/animation.gif
I'm actually interested to design a maintainable and clear structure for this app.
What do you think? which pattern is better for development and the feature...
You know, I've separated Styles but have doubt on Images??
This must be an opinion based question and it isn't something you should care that much about to be honest. It's personal preference but if you ask me, it's better to keep you assets in a same folder so your components' structure won't get messy.
I would like to say "all in one place" is good. Assets that are required to be loaded, for example images for navigation should be placed in public folder as it is much more comfortable to use. You just need to set url to point it.
For other cases, I think it is better to place it in component's folder.
I think tree structure is easy to maintain and scalable. Let's imagine that you need to update a component. In that case, you just need to update files in the same folder. If it is located somewhere else, this can lead to potential problems: for example, you need to make sure that it is not used by other files.
To sum up, I think it is good to place assets in the component's folder.
I'm using ui-router/stateProvider to load various views for a single page app. Additionally I'm following what appears to be best practice for structuring code by breaking my code into components so I have, for example;
Index.html
\Components
\Component1
\page1.html
\page1.css
\page1-controllers.js
\page1-directives.js
\Component2
\page2.html
\page2.css
\page2-controllers.js
\page2-directives.js
I have quite a few different views/components (10+) and my question really relates to how to manage the loading of the js files (and the CSS files for that matter). I can put the JS files all in tags in the index.html file and all works fine, but looks a bit messy as it is a very long list.
So my question is: How should I manage the inclusion of the various scripts for each view; should they all remain in the index.html file or is there a better way of managing them, such as loading only when each view is called via the ui-router?
Many Thanks
I think that you need to use RequireJs, I will include a couple of sites with the documentation that explain how implement that.
http://www.javascripthtml.com/load-dynamically-javascript-file-in-angularjs-with-requirejs/
https://cdnjs.com/libraries/backbone.js/tutorials/organizing-backbone-using-modules
For css you may want to add a single class to each view then use a single css file for all views. I keep the css organized into modules for easy access. This will also help load times as it will require less requests.
For js I would create a universal js file that contains any code that is required for ALL views, then create individual js files for individual views. There really isn't a "right" way per se but preferred ways depending on the developers you work with. Keep it simple and easy for other developers to read. :)
I have the same problem as you, I think that the only solution for us is to add the script in the "index.hmtl" page.
I am using backbone.js in a legacy app to rewrite separate pages into individual bits of backbone work.
I am not using any routing and it is not a total single page application.
Only certain pages are individual backbone.js applicaitons.
At the moment I have all my backbone javasript in one file for each page that uses it which is painful to work on.
Would it be wise to use something like requirejs on a page by page basis or is there something better I could do in order to split the page up in development and serve one page in production?
That depends largely on what your existing codebase looks like.
RequireJS is a great tool...if your existing code is set up to support it, or you have a small enough codebase to be able to convert it without breaking everything. However, not all legacy JS code is, especially if it's part of a larger system (I personally ran into this problem with a Backbone project I'm working on). If you can, then by all means, make use of it. The big advantage, as far as I know, with RequireJS is that it doesn't actually fetch and load the Javascript files until you need them. So you can have one RequireJS call that's in all of your pages, and only download what you need, when you need it.
There are other ways, however, to combine your Javascript code at production time, which, again, depends greatly on your setup. Many content management systems include "minify" scripts that handle it automatically for all of your Javascript files. You can also do it "by hand" with Minify, YUI Compressor, or one of the many other minification tools out there. (You can also do it "really by hand", and develop in multiple files and combine them via copy+paste, but that's really more work than is necessary.)
Regardless of how you go about doing it, I highly recommend breaking your projects into multiple files (not only into a file for different projects, but multiple files within the projects, to hold each view and models if they have significant code). It makes it infinitely easier to maintain.
I'm trying to migrate all "content" pages on a website to DNN5 Pro.
So I just created all the pages in DNN, added HTML module to the ContentPane and copied and pasted the HTML content from old pages.
The problem is that most of the pages have bits of classic asp code which do some minor server-side tasks - for example, populate tables with prices fetched from DB, pre-select user's country based on his IP address, do some basic dates calculations, etc.
Obviously, this code won't work in DNN.
If I had to migrate to PHP, I'd just rewrite these bits of code from classic ASP to PHP, then assign values from PHP to smarty and then would use them in templates.
But as DNN has a completely different architecture, I can't see how similar approach can be used.
Token replacement feature in HTML module looks like what I need, but it allows to "map" only tokens provided by DNN.
So, maybe anyone had similar issue with DNN and/or knows how this should be done.
It seems like you are attempting to subvert the entire point of DotNetNuke. While certainly there are a variety of hacky ways you could try to make this work just like the php site, it's a terrible idea to do so.
Instead, you need to evaluate each of the dynamic sections of the php site and find or create a DotNetNuke module that will replicate that functionality.
To make the initial conversion quicker, you can build modules you create using simple ASP style inline scripting but you should definitely use existing modules for things like displaying data in a grid.
You could write code directly in your skin file. Do some logic like:
<%If PortalSettings.ActiveTab.TabID = 33 Then
//code here of what you want
End If%>
Where 33 is the page id for the page you want to run custom code on. There are other ways to do this like creating skin objects, or creating custom modules, but this is probably the easiest thing to do. Just write code directly in you skin. Or make a copy of your skin for each page you need to do custom code for... again, more elegant ways but this will get'er done.
The home page for DotNetNuke 5.2 is around 252.6KB. It uses 15 JavaScripts and 8 CSS files. The number of resources DotNetNuke uses seems excessive to me. I am looking for best practices creating DotNetNuke skins that limit the JavaScript and CSS resources.
You can use the Unload CSS Skin Object to remove links to some of the CSS files loaded by the framework (like Default.css, portal.css & any module-specific CSS files). You can then move all of those styles into the skin (or portal stylesheet, whichever is your preference), so that there's only one stylesheet that gets loaded.
I don't know of any solutions for combining JavaScript resources or reducing the number of scripts that DNN requires.
From 6.1 onward, the Client Resource Management component is the solution for this. It automatically combines all your files, cleaning them up, removing comments, and minifying if desired.
http://www.dotnetnuke.com/Resources/Wiki/Page/Client-Resource-Management-API.aspx
It takes a little getting used to, but the control is quite nice. You can decide which order they'll go in, you can group the files in bunches if you don't want one big single file - maybe you want certain bunches of scripts together but not all.
One thing to remember is that when you're doing development (as noted by the comment below, which I've since edited this post), you should always use debug=true in the web.config, otherwise if you are using Resource Mgmt and change your source files, you'll constantly need to regenerate the combined files by going into Site Settings, Client Resource Management, and increment the version. It's kind of a protection to keep anything from altering your clients' browser caches without intent (that's the message box that pops up to let you know when you do it). I'm sure if you have a zillion users this might make a difference.
Part of that is just the dynamic nature of DNN - there are some good resources that R2i has published about combining javascript and CSS
One concrete suggestion is to combine all your skin and contianer css in one file and if you have full control of the site to combine the css from the modules you use into that same file.
I know with the addition of the Telerik controls there is some abilities to combine resource files
Another thing that helps is to combine graphics into a single file and use CSS (the sprite technique) to cut down number of files loaded and calls to the sever
Like it was stated above, it's the nature of the beast. Each module will have at least 1 css file included. You can check out PageBlaster from snapsis.com, I believe it will do what you are looking for.