IMHO, the JavaScript changes in T5.4 are just amazing. For the first time ever
I have found myself writing significant JavaScript that worked the very first
time it was run! I think it's due to the enforced modularity combined with the
way that RequireJS making modularising oh so easy. In a component-oriented
Tapestry world it's perfect.
To Paul, and others, do these examples cover the situations you are describing?
If not, please say so, so that I will know to add others.
http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/javascript
http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/reusable
http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/robust
http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/mixin
http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/modal/1
http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/reusablemodal/1
http://jumpstart.doublenegative.com.au/jumpstart7/examples/ajax/onevent
http://jumpstart.doublenegative.com.au/jumpstart7/together/ajaxcomponentscrud/persons
Geoff
Do these examples help? If there's a missing situation, please let me know so I
can add an example.
On 13 Nov 2014, at 12:30 pm, Paul Stanton <[email protected]> wrote:
> 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 <[email protected]> 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: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
