I realize from the Aurelia 0.10.0 Release & Status blog post that Aurelia's "bundling solution is about 50% complete".
For the purpose of releasing a standalone embeddable Aurelia app (on 3rd party site), am interested to know if there is currently a method for loading HTML view templates dynamically for use with RequireJS (Almond) and the text! plugin or an equivalent (SystemJS or other) mechanism.
Or do we need to wait for the bundler?
There isn't a way to do this currently. However, that's something we can add...and we do expect to make some improvements in this area as part of our general bundling work.
Related
I'm trying to find a way to import the Prismic.io javascript kit in my Angular 2 project.
Is there a way to do so ? I tried to understand their Angular2-starter but it's not documented to do it on an existing project.
I want to know if there is a way to import node modules directly into Angular2 ?
Thanks in advance !
You need to be more specific, what does it mean import modules directly into angular 2?
First, to have common ground about modules:
Modules are a core feature of javascript, either natively in ES6 or using bundlers (e.g WebPack, SystemJS, etc...)
Importing a modules is not related to Angular 2
As for Angular 2, if by using directly you mean being able to inject service via the dependency injection then this is just a configuration operation done in angular.
In the case of an external, 3rd party, NON Angular library you might want to wrap it with an angular service which is then injected.
The starter project you linked to does so, it defined a prismic-service class that wrap the original prismic library so you only work against the wrapper class.
You can extend this class to support more features as you go.
Some notes on extending 3rd part libraries in angular 2 vs angular 1:
AngularJS (1) developers approach 3rd party libraries with caution. Since AngularJS has an internal change detection mechanism that Angular has to manage, execute and control. Any 3rd party library that modifies data that directly or indirectly effects the UI must also trigger the internal change detection in angular.
In Angular2 change detection is triggered by generic async operations such as events, user interactions, etc... Angular does not manage it directly, it is triggered automatically as if it was magic. This is possible due to the help of Zones which is both a concept and a library. Angular implements NgZone.
Basically it means that you can use prismic directly or as a wrapped angular service, it doesn't matter, it will just work.
I guess that most of your questions will focus on integration, which is how to take the data from the API and make a UI out of it.
The prismic Development kit provides a REST API for retrieving metadata about UI elements and data that they contain.
The client (in a SPA, like angular 2) needs to display actual UI components from the metadata.
In other words you need to build Angular 2 components that correspond to the components in prismic.
A common JavaScript library that builds a UI from prismic REST API data will not work here. It will generate HTML code that is not part of the angular application and does no participate in change detection, lifecycle hooks and routing.
All components in angular must be compiled first, at the bootstrap or at build if offline compiler is used.
The minimal approach is to get the HTML markup from the server and inject it into an angular component acting as a wrapper. This allows control over the lifecycle of a page and used for routing, page transition animation etc...
The starter project provides such a wrapper called DocumentPage. The DocumentPage has logic to download it's content (via route parameters) from prismic and display it as raw HTML. See here
The html markup retrieved from prismic is NOT bindable and you can't apply change detection and expressions in it. If you split it into chunks you can apply some angular magic in between.
So, it's quite simple actually, the starter project is a simple wrapper around the prismic framework in both API and UI. Angular has a small part in the application as it acts as a simple wrapper/container. The actual content is driven by prismic. I don't see benefits using angular with such approach, it doesn't do any harm but it's not really an angular app.
A proper angular2 prismic app would be built upon pure metadata representation of components which are implemented in angular as angular components. It is quite an advanced app that requires dynamic component creation as well as advanced routing implementation with lazy loading (to introduce new components on the fly).
I am building an app that consists of a number of plugins. The app and the plugins are built around the service stack framework including the razor engine.
One of the problems I have is that I have to set all of the files to copy always, the final app ends up with a mashup of files from all the plugins. It works but doesn't make it easy to add/remove plugins - ultimately I would like to do this whilst the app is running.
I found razorgenerator which looks like it addresses part of my problem and would precompile the microsoft razor pages into the dll. Has anybody done anything like this with the service stack razor files?
It wasn't really designed for it, but here's an example of using ServiceStack to render stand-alone razor pages.
You could also use another tool like razorgenerator or RazorEngine though this is disconnected and doesn't have anything to do with the Razor support in ServiceStack.
I'm currently implementing a ruby/sinatra application using erb as the rendering engine using client-side rendering using handlebars/mustache templates as well. I'm implementing a certain list view in which the list elements will be rendered using the client side solution when javascript is present and fallback to server side when not (targeting crawlers this way). But I'm left with the folliowing issue: I basically have two templates written in two different markups which produce the same html. I'd love to "write once, run everywhere". How are other projects leveraging this issue?
I've used sinatra-mustache with Sinatra, and it works great. I have not used it for both client and server side templating from the same template files, but you should be able to do that as well.
I've found the answer to be using your favorite templating flavor on the server-side but using some other templating engine for the cases where the template is going to be shared on the client side. So, I'm using erb most of the time, the rest of the time using poirot (for Rails). This integrates Mustache templates on action pack, which handles multiple templating engines anyway. Poirot comes ready with helpers to write the templates on the document and also client side rendering libraries. It also integrates handlebars and hogan templates, which are mustache extensions.
As for Sinatra, I try using the same approach using erb and https://github.com/defunkt/mustache , but the nice integration from poirot on rails has to be done by hand.
I am developing a Java EE based web application. We have a very limited time to come up with a alpha version and trying to decide on a web framework to use. It has to be something easy to learn but powerful. Standard JSP/Servlet is not an option here due to the time it takes for the development. Appreciate if anyone could advice. Current options are Wicket and GWT. (JSF is also an option)
Wicket is component-based and comes with a bunch of standard components (like pagination, auto-complete, data grids, form handling etc.). If you want to create a standard panel (with the possibility for easy re-use) just create your HTML fragment to use a template (with wicket:id attributes wherever you want to bind dynamic content or sub-components) and a corresponding Java file. Furthermore, you can attach specific CSS and JS files.
In my opinion, Wicket development is good value (functionality) for money. And you get a lot of built-in AJAX functionality without even writing (not reading) any JS. E.g., change the model for a component, attach the component to an AjaxRequestTarget and the panel is automagically repainted via DOM manipulation.
For a quick overview and intro I recommend Wicket in Action by Dashorst & Hillenius. (And don't miss out on other great resources.)
Everything depends on your application. I don't have experience with Wicket, not much with JSF. I have big experience with GWT.
GWT is good if your application has to be mostly dynamic. In GWT you can change everything on the page not even calling the server. GWT is compiled to Javascript. On the other hand, if you have big project, it is quite frustrating if your application in development starts few minutes, because it has a lot of code to compile to Javascript. My opinion: it is not good for big projects.
If you don't need to change your pages so much client-side, I would use JSF2 (or Wicket, if I knew it).
Have a look at this comparison of Wicket and GWT, this may help you decide for yourself:
Wicket and GWT compared with code
We have a medium sized .js file that we include in our web framework that I am porting over to SharePoint. However, I'm not sure how to go about this or what the best practice is. This is for a framework solution that will be used by other client projects, so it's best for it to be self contained and deploy-able, rather than requiring manually deploying files to the webserver.
My current thinking to put the JavaScript into an embedded resource and then use the script manager to write out the file. Does this seem reasonable? Or does anyone have any other recommendations?
Embeded resource is the best way and you don't need to use the ScriptManager to render it out (as AJAX is not configured OoB on SharePoint), you can just render it as any other client script resource (through the ClientScriptManager).
Best idea is the have an if ContainsScriptManager else UsClientScriptManager style.
That way you get the best of both worlds
You could just toss it into a doc library.
If you are packaging your web part into a sharepoint solution, you could include it as a Module (VSEWSS item). Your manifest file would get something like:
<TemplateFiles>
<TemplateFile Location="LAYOUTS\somescript.js" />
</TemplateFiles>
Theres lots of info on how to do this on the web. I've liked the doc library option for images, css, and javascript because I don't have to rebuild and wait for for SP to JIT compile for 30 seconds each time I do a minor tweak to some style or script. I just edit these things in SPDesigner right out of the doc library.
Create resource mapped folder in your project and put the js file there and give the referene of the js file as _layout/jsfilename.js and this js file will be deployed with your project where ever you will deploy it.