I have a webpage that needs to be able to generate and later read barcodes. But i cannot seem to find any small scale addon to aurelia that does even one of these. Is there any libary that does this or do i have to write my own somehow? Or can i somehow use some preexisting barcode stuff that is not directly designed for aurelia?
looks like you have to find a suitable library for the task on npm.
For barcode generation, you can use this test app:
https://codesandbox.io/embed/barcodes-bxgf1
Be sure to adapt to your own bundling choice.
I used quaggaJS in my aurelia app for reading existing bar codes.
(it's actually just a regular JS package - not specially for aurelia)
the API is kind of old (callbacks instead of promises), and overall it's a little weird (the Initialization process), but in the end it works great with little effort.
you can use https://www.npmjs.com/package/qr-scanner only draw back is that your website need to be https.
Related
I'm building my first vue.js app and I'd like to have some help on deciding a design approach.
This app is going to be embedded inside a page of a site - built with Drupal 8.
Both app and site are going to use bootstrap 4 as base framework and we're going to use sass to style.
It's a quite simple app: a multistep form with some ajax call done to the aforementioned site.
It has anyway some components - one for each step, for some of the more complex input, for a sidebar showing the result of the ajax calls and so on.
I need to decide the "guideline" for styling this app and I'd like to get some help\insight to what solution is better.
On one hand, I could put the style inside the app itself; on the other hand I could leave all the style to the one present on the site.
As far as I can see the benefits of the first approach are the use of scope of each module, thus having a better "modularity".
However, putting the style all inside the site would avoid code duplication - simple example: custom color variables.
Personally I can't see for now other differences right now.
I haven't found material about the suggested approach and the pros\cons.
Could advice me of which approach is the best? Thank you.
It depends on the project, but you can make a list of cons and pros based on your project brief. If there are very few (or 0) changes in the future or it's based only on small components (not much style) then go with component-scoped styling. If the project is big, always go with a style pattern like the 7-1 pattern
I prefer working with the 7-1 pattern pattern.
Pros:
- Scalability or future updates like you mentioned the color variables case.
- You don't depend on Javascript to load the style, depending on how you write the app or how it loads, it may have glitches.
First off, I'm brand new to Dojo.
I'm integrating it into our existing web app.
We initially only need the Calendar widget functionality.
I'm looking to keep the number and size of files as small as possible.
I don't believe downloading just the base code file will be sufficent?
http://dojotoolkit.org/download/
Additionally, the Dojo toolkit download is a huge zip (Even if I was to only use compressed files)
Am I left with downloading the toolkit and manually removing everything I don't need?
Is there no custom download builder like jquery ui?
Well, the dojo library is much larger than jquery ui and I don't know of an equivalent to the download builder. If you are just interested in using dojo for a single widget, you might consider exploring a different library.
To use dojox/Calendar, you are still going to need the many dependencies it has on other dojo modules. You can do this manually, but it will be tedious.
One thing you can do is run dojo's build system to package dojox/Calendar and all of its dependencies into a single file. This isn't a trivial task and requires a good understanding of dojo's AMD loader and package system.
If you want to go down this route, I would clone the dojo-boilerplate project on github. It contains everything you need to do this out of the box. Then follow the build system tutorial to understand how you set this up. From there you can have your app depend on dojox/Calendar to produce the file you include on your page to consume it.
I suggest that you put the whole thing (yes, it's a lot of tiny files) to your server.
Dojo 1.9 is written so that when users visit, their computers will only download the individual pieces on an as-needed basis. This is possible because every piece (AMD modules) is explicit about what it needs.
Once you have something that works, you can choose speed-up loading times by using the build system. Basically, this involves going: "If the user wants this thing, they'll probably want all this other stuff, so create a big minified lump and give it to them whenever they start asking." Best of all, it doesn't have to be perfect: If you miss including something, the users browser will still request it a la carte.
At work we're using the Dojo Boilerplate starting application which helps give some initial organization to the build process.
I am converting a good old ASP.Net website to a single page application using Ember.js in a ASP.NET Web API project.
All the devs of my team and myself are pretty new to javascript. We spent the last 2 weeks learning the basis and comparing SPA frameworks. I apologize in advance if my question sounds stupid :)
All the Ember tutorials I have found so far included all Handlebars templates into one single file. I assumed it would be pretty obvious to split them into separates files (*.hbs) when the time would come, but it's not. I might be totally missing something here, but I found about 4 ways to get my templates back when I need them. I'd like to know which method you would recommend:
Concatenate and then inject all the template files when the app loads. I could write some C# code on the server-side that concatenates all the templates files into a single one when the app loads (i.e. each time a visitor enter the app). It seems odd to me, in terms of processing, but also because the generated HTML file will be pretty heavy.
Load each template dynamically via Ajax when I need it. Pretty much what is done here. I kinda like this solution even though I haven't tried it yet. It makes sense to me to get asynchronously a template when I need it instead of loading the entire app on the first load.
Use the Bundling mechanism of Asp.Net MVC. I found stuff like csharp-ember-handlebars to precompile the templates on the server-side and return them as a single javascript file. It works-ish but I feel like the precompiled file will become pretty heavy as I add new templates.
Use Grunt with the plugin grunt-ember-handlebars to precompile the templates. I'm not familiar with Grunt but if I understand well all the devs working on the project will have to install Node.js + Grunt + learn how to use a command prompt + remember to run the command before each commit (if they modified a template). This is not obvious for the web designers. And adding grunt to the build actions will require the entire dev team (working on other projects) to have grunt on their machine (not acceptable).
I need to find a simple and elegant solution to address this issue. My project is in a solution with 35 other projects and I cannot add too much complexity to the build, neither depend on unstable libraries. Maybe I have been too optimistic when I thought I could use Ember for my project. Any suggestion would be welcome!
Your #3 is the most ideal (and common) way that I've seen applications handle templates. With a compiled and minified template file you really don't have to worry to much about performance problems in regards to adding new templates, especially if you take advantage of caching.
One benefit to having the templates compiled and available off-the-bat is that users only need to Download Your Resources Once™, as apposed to downloading resources for each subsequent page load. This leads to a fantastic user experience.
We are trying to make an app maker with dijit. Do you know what to do more or less to have the dojox.mobile.* branch running parallel to my dijit app ?
I know there is a seperate dojox.mobile.parser,... I guess, I need to fork it quite deep ?
I thought first about an iFrame but we need drag'n drop from the designer and the simulator.
Any help is welcome,
g
dojox.mobile offers a very light-weight parser which can be used in place of the standard dojo.parser. I think it skips stuff like attachpoints and probably wouldn't work too well with Dijit, so if you use both types of widgets on your page, stick with dojo.parser. The parsers share some globals and are unable to co-exist, so do NOT load both.
I'm thinking about writing a professional CV page that would be easy to update, using a simple backend to add informations and blocks of optional details, and... (feature creap coming)
Anyway, I was thinking of a "simple" web page grpahically, that would easily be convertible to PDF file, using browser functionallity or not.
Assuming that the page have blocks of text that you must ckick a button to see (those are optional details), what should I know or what tools should I use to write this web page?
I'm totally rusted on web code, I used php without ajax a lot before but I understand the idea. I was thinking maybe it would be a good opportunity to try a framework to make a "webapp", like Ruby+ROR or Python+Django? Is that a good idea? I'm ready to learn about those, I'm just not sure if it's worth for such project.
Should I know some things about html code or javascript behaviour that I shouldn't use because it would break any PDF generation tool or something like that?
Any advice on the way to proceed would be helpful.
You'll want to read up on how to create a print stylesheet. This way when you go to print the CV you can choose something like CutePDF Writer and your print stylesheet will automatically be used. You will make your stylesheet show all hidden text blocks and hide things like navigation, buttons, etc.
I can't tell you whether or not it's worth it for you to try a new framework for this project, that's up to you. It's not bad to learn new things. Since I don't know all the details of your project it's hard to answer if it's worth it for this particular project. From your description is sounds like you're just making an HTML resume/CV which sound, to me, like one flat HTML page with some JavaScript. If that's the case you could probably just use a text editor.
If you want my personal opinion, ASP.Net 4 is the way to go if you want to learn something new (or if you just want to use a great framework).
As far as breaking the PDF generation, your print stylesheet will be responsible for showing/hiding things but any JavaScripts should be aware of this as well. Check the link I gave you above for more information.