New Stuff (1)

So I'm going through my example application updating different examples new APEX 3.1 features, as I work through them I'll be posting examples of changes.

So the first one are the changes to the basic example for illustrating Ajax using an OnDemand Process.

Javascript


One of the biggest changes , and one of my favorites , is that in older versions of APEX to pass a value to on OnDemand Process in most cases you would need a application level item that was only used for that purpose , this is no longer needed.

This new functionality is illustrated on line 4 where the global variables x01 gets the value of the textarea to post to the process. There are 10 global variables x01 - x10 , and a few others, so you can pass around quite a few values at once, more in later post.

There are a couple calls to $v('ITEM_NAME') which given an item name returns you the value of the given item.

And $s('ITEM_NAME','Some Value') which given an item name and a value set the value of that item.
* These both work with most the basic item types and will be extended support all item types.

OnDemand Process (SimpleExample)


On line 4 of the OnDemand Process is take getting the value of the global variable. The global variables are only available for that Ajax call and do not get saved into session state.

Simple changes to be sure but they allow for much more generic javascript and easier integration across different application's

14 Comments:

  1. Anonymous said...
    This is EXTREMELY nice. Now we don't have to have all those application items hanging around for no other purpose than to serve and AJAX call. GREAT WORK.

    Now if there were only a way to better debug what is going on in the application process...

    :)
    Dan McGhan said...
    Great job, sometimes the small changes can go a long way.
    Mark Lancaster said...
    It sounds like such a little thing, but this was always something that used to really annoy me.

    I really like the direction Apex is going. Interactive reports has made a big difference on the querying side of things. Can't wait until release 4.0 comes out with user-defined widgets.
    Patrick Wolf said...
    In my opinion application items where overused in the past, because most time a page item could also have been used for passing the value. But the new parameters are nice, especially if you really write generic on-demand processes like for the upcoming custom item types.

    A small code improvement, you should replace page 0 in the htmldb_Get call with $v('pFlowStepId'), see AJAX and page 0 problem for the reason.

    BTW, why is it not possible to define an on-demand process on page level? Most of this processes are page specific, having them all on application level makes it quite hard to track them. Especially if we add more and more AJAX stuff into our applications.

    Greetings
    Patrick
    Arie Geller said...
    Hi Carl,

    First, I didn’t want to hijack Joel’s blog, so thanks on the update about Vikas. I guess when he has you on his IM “speed dial” he can visit the forum less frequently :-)

    And to the current post. I’ve seen that the WWV_FLOW package has G_X01 to G_X10 global variables, and the ACCEPT procedure has x01 to x20 as parameters. Is there any connection between these?

    Thanks,
    Arie.
    Patrick Wolf said...
    Hi Arie,

    they are not related. The x01-x20 parameters for accept have always been there. They are used for example by the report pagination select list. I don't know why this is been done, because pagination never issues a submit, it just redirects. The select list could just skip the name property to tell the browser that the field doesn't have to be submitted...

    Patrick
    Anonymous said...
    Hello Carl

    I have a few questions if you don't mind.

    Is it possible to post x01..x10 global variables with add() method ?

    What is the difference between add() and addParam() ( or perhaps I should ask why didn't you use add() for x01..x10 ?

    Can I set those global variable's values like common items in PL/SQL:
    APEX_UTIL.SET_SESSION_STATE(wwv_flow.g_x01,null);
    ... or is there any more concise way to do it ?


    Kind Regards,
    Matjaz
    Anonymous said...
    There's something I don't get.
    Why do you need a temp item at all?

    try

    on the js:
    get.addParam('P11_TEST',$v('P11_TEST'));

    on the pl/sql:
    l_value := v('P11_TEST');

    it works fine for me.
    Anonymous said...
    Hi Patrick, great work.

    Which difference between htp.p and htp.prn into on demand process?

    Thanks,
    Sergio
    Remco Goris said...
    In reaction to Anonymous:
    Why we need a temp item?
    I don't know how these temp items work, but the only reason that makes sense to me, is that they enable you to define variables and assign a value to them, no matter what the current page.
    In other words: you set the value on page 11, after which the same value is avaible in any page the user navigates to - until you assign it a different value somewhere along the line.

    Can someone please confirm this?
    Remco
    Bronk said...
    Hi guys. I used this example in my project. But I have one problem with umlauts.
    If I am using example on your side, then works excellent. In my project all umlauts returned by proccess have different characters.
    For example: I am using string with "München" and process returned just "Munchen". Please ask me what is problem?
    PS. I am trying to use next code in the proccess on-demand:
    ...
    owa_util.mime_header('text/html', false);
    htp.p('Content-Length: '||length(l_value));
    htp.p('Content-Language: de');
    owa_util.http_header_close;
    ...
    but it's not work.
    Thanks
    pay per head call center said...
    I really enjoy reading the post, thanks for sharing I really like it, I already bookmarked it, thank you guys.
    thargenediad said...
    I miss Carl... :(
    Ideation Fashion said...
    Good share of this post. Thanks.
    www.kellyhandbag.com

Post a Comment