Re: [5.4] javascript - simplify the new paradigm please

2014-11-18 Thread Paul Stanton
Chris, can you point me to an example of this? thanks, p. On 18/11/2014 10:53 AM, Chris Poulsen wrote: I'm moving more of the initializer code over to get client id's etc. from data attributes - the "scanner" pattern for initialization that can be seen in some of tapestrys own components works

Re: [5.4] javascript - simplify the new paradigm please

2014-11-17 Thread Chris Poulsen
I'm moving more of the initializer code over to get client id's etc. from data attributes - the "scanner" pattern for initialization that can be seen in some of tapestrys own components works really well (as opposed to setting up javascript modules with an initializer call as you have in your examp

Re: [5.4] javascript - simplify the new paradigm please

2014-11-17 Thread Geoff Callender
Yes indeed. The reason I've developed the habit of using afterRender() is that so often we need to pass the clientId of an embedded component to the JavaScript. In afterRender() we can be sure that all clientIds have been assigned. So now I just use afterRender() without giving it a second tho

Re: [5.4] javascript - simplify the new paradigm please

2014-11-17 Thread Thiago H de Paula Figueiredo
On Mon, 17 Nov 2014 09:30:51 -0200, Chris Poulsen wrote: I tend to think of the the "after render requires" as initializers, Actually, it can be used inside beginRender() or setupRender() with the exact same result. :) Tapestry will only actually add the JavaScript stuff after the whole

Re: [5.4] javascript - simplify the new paradigm please

2014-11-17 Thread Chris Poulsen
I tend to think of the the "after render requires" as initializers, and the ajaxResponseRenderer (ARR) callbacks as the place to do interaction. I do not think of toggle calls like (show/hide timer) as real initializers. We still use .require to get the client side module "injected" in the ARR, b

Re: [5.4] javascript - simplify the new paradigm please

2014-11-17 Thread Geoff Callender
Hey, hang on, Chris, weren't you the one who asked "can't you just use javascriptsupport to require and invoke your js module function?". That's what got me doubting the "rule of thumb" that I'd written! Am I missing your point? Cheers Geoff On 17 Nov 2014, at 8:56 pm, Chris Poulsen wrote:

Re: [5.4] javascript - simplify the new paradigm please

2014-11-17 Thread Chris Poulsen
We're doing something like this in event handlers to perform callbacks void onSetupDialog( @RequestParameter( "params" ) JSONObject json ) { initialLoad = false; extractParams( json ); ajaxResponseRenderer.addRender( "linkDialogModal", ( ( org.apache.ta

Re: [5.4] javascript - simplify the new paradigm please

2014-11-17 Thread Chris Poulsen
You are probably asking for trouble if you try to misuse "initializers" in this way (which also explains why two identical init statements results in only one being executed) -- Chris On Mon, Nov 17, 2014 at 8:45 AM, Charlouze wrote: > Geoff, > > AFAIK, JavascriptSupport is only available at r

Re: [5.4] javascript - simplify the new paradigm please

2014-11-16 Thread Charlouze
Geoff, AFAIK, JavascriptSupport is only available at render time and ajax render doesn't start until after your event handler returns something. I think it's because tapestry doesn't know what will need to be rendered yet. For your second question, I think you can achieve what you want if you pas

Re: [5.4] javascript - simplify the new paradigm please

2014-11-16 Thread Geoff Callender
Chris, It looks like the "rule of thumb" that I stated was wrong. I've just used JavaScriptSupport#require in some AJAX event handlers. Can someone explain under what circumstances we have to use AjaxResponseRenderer#addCallback instead of JavaScriptSupport#require ? Is it something to do with

Re: [5.4] javascript - simplify the new paradigm please

2014-11-16 Thread Paul Stanton
Geoff, After some testing I can really see the benefits in how you achieve this... One of my main prior misunderstanding was that the 'define' is only run once (I thought it would be re-run each 'require'), making similar to a 'static' object in some ways, in that the state is then shared by

Re: [5.4] javascript - simplify the new paradigm please

2014-11-14 Thread Paul Stanton
Thanks Geoff, Im going to have to play around with this and see what is happening under the covers. I'll get back... cheers, p. On 14/11/2014 3:06 PM, Geoff Callender wrote: I accidentally left out the object's state vars. Added below. On 14 Nov 2014, at 10:00 am, Geoff Callender wrote:

Re: [5.4] javascript - simplify the new paradigm please

2014-11-13 Thread Geoff Callender
I don't think so. I believe the rule of thumb is to use JavaScriptSupport during render, and use an AJAX callback during partial page render. IIRC, the JavaScriptSupport environmental is not available when you're handling an AJAX component event request. On 13 Nov 2014, at 6:08 pm, Chris Poul

Re: [5.4] javascript - simplify the new paradigm please

2014-11-13 Thread Geoff Callender
I accidentally left out the object's state vars. Added below. On 14 Nov 2014, at 10:00 am, Geoff Callender wrote: > Yep, that's a valid case, and it's one I have to put into JumpStart. > > Here's the way I handle it. I'd like to see what others do. > > Have the module keep an array of objects

Re: [5.4] javascript - simplify the new paradigm please

2014-11-13 Thread Geoff Callender
A better example would be where the client-side objects have considerable state, eg. a Graph object or, more complex still, a Graph editor. Of course, client-side objects may be avoided having your javascript save/retrieve all state to/from hidden fields in the relevant part of the DOM, but th

Re: [5.4] javascript - simplify the new paradigm please

2014-11-13 Thread Geoff Callender
Yep, that's a valid case, and it's one I have to put into JumpStart. Here's the way I handle it. I'd like to see what others do. Have the module keep an array of objects, identified by a key. The server-side can provide the key when initialising and later whenever invoking a function. The compo

Re: [5.4] javascript - simplify the new paradigm please

2014-11-13 Thread Paul Stanton
Oh, so calling require("modal").invoke("activate") and then later require("modal").invoke("deactivate") .. both re-construct a seperate "modal" js object and then call one of the two published functions... what if you have two different modals? what if they are init-ed differently: java:aft

Re: [5.4] javascript - simplify the new paradigm please

2014-11-13 Thread Howard Lewis Ship
The change in JavaScript is to support several goals: - A good transition from Prototype.js to jQuery (or perhaps something else in the future) - Reduce the total amount of JavaScript sent to the client - Allow more of the JavaScript to transfer in parallel - Make it easier to override Tapestry's b

Re: [5.4] javascript - simplify the new paradigm please

2014-11-12 Thread Chris Poulsen
can't you just use javascriptsupport to require and invoke your js module function? -- Chris On Thu, Nov 13, 2014 at 6:34 AM, Geoff Callender < geoff.callender.jumpst...@gmail.com> wrote: > Have you had a look at these two: > > > http://jumpstart.doublenegative.com.au/jumpstart7/examples/javasc

Re: [5.4] javascript - simplify the new paradigm please

2014-11-12 Thread Geoff Callender
Have you had a look at these two: http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/modal/1 http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/reusablemodal/1 Do they fit your scenario? On 13 Nov 2014, at 3:40 pm, Paul Stanton wrote: > H

Re: [5.4] javascript - simplify the new paradigm please

2014-11-12 Thread Paul Stanton
Hi Geoff, I have found your examples invaluable in learning some of the basics of this (and other) concepts. I can't thank you enough .. the only thing I can see is missing currently is the example I asked about in the previous mail: Basically, how do I interact with a js module instance a

Re: [5.4] javascript - simplify the new paradigm please

2014-11-12 Thread Geoff Callender
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 comp

Re: [5.4] javascript - simplify the new paradigm please

2014-11-12 Thread Paul Stanton
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

Re: [5.4] javascript - simplify the new paradigm please

2014-11-12 Thread Kalle Korhonen
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,

Re: [5.4] javascript - simplify the new paradigm please

2014-11-12 Thread Thiago H de Paula Figueiredo
On Wed, 12 Nov 2014 19:08:44 -0200, Paul Stanton wrote: How do I execute some javascript in the render phase of a component which creates an object and then refer to that object when handling an async event for the same component? It seems you want to invoke a page or component method fr

Re: [5.4] javascript - simplify the new paradigm please

2014-11-12 Thread Paul Stanton
Or try this simple question: How do I execute some javascript in the render phase of a component which creates an object and then refer to that object when handling an async event for the same component? Please excuse me if this is documented somewhere, I cannot find it. On 13/11/2014 7:41 A

Re: [5.4] javascript - simplify the new paradigm please

2014-11-12 Thread Thiago H de Paula Figueiredo
On Wed, 12 Nov 2014 18:41:48 -0200, Paul Stanton wrote: Hi Thiago, Hi! Do you think you could put aside the dissection of my question and defence of position and just answer the question to be helpful? Your questions were vague, so I couldn't provide a good answer. I am not trying to

Re: [5.4] javascript - simplify the new paradigm please

2014-11-12 Thread Paul Stanton
Hi Thiago, Firstly thanks for the reply. Do you think you could put aside the dissection of my question and defence of position and just answer the question to be helpful? I am not trying to start an idealogical conversation or criticise anyone or any way of thinking but would love for you t

Re: [5.4] javascript - simplify the new paradigm please

2014-11-12 Thread Thiago H de Paula Figueiredo
On Wed, 12 Nov 2014 09:13:43 -0200, Paul Stanton wrote: Hi, 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 Require.js is actually used by Tapestry 5.4. I'm not sure what you mean by Closure (t

[5.4] javascript - simplify the new paradigm please

2014-11-12 Thread Paul Stanton
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 fro