-
Notifications
You must be signed in to change notification settings - Fork 123
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.js
if this is package with production code (ordevel.js
if 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 current
You 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 new
For 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.
What would the receiver be in the case of a global JavaScript function like this?
btoa(aValue)
Answer in Amber Smalltalk:
btoa value: aValue
Also note that for console.log('text') the equivalent Amber statement is: console log: 'text'.
more see https://github.com/amber-smalltalk/amber/wiki/From-smalltalk-to-javascript-and-back
This is the place to develop the answer using the material from here https://github.com/amber-smalltalk/amber-documentation/issues/55 before moving it to the web site.
In case the external library is not a proper AMD module, some more work must be done to make it properly loadable by AMD - to shim dependencies; and to shim exports - so module can load itself after its own dependencies; and so it is known when it is loaded so it could itself be used as a dependency of other modules.
Contrary to popular belief, it does not matter at all how the module was installed - bower, npm, by hand, otherwise. Bower is just very convenient because it manages all the dependencies, version clashes and upgrades gracefully.
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.json
file in the root directory of the library. - the path used in
local.amd.json
is 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 devel
to construct aconfig.js
file. - some libraries do not provide a
local.amd.json
. In that case you have to provide an*.amd.json
file namedlibrarydirectoryname.amd.json
and 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.json
file.
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
imports:
specifies dependencies of a package that it needs to load before it can be loaded itself. If such dependencies cannot be found, load fails. Imports are defined at two places: first, as actual dependencies of compiled .js
module; second, as metadata for the Smalltalk level, so IDE can show / modify them.
Recovering from invalid imports:
not allowing app to load is two-stage: first remove the invalid dependency from the define([...list of dependencies...], function(...import varnames...) {...code of package...});
call in the .js
file itself. The define
call is the first and only things in the .js file (as the function with code of the package span the while file). Just edit out the wrong dependency from [...list of dependencies...]
and if it was bound to import variable, remove its name from ...import varnames...
as well.
The app now should load, even if it will probably have errors from the fact that the dependency is missing. Now, the second stage is to actually fix the imports:
line itself in the IDE (as the metadata are still with the old values), putting correct values there, save, commit and if the fix was correct, successfully reload with correct dependencies loaded.