I have a large rails application that I am wanting to split out into smaller applications. The one piece of this application that will be universal to all smaller applications is the mast and footer. I would like to extract the html, javascript and css for the mast and footer into it's own package that each app can load and render.
The main issue I'm running into is that the apps will likely not all be written in rails. Some will be rails, some will be expressjs, some written in Go, and some may end up being written in other languages, so my solution needs to be language agnostic.
My thought is that I can extract the html, css and javascript into it's own git repo, use mustache templates for the html, and then use grunt or a similar build tool to build a gem, a package.json structure and a golang module. Possibly each in it's own git submodule.
I'm curious if there is a more standardized way of doing this. Or if anyone knows of a simpler way of achieving this goal.
Sounds like the technology in common is HTML/JS/CSS.
Wouldn't it be better to export the mast and footer as a self contained JS library, or more precisely, as widgets?
So whatever the application server tech stack would be, you could always generate the HTML in the form of:
<script src="your_widgets.js"></script>
<script>new Footer.render('id_of_dom_element_to_render_to');</script>
By doing so, whether you want the widget library to load the template or you want to embed the template into the widget library or whether you want to simply just construct it using HTMLFragment will not be limited by the server tech choice.
Related
I am currently working on a project in which we are having a React/Flux UI being developed for us. I am being told that the UI code needs to be converted into GSPs and put into a Grails Project, to work with our backend. I feel like moving the UI into GSPs will nullify the use of our Flux implementation(Reflux).
My initial thought is that this is wrong and I have not found any use of Grails and Flux through searching.
I'm involved with a production Grails application which uses React as it's front-end. There's no need to "convert" the React/Flux code into GSP - in fact that would largely sacrifice the benefits of the React UI. There's no need- Grails is very well suited to provide a robust Restful backend to a React (or Angular, or any other JS framework) application.
Depending on your application needs, you will probably want to provide a restful API for the front-end to consume/post as needed. Use URLMappings.groovy to specify endpoints that the React app can access. You will likely choose to use JSON as the medium to send data to the React app - Grails' JSON views are a fast, flexible and straightforward means to render Grails domain objects or other data to a JSON payload.
There shouldn't be anything Grails-specifc regarding Flux - use it to manage and mutate your state in the React application, perhaps by making rest calls from your Flux dispatcher (or action creator) to the Grails backend to retrieve data and update your Flux store.
Regarding GSP, my recommendation is to simply have a barebones GSP view off your main controller, which simply loads the Javascript needed to run your React app. If you are using a module bundler like webpack, this can be as simple as linking your bundle.js file into your view and providing the root element specified in your top-level component:
<html>
<head>
<title>My App</title>
</head>
<body>
<div id="app"></div>
<asset:javascript src="bundle.js"/>
</body>
</html>
Note that for this to work, you must be outputting your webpack bundle into grails-app/assets/javascripts, which I find to be the simplest way to load the React application in a Grails app. Using this approach, there's no need to load React, Flux or other related libraries into Grails directly - just build your project using the standard JS toolchain (using npm/package.json to manage your dependencies), and process/bundle the entire application into a plain JS bundle that can be loaded by the Grails asset-pipeline.
React makes a great choice as a view-focused Javascript library that doesn't make a lot of assumptions about your backend architecture. With a solid restful api based on Grails, and some intelligent choices about tooling and project structure, React is a great fit for a modern, single-page Javascript UI in a Grails app.
Why would the use of GSP nullify the use of React or Flux? GSP is just a server-side processing language that renders HTML. Last I checked React and Flux make good use of HTML for a great number of things in combination with Javascript.
You can use them together without any issues. How, is up to you.
You are being told wrong. GSPs are Java servlets. The only reason to mix React with a server-side technology is for an isomorphic application, where you would compile your JS prior to returning/pushing it to the client. In which case, you would need to create something akin to a Rhino-based servlet. Otherwise, treat it as you would treat any other static asset.
Edit: so apparently adding class="button" make it work... Can someone provide a reference on what other classes are there? We can't find any information on this.. Thanks
We are making an app in HTML5 using XDK, it has quite a few different views. We were planning to just link to another html page each time we want to go to a different view. But we quickly found out that hyperlinking does not work, is disabled, and button does not link either.
One of the people in my group said she saw an example about having a bunch of and then just show and hide them and use that as UI navigation... is that the only way?
Thanks in advance!
The Intel XDK doesn't insert any class definitions or require that you use a specific framework. It is a tool for assembling an HTML5 hybrid mobile app using the CSS, HTML and JS files that you supply.
If you look at the samples and the default "blank" project that is created when you create a new project you'll see that there may be references to one or more of the following "phantom" JS files:
intelxdk.js
cordova.js
xhr.js
The first two (intelxdk.js and cordova.js) are special "device API" JavaScript libraries. You won't actually find them in your project directory, they are automatically included when you use the emulator and when you build your project (which "wraps up" your HTML5 code and assets into a native wrapper that is specific to the target you are building -- it does not compile anything, it just converts it into a hybrid native/HTML5 container app that can be installed on the target platform that you built for).
The third one is a special helper JS library for dealing with CORS issues from within your app.
None of these three JS files define any classes or HTML tags, etc. They simply implement target-specific device APIs that consist of JavaScript on the "top end" and native code on the "bottom end." Your application only sees and interacts with the JavaScript interface, and only with the APIs that you need to use (which is totally optional).
For an intro to all of this, please see the Intel XDK Documentation page.
So, that means you determine which frameworks and structure your app takes. In other words, if you want to use Bootstrap and jQuery you can do so. If you decide to use the App Designer or the App Starter tools, they will define some classes that impact your layout. However, you are not required to use these tools to define your HTML and CSS, you can do it by hand or use your favorite UI framework library.
Keep in mind that your code is not being rendered by a desktop browser but the embedded "webview" that is part of the device. These webviews don't have the same memory and CPU resources that you're used to working with in a desktop browser, so you need to learn to be "lean and mean" for the best results. You are using HTML5 technologies to build a mobile app -- not creating a web site on a phone.
Hope this helps, please see our HTML5 web site for more background material. It's a little slim right now, but we're adding examples and background material as time and resources permit.
Hope that helps...
I'm taking a look at Hogan.js by Twitter.
http://twitter.github.com/hogan.js/
They talk about being able to precompile templates via the server which I understand can be a perf gain.
Currently every time I render the template I perform the following after an AJAX hit to the server to get data:
var template = Hogan.compile($('#seasonsTmpl').html());
$('#main').html(template.render(data));
Given the following template:
<script type="text/html" id="seasonsTmpl">
<ul>
{{#season}}
<li>{{.}}</li>
{{/season}}
</ul>
</script>
What can I do to "precompile" server side using an ASP.MVC backend? Is this not possible as it seems to be centered around using Node.js?
You have the right idea to optimize your templates. There are two options, and the choice probably depends on whether you want to render your templates client-side or server-side.
If you want to render them client-side, you can do a true precompile using Hogan.js. Yes, this does not run on .NET, but I think you've misunderstood when precompilation is possible. Rather than expecting it to happen on each web request, or page load, you can compile your templates up-front as part of your build process. You will need to install node and npm to set this up, but you only need to run this locally on your own machine, or a build box if you use one. Whenever you update your templates, you would run Hogan again to update the output file. The compiled output will be a JavaScript file full of functions that are optimized for later use. These functions include your template strings, along with the logic to render the data a la Mustache. You can then include the output file just like any other JavaScript include, or include it with the other sources for minification if you do that.
The second option is to render the templates server-side. This is different than precompilation, the server will compile and render the templates again for each web request. Step away from Hogan.js and look at a .NET alternative such as Nustache. The great thing about Mustache is it has a spec and has been ported to several server-side languages.
There's a fundamental difference in these options in terms of where the rendering happens. You might even want to leverage both approaches in certain scenarios, say if you want to render the initial page load server-side using Nustache, but have dynamic elements that must be rendered in the browser using templates precompiled through Hogan.
More info:
Nustache on Github
I hope you find this helpful!
I am getting ready to code a number of HTML helpers for UI elements in an ASP.NET MVC 3 project. I expect many of the helpers to depend on code that is located in external javascript libraries. These could be custom javascript libraries that I write, or they could reference 3rd party libraries like jQuery and jQueryUI. For example, I might write HTML.RichM.DataPicker(...) that would require the page to have jQuery and jQueryUI referenced and some code executed in the document ready function. Getting code into the document ready function is pretty straightforward I guess -- I could simply inject a new script block into the output with the contents of the function, even though that would mean I might have a page peppered with document ready functions all over.
The other part of this is making sure that the jQuery and jQuery UI libraries (in my example) are referenced and included. Is there an "MVC way" to add the code references to the view page or the layout/master if they are not already there, or must I instruct users of my HTML helpers that they need to add references manually for any required javascript files? Of course, I could just instruct them to include all possible external library references in the master or layout page, but that seems like overkill. In ASP.NET Web Forms, for example, I might have used RegisterClientStartupScript or RegisterStartupScript to do this from my custom control.
Thanks for any suggestions!
I think the easiest way is to include the dependant scripts in the header, that's maybe not what you want to do, but I think it's the easiest way.
I suggest you using a tool like SquishIt to bundle your JS files together, that way, you will not have to load like 20 js files, it will be more efficient and cleaner.
Good day!
I'm looking for solution to combine, minimize and gzip CSS and JavaScript files. It seems they come in two forms:
In form of ASP.NET handler\module with processing files on the fly (with caching results)
In form of VS build tasks (to perform processing while building)
Generally I'm ok with either.
I've looked on a number of solutions (and I use ASP.NET handler from this article http://www.codeproject.com/KB/aspnet/httpcompression.aspx a lot), but maybe something "must have" came out and I've missed it.
Thanks in advance!
Here's my advice to you: use build tasks and HTTP cache the output.
In terms of build tasks, you'll want to check out your favorite JavaScript minifier (my favorite is Google Closure Minifier) that has a command line utility that you can just plug into your project file, MSBUILD file or NANT file. Same deal with CSS (I personally use Yahoo! YUI Compressor). If you're into using LESS, you can certainly combine this with the YUI compressor. To optimize images, I'd use optipng. There's directions on how these guys work on their individual sites.
Now, after you have these files all nice and optimized, you'll want to output them using a handler or controller action for MVC. To set the expiration so that subsequent requests will default to the file downloaded on the first request, you'll want this to run in your code:
Response.ExpiresAbsolute = DateTime.Now.AddYears(1);
More than likely you'll want a cache-buster strategy so that you can change the content files. You'd do this by passing a random parameter to your handler. There are a few different ways to go about this... just Google it.
Hope this helps.
I'm using the telerik mvc components for small-medium sites. It was simple to add and configure with NuGet.
Moth can (among other things) handle all your javascript / css requests on the fly. See Wiki: Javascript.
Best of all, it can also put all javascript at the bottom of the page, including parts you write in your partial views! Wiki: Inline script.