-
Notifications
You must be signed in to change notification settings - Fork 120
FAQ
- Click on any class
- In the code browser pane change the code to
Object subclass: #SomeNewClass
instanceVariableNames: ''
package: 'Myapp-NewPackage'- Click on Save
- Select the package Myapp-NewPackage
- Click on Commit
- Edit
deploy.jsif this is package with production code (ordevel.jsif this package contains tests or other non-production code) to include the new package'amber-myapp/Myapp-NewPackage' - Run
grunt devel - Reload localhost:4000
- The new package Myapp-NewPackage shows up in the Browser.
Example of the new deploy.js file:
define([
'amber/deploy',
// --- packages to be deployed begin here ---
'amber-myapp/Myapp',
'amber-myapp/Myapp-Data'
// --- packages to be deployed end here ---
], function (amber) {
return amber;
});Note: Helios version should be added here as well.
If you wish to extend core Amber classes with extra methods, and commit those changes without overwriting the Kernel-Objects.js file (for example), you must set a "Method Protocol" for the method and enter the protocol of "*MyPackage" where "MyPackage" is the package you want to commit that method to. This is exactly like "class extensions" in Monticello in Pharo/Squeak etc and makes sure that the method belongs in the MyPackage package and not in the package of the extended class.
You have to use JQuery for doing that:
html p asJQuery html: '<p>hello world</p>'Following the Seaside convention:
html p with: [
html a
href: 'http://www.google.fr';
with: 'Google' ]Events are fired and consumed in Amber via the "Announcements" system. To use announcements, first you need an instance of Announcer. There is already a SystemAnnouncer for example, which can be obtained through:
announcerInstance := SystemAnnouncer currentYou can also create your own single instance of Announcer or a subclass of it.
Then you need a class for each announcement (see SystemAnnouncement and subclasses).
Announcement classes don't necessarily need any methods.
Sending announcements is as easy as:
announcerInstance announce: AnnouncementClass newFor receiving announcements you have to register a callback for the desired announcement class like the following:
announcerInstance on: AnnouncementClass do: [:announcement | "do something when announcement occurs"]All Smalltalk instance variables can be accessed as JavaScript properties by adding an @ sign in front of their name. For example, to access the counter variable of class Counter you would do the following:
Counter>>assignTwo
< self[ "@counter" ] = 2; >I have an error Commit failed for namespace "test_amber". Do you want to commit to another path?
Directory (\new_test\src) exists. In the directory there are two files (AmberTest.st & AmberTest.js) created by the wizard initialization (amber init).
Answer: Make sure you have started amber serve from within the project directory or in case you did that if it is still running.
Note: Dots are not allowed in the namespace.
Assuming I have a field with an id of #field1, how do I get the text value of it?
Answer:
'#field1' asJQuery val
Note:
All Javascript methods in jQuery are available to you this way.
Multi parameter functions are then mapped like:
aQuery.sampleFunc (a,b,c);
aQuery sampleFunc: a and: b and: c.
The and: can be whatever. The only thing that matters is the first part of the keyword selector which has to match the function name.
What would the receiver be in the case of a global JavaScript function like this?
btoa(aValue)
Answer in Amber Smalltalk:
btoa value: aValue
more see https://github.com/amber-smalltalk/amber/wiki/From-smalltalk-to-javascript-and-back
I am integrating a JavaScript library and I need to add it's *.amd.json file, what should I use as path there?
- each library needs its own
local.amd.jsonfile in the root directory of the library. - the path used in
local.amd.jsonis relative to the library directory. Every single mapping is always resolved from the directory of the library. - the *.amd.json files are used by
grunt develto construct aconfig.jsfile. - some libraries do not provide a
local.amd.json. In that case you have to provide an*.amd.jsonfile namedlibrarydirectoryname.amd.jsonand keep it in the root directory of your project, the project which uses the library. But the path to be used is still relative to the library directory as it would be in alocal.amd.jsonfile.
Some examples of *.amd.json files
- https://github.com/herby/amd-config-builder
- http://stackoverflow.com/questions/27374889/how-to-add-a-non-amber-library-with-bower-for-example-processing-js
.min.js files are already minified, thus not readable / debuggable. But you develop an app (or lib), and during development (set by grunt devel) it is much better to have all files in non-minified human-readable form. Once you want to deploy an app, you do grunt deploy which minifies every file your app uses, including libraries. So, in deployed form, you don't lose the minifier advantage.
Source: 47
