Thank you both of you for your responses ... I am learning a lot and
think I'm close to what I need to convert at least some of my work.
However I am still stumbling on this one use case which can be summed up
by the following question:
"How do I refer back to an object which was created and returned from
within 'define'"
ie:
java:afterRender()
{
js.require("module").with("xyz");
}
java:onSomeAsyncEvent()
{
js. ??? // do something with module instance?
}
I'm getting the feeling that the answer might be "it isn't" .. that all
future communication between server and client is achieved via
triggering/handling events... however there is a lot of ambiguity
(possibly due to my lack of understanding, and the abstraction caused by
coffee?) in the source code.
Looking through the tapestry source as advised yields some questions,
for example, t5/core/confirm-click.js:
return {
runDialog: runDialog
};
Why does this return this function, and how is that used/referenced
elsewhere?
and t5/core/autocomplete.js:
(function() {
define([...], function(dom, ajax, $, _arg) {
var exports, extendURL, init;
...
init = function(spec) {
return $field.typeahead({
...
});
};
return exports = init;
});
}).call(this);
I don't understand why 'init' returns the result of '$field.typeahead'
and what the "return exports = init;" achieves and how any of this is
referred to later on?
Thanks, p.
On 13/11/2014 8:26 AM, Kalle Korhonen wrote:
Well, let me try to answer as well. I just rewrote one, simple old school
component to new T5.4, perhaps that's one good data point. I find that the
biggest difference is in attaching the event handlers and in the
initialization, much else is the same. Objects are overrated for data
encapsulation, variables trapped in closures serve the same purpose.
As always, Tapestry's own source code is invaluable for understanding how
things work, and often (perhaps not always) a good example of best
practices. Namespace collisions are often less of a problem for a developer
writing the web application but always an issue when developing components
for general use. If you imagine multiple components from different sources
working together, you can see how they might start stepping on each other
fairly quickly, and those problems are hairy to debug and difficult to
solve, so best to avoid in the first place.
See my recent commit:
https://github.com/tynamo/tynamo-federatedaccounts/commit/b48cf6e9338107b90cea8ad3bff6e75a90868bfd
together with the origin javascript:
http://svn.codehaus.org/tynamo/trunk/tynamo-federatedaccounts/tynamo-federatedaccounts-core/src/main/resources/org/tynamo/security/federatedaccounts/components/CollapsiblePanel.js
You can see how there's even a pretty much unnecessary use of a class there.
Javascript for built-in components are at
https://github.com/apache/tapestry-5/tree/master/tapestry-core/src/main/coffeescript/META-INF/modules/t5/core.
It's often required to take a look at the corresponding .java source
understand how it all fits together.
The documentation that Howard wrote on this is actually excellent, see
http://tapestry.apache.org/client-side-javascript.html and
http://tapestry.apache.org/javascript-modules.html, but like any other new
programming concept, requires you to actually learn it, not just just
reading it through.
Coffeescript is another topic. The good thing is you don't have to get into
it at all if you don't want to. I like the syntax but I'm still not sure if
it's worth the additional complexity. Anyway for transcompiling on-the-fly,
tapestry-webresources is great and takes all the pain away when developing
your own web app.
Kalle
On Wed, Nov 12, 2014 at 3:13 AM, Paul Stanton <pa...@mapshed.com.au> wrote:
Hi,
so like many developers (i'm guessing) I'm not quite up to speed with all
these new javascript frameworks: requirejs, closure, etc etc and to be
honest I really didn't see a problem with the namespace model of the past.
I'm not open to learning but it seems like a paradigm far removed from what
i'm used to. it doesn't seem object oriented at all for example.
that aside, can someone please point me (and other readers) to some basic
examples to get us started in this brave new world. the first thing I would
like to achieve is to be able to call some page or component specific
marshalling code with page/component context parameters.
your helpful attitudes will be appreciated!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
