I'm relatively new to meteor, but have already some experience in AngularJS. Therefore I have "angular-meteor" installed.
I also have a bit played around with it and am very happy with it. Now I have only the problem that if I, for example, wants the package "meteor-uploads" use, I always receive the error message:
Token '>' not a primary expression at column 1 of the expression [> upload_bootstrap] starting at [> upload_bootstrap].
if I want to use the package, by {{> upload_bootstrap}}.
What am I doing wrong?
Update
I can access the package with:
import upload_bootstrap from 'meteor/tomi:upload_bootstrap';
How can I now render it to my view?
The client package for meteor-uploads was designed to be used with Blaze only (it has a dependency on Blaze). You won't be able to use it with Angular unless you're willing to port a lot of the code over yourself.
If you're looking for a popular Meteor based file upload solution (that isn't tied to a specific view layer which means it can be used with Angular), take a look at edgee:slingshot.
Related
I am currently using meteorhacks:ssr along with wkhtmltopdf in order to generate downloadable pdfs within my Meteor app. It is working end-to-end, which is great, apart from one last element.
The template helpers which have been specified in packages across my app, are not visible. From the examples in the documentation for SSR it uses templates and helpers specified at a super-package level, which is not feasible with a package based arrangement for an app.
The only way I can see to make them available both client and server-side is to store the functions in an object, and then to loop through the helper functions in client and server code to render the functions accessible in both places.
That methodology works, but it is rather lacking in beauty. Does anyone have any other experience/ideas with this?
I seek a little help to wrap a package for meteor. It has always been my weakness on this framework. I know it is not difficult, I read tutorials and some articles like :
https://www.discovermeteor.com/blog/wrapping-npm-packages/
http://www.meteorpedia.com/read/Packaging_existing_Libraries
However I get lost in export and stuff, and it is time to understand !
I tried to wrap this package :
https://github.com/fians/Waves
(I knew one day I was going to not find the package already made by someone on atmosphere :()
So I wanted to do the thnings right, following guidelines made by dandv. I forked the repo, add the meteor packages with the files : export.js and package.js. Following the example of moment As you can see here :
https://github.com/Voyag3r/Waves
Finally, in my app, I created the local package folder with the meteor command : meteor create --package voyag3r:waves I tried to called the waves variable, bit it is not defined. I tried with and without a capital letter. (like in the source code waves.js). No, I tried with this.Waves instead of just Waves in export.js, neither.
There is something I do not understand with namespace and visibility I think, and errors are not displaying useful information this time. Is there someone to explain to me ? Because I would like to do a lot of other packages !
Thanks !
Glad to see that you read through those documents above, as they're quite helpful. However, I understand that it can be confusing to work through the details. Hopefully, I can assist you.
I recently finished packaging up a couple of libraries for Meteor, so you should take a look at those repositories as examples:
jspdf:core
jspdf:autotable
More specifically, take a look at the jspdf:core repository above and inspect the meteor-pre.js and meteor-post.js files for how to handle exporting variables:
meteor-pre.js
var window = {};
meteor-post.js
jsPDF = window.jsPDF;
Other important files include package.js and package.json, and of course autopublish.json, for integrating version updates with http://autopublish.meteor.com/, a fantastic tool written by Luca Mussi #splendido.
Additionally, I would recommend that you review the Official Meteor integration directly from 3rd party libraries discussion and ask #splendido or #dandv for assistance with reserving the namespace for this library.
This process has gone through rapid change over the last few months, and although not perfect, it's improving steadily. I'm encouraged to see that, like me, you want to assist the Meteor ecosystem.
My package introduces registry entries. Changes by site administrator should not be overwritten on reinstall of the package.
Many ways to Rome. I chose ftw.upgrade. I like the declarative way of the upgrade step syntax. Its possible to use an upgrade directory for generic setup xml-Files like propertiestool.xml. No need to define handler python code. The upgrade works well. The admin can upgrade from control panel and in my case the new property is added. Insomma: For a new property just these have to be added: an upgrade-step declaration for source and destination version and directory where to find the properties.xml. Thumb up! –
You can pilot what to do when installing a Plone add-on by providing an Extension/install.py file with a install method inside:
def install(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-your.pfile:default')
This way you are driving what Plone should do when installing.
If you need it: the same if for uninstall:
def uninstall(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-example.gs:uninstall')
This way you can prevent the uninstall step to be run when reinstalling.
Warning: as Mathias suggested using quickinstaller -> reinstall feature is bad.
Warning: this will not probably work anymore on Plone 5 (there's open discussion about this).
I think what you describe is one of the problems upcoming with the increasing complexity of Plone's stack, and one of the reasons, why it is not recommended to execute a re-install anymore, but to provide a profile for each version of the Add-On, via upgrade-steps (as Mathias mentioned). That increases dev-time significantly and results in even more conflicts, of my experience. Here are the refering docs:
http://docs.plone.org/develop/addons/components/genericsetup.html#add-upgrade-step
Elizabeth Leddy once wrote an Add-On to ease that pain and I can confirm it does:
https://github.com/ampsport/amp.ezupgrade
And the great guys from FTW, too, I never used it, but looks promising:
https://pypi.python.org/pypi/ftw.upgrade
Neither used this one, even claims to have some extra goodies, like cleanup broken OFS objects and R. Patterson's on it:
https://github.com/collective/collective.upgrade
As we're here, the first good doc I could find about it ~ 1.5 years ago, comes from Uwosh, of course:
http://www.uwosh.edu/ploneprojects/docs/how-tos/how-to-use-generic-setup-upgrade-steps
Another solution can be, to check, if it's an initial- or re-install, and set the properties programatically via a Python-script, conveniently called 'setuphandlers.py', like described in this answer:
How to check, if my product is already installed, when installing it?
That way one can still trigger re-installs without blowing it all up.
Lastly, a lot of the GS-xml-files understand the purge-property, setting it to False, will not overwrite the whole file, just your given props. This might, or not, apply to your case, you can find samples in the above referenced official doc.
first of all, i will explain what i would like to do here : given a C big programm, i would like to output a list of producers/consumers for a data and a list of calling/called-by functions of the function where this data is.
for doing this, i am thinking about using what computes some modules of frama-c, like dataflow.ml or callgraph.ml in my own plugin.
however, as i read the plugin developper doc, i can't manage to see how we can have access to the data of those modules.
is a "open.cyl_type" sufficient here in my own plugin?
moreover, here are my other questions :
i tried using by the way pdg plugin for my purposes but when i call it and it says "pdg graph computed", how can i access it?
is there any more documented thing about "impact" plugin than the official webpage, in depth, how it works fondamentally? (i have to say that i'm in like a pre-project phase, and that i installed frama-c with the apt-get on ubuntu and that i did not get an impact plugin working (i'll see by compiling the sources))
by the way, do you think i'm using the right method to get to my purposes?
Your question is quite unclear, and this answer is thus very generic. As mentioned in the developer documentation, there are two main classes of plugins: static plugins, compiled with the kernel and whose API is exposed in a module (usually of the same name of the plugin) in Db. Dynamic plugins, such as Semantic_callgraph register dynamically their entry points through the Dynamic module.
If you do make doc in Frama-C sources (I'm not sure that there is a corresponding package in Ubuntu) you can access documentation for the Db module in FRAMAC_SOURCE_DIR/doc/code/html/Db.html and the list of functions registered by dynamic plugins in FRAMAC_SOURCE_DIR/doc/code/dynamic_plugins/Dynamic_plugins.html.
I think that, following Virgile's advice, you should get the source code anyway because you will most of the time need to browse the code to find what you are looking for. Beside, you can have a look at the hello_word plug-in (in src/dummy/hello_world) to have an example of a very simple plug-in. You can also find some examples on my web site at https://anne.pacalet.fr/Notes/doku.php?id=notes:0061_frama_c_scripts to find out how to have access to some information in the AST.
Working my way through the Discover Meteor book. The code form chapters on creating postItem templates that include a link to specific posts just doesn't 'work' (no errors, but no result either).
See linked gists for code I'm using [1]. There are no errors in the console. I've also read up about changes introduced in Meteor 0.8 with Blaze and I suspect that this is causing the problem, however, the documentation seems to suggest template helper usage in my case is the same[2] and I can see from looking at various meteor created scripts such as router.js that older templating systems are at least attempted to be supported [3].
Why doesn't this code work? And is there a way to make only slight changes to get it working rather than moving over to iron-router and potentially departing too far from the edition of Discover Meteor that I'm using?
[1] client/views/posts/post_item.html: https://gist.github.com/Trindaz/11139437; client/helpers/router.js: https://gist.github.com/Trindaz/11139409;
[2] http://meteorpedia.com/read/Blaze_Notes#Template Helpers [Note: space before 'Helpers' in this link breaks it] This appears to be more about block helpers than the way I'm using helpers, but seems to be the extent of any discussion on helper usage so I assumed everything else remained unchanged.
[3] https://github.com/tmeasday/meteor-router/blob/master/lib/router_client.js#L88
I found the answer almost immediately after writing this up, leaving question up for future googlers.
The problem seems to be caused by UI.body member assignments at https://github.com/tmeasday/meteor-router/blob/v0.6.1/lib/router_client.js#L89-L90. This breaks changes introduced in Meteor 0.8.0-rc3 https://groups.google.com/forum/#!msg/meteor-talk/oatU1zzcaeQ/54ay-pPlRrwJ.
From the release: "Templates no longer automatically access the helpers of ancestors [11]. If you were declaring helpers with UI.body.helpers you need to switch to UI.registerHelper instead."
This may all be redundant now as work has moved to iron-router.