and Mike. I collected them for my own use, but I hope they will turn out
to be helpful to anyone who needs to get started with mkws.
+Environment
+-----------
+
+apt-get install yui-compressor
+get nodejs, sudo make install, ln -s /usr/local/bin/npm ~/bin/npm if needed
+
+cd .../mkws; make check
+
+
+Apache
+------
+You need to set up a local apache.
+ * add 'mkws' in /etc/hosts to point to 127.0.0.2
+ * symlinked .../mkws/tools/apache2/mkws-heikki to /etc/apache/sites-available
+ * a2ensite mkws-heikki
+ * a2enmod rewrite
+ * a2enmod headers
+ * service apache2 reload
+ * Check that your browser sees somethig in http://mkws/ and
+ http://mkws/jasmine-popup.html. If need be, enable javascript etc.
Libraries
---------
Include files
-------------
-The whitepaper says to include mkws-complete.js. This file is made by concatenating
+The manual says to include mkws-complete.js. This file is made by concatenating
a number of files (see Makefile). For us developers, it is easier to include the
raw files, as in
Unit tests
----------
-if you want understand the test than you can look at mkws/test/spec/mkws-config.js
+Tests are based on jasmine. a general description of jasmine is on
+http://jasmine.github.io/1.3/introduction.html
+
+If you want understand the test than you can look at mkws/test/spec/mkws-config.js
and mkws/test/spec/mkws-pazpar2.js . See also mkws/test/README.txt
+The test scripts are included from the test page, for example
+mkws/examples/htdocs/jasmine-popup.html has
+<script type="text/javascript" src="test/spec/mkws-pazpar2.js"></script>
+
+
+
Structure of mkws.js
--------------------
(This will soon be out of date, but should provide some kind of starting
-point even then)
+point even then. This is taken directly from a Skype chat with Mike, where
+he explained the whole thing.)
First page is just helper functions for the Handlebars template library, which we
use to generate some of the HTML output. (Down the line, we will use this more
am working on right now.
Next, a very short stanza of code that just makes sure mkws_config is defined:
-simple applications won't bother to define it at all since they override node
+simple applications won't bother to define it at all since they override none
of the defaults.
Next, a factory method for making widget objects. At present this is trivial
You're familiar with this JS idiom?
(function() { code ... })();
- Runs the code immediately, but within its own namespace. That's what we do for
+Runs the code immediately, but within its own namespace. That's what we do for
all the remaining code in mkws.js. In this case, we pass the jQuery object into
that namespace under the name `j' for reasons that are frankly opaque to me.
(You will notice that the teams have a debug() function which delegates to this
but adds some other useful team-specific stuff.)
- Next up: the utility function mkws.handle_node_with_team(). We use a LOT of nodes
+Next up: the utility function mkws.handle_node_with_team(). We use a LOT of nodes
that have their team-name in a class (as in "mkwsTeam_NAME" outlined above).
All the utility does is parse out that team-name, and the widget-type, from the
classes, and pass them through to the callback.
using new-style elements. This is the code you just fixed.
Straight after that, more fixup: elements that have an mkws* class but no
-team are given an extra class kwsTeam_AUTO. This is the ONLY thing that's special
+team are given an extra class mkwsTeam_AUTO. This is the ONLY thing that's special
about the team "AUTO" -- it has no other privileges.
- Very near the end now: we walk through all nodes with an mkws* class, and create
+Very near the end now: we walk through all nodes with an mkws* class, and create
the team and widget objects using the factories we described earlier. Jason is
worried this will be slow, hence the instrumentation. It's not :-)
projects / mkws-moved-to-github.git / blobdiff