You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Greg Brown <gk...@mac.com> on 2009/09/25 03:05:45 UTC

Element-based event handlers in WTKX

Hi all,

You may have noticed another change I recently checked in - a <wtkx:script> tag is no longer required for element-based event handlers. Since the scripting language is now specified at the page level, the <wtkx:script> tag is no longer needed here. This helps to further reduce the amount of "clutter" in your scripted WTKX files.

This does mean that you can no longer use script defined in an external file to implement event handlers. Though that was previously supported, it was counter to the intent of the inline event handlers, which are meant to place the event handler logic near the element to which it applies. You can, of course, still define <wtkx:script> blocks elsewhere that do include externally defined script files.

Let me know if you have any questions...

Greg


Re: Element-based event handlers in WTKX

Posted by Greg Brown <gk...@mac.com>.
> What I'd do in this case is to set the application instance into the  
> scope of the WTKXSerializer, so that script blocks can see the  
> 'application' reference.

The iTunes Search demo (org.apache.pivot.demos.itunes.SearchDemo) does  
exactly this. You can also take a look at that class for an example.


Re: Element-based event handlers in WTKX

Posted by Todd Volkert <tv...@gmail.com>.
What I'd do in this case is to set the application instance into the scope
of the WTKXSerializer, so that script blocks can see the 'application'
reference.  Below is an example:

public class ScriptTest implements Application {
    private Window window = null;

    public void loadData() {
        System.out.println("loadData()");
    }

    @Override
    public void startup(Display display, Map<String, String> properties)
        throws Exception {
        WTKXSerializer wtkxSerializer = new WTKXSerializer();
        wtkxSerializer.put("application", this);
        window = (Window)wtkxSerializer.readObject(this,
"script_test.wtkx");
        window.open(display);
    }

    @Override
    public boolean shutdown(boolean optional) {
        if (window != null) {
            window.close();
        }

        return false;
    }

    @Override
    public void suspend() {
    }

    @Override
    public void resume() {
    }

    public static void main(String[] args) {
        DesktopApplicationContext.main(ScriptTest.class, args);
    }
}

<Window maximized="true"
    xmlns:wtkx="http://pivot.apache.org/wtkx"
    xmlns="org.apache.pivot.wtk">
    <content>
        <BoxPane styles="{padding:10}">
            <PushButton buttonData="Load Data">
                <buttonPressListeners>
                    <![CDATA[
                    function buttonPressed(button) {
                        application.loadData();
                    }
                    ]]>
                </buttonPressListeners>
            </PushButton>
        </BoxPane>
    </content>
</Window>

Hope that helps,
-T

On Fri, Sep 25, 2009 at 6:34 AM, Gregor Aisch <gk...@vis4.net> wrote:

> what do i have to do to call functions of my main application class from
> wtkx event handlers? say loadData() is a public function of my application
> class (the one which reads and binds the wtkx), the following doesn't work:
>
> <PushButton buttonData="load">
>   <buttonPressListeners>                             function
> buttonPressed(button) {
>            loadData();
>       }
>   </buttonPressListeners>           </PushButton>
>
> i get the following exception:
>
> javax.script.ScriptException:
> sun.org.mozilla.javascript.internal.EcmaError: ReferenceError: "loadData" is
> not defined.
>
>
>
> Greg Brown schrieb:
>
>  Hi all,
>>
>> You may have noticed another change I recently checked in - a
>> <wtkx:script> tag is no longer required for element-based event handlers.
>> Since the scripting language is now specified at the page level, the
>> <wtkx:script> tag is no longer needed here. This helps to further reduce the
>> amount of "clutter" in your scripted WTKX files.
>>
>> This does mean that you can no longer use script defined in an external
>> file to implement event handlers. Though that was previously supported, it
>> was counter to the intent of the inline event handlers, which are meant to
>> place the event handler logic near the element to which it applies. You can,
>> of course, still define <wtkx:script> blocks elsewhere that do include
>> externally defined script files.
>>
>> Let me know if you have any questions...
>>
>> Greg
>>
>>
>>
>
>

Re: Element-based event handlers in WTKX

Posted by Gregor Aisch <gk...@vis4.net>.
what do i have to do to call functions of my main application class from 
wtkx event handlers? say loadData() is a public function of my 
application class (the one which reads and binds the wtkx), the 
following doesn't work:

<PushButton buttonData="load">
    <buttonPressListeners>                       
        function buttonPressed(button) {
             loadData();
        }
    </buttonPressListeners>           
</PushButton>

i get the following exception:

javax.script.ScriptException: 
sun.org.mozilla.javascript.internal.EcmaError: ReferenceError: 
"loadData" is not defined.



Greg Brown schrieb:
> Hi all,
>
> You may have noticed another change I recently checked in - a <wtkx:script> tag is no longer required for element-based event handlers. Since the scripting language is now specified at the page level, the <wtkx:script> tag is no longer needed here. This helps to further reduce the amount of "clutter" in your scripted WTKX files.
>
> This does mean that you can no longer use script defined in an external file to implement event handlers. Though that was previously supported, it was counter to the intent of the inline event handlers, which are meant to place the event handler logic near the element to which it applies. You can, of course, still define <wtkx:script> blocks elsewhere that do include externally defined script files.
>
> Let me know if you have any questions...
>
> Greg
>
>