1 2 Previous Next 23 Replies Latest reply: Nov 15, 2007 6:08 AM by wrightusr Go to original post RSS
      • 15. Re: Custom Item Types in future APEX version.
        Arie Geller
        Hi Patrick,

        Thanks for taking the time to clarify some of the issues I mentioned in my post. Reading your reply, and the other posts and references, raised a few more questions with me (it’s OK not to have all the answers. It’s only natural in these early stages of forming the concept).

        As Vikas mentioned in his post, there are many JavaScript toolkits out there that can make your life a bit easier. So let’s say I want to use the table drag&drop effect I saw in one of John’s examples. I think he’s using the Yahoo UI components. I also need some sortable lists, using code from script.aculo.us, and I’m really impressed with some of the graphic manipulation options Dojo (Carl’s favorite) has to offer.

        How these individual components (features) will be imported into APEX? Loading all the JS libraries is not practical. “Cutting” out only the relevant code from theses libraries? Is it legal (I believe most of them allow you to do whatever you want with the code, as long as you keep it intact, and keep their copyright messages)? Creating your own code, based on these libraries? A bit like reinventing the wheel over and over again. What are you going to do with the JavaScript code – loading it into the database as static file? Not very efficient from the browser cache point of view. Store it in the OS file system? What about sites where you don’t have such access, like in apex.oracle.com, or the other public site (like john’s)?

        Dimitri mentioned your ApexLib framework. Do you see a scenario where you can embed it into APEX with only one click of a button (similar to a new application deployment)?

        • 16. Re: Custom Item Types in future APEX version.
          Dietmar Aust
          Custom Item Types in APEX

          <h4>Business need</h4>
          The main intent is to move towards an even more professional platform. Many modern application development environments have the capability to build modules which can be reused in different applications and also to extend the environment via a plugin architecture (Eclipse, Jdeveloper, even Visual Basic right from the beginning). This has many proven merits regarding reusuability, productivity, maintainability and ease of use. Also doing this, it would attract 3rd party development to add even more value to the platform. This way Oracle could focus on building a more modular, pluggable architecture and leverage the community and for profit organizations to build specific features / widgets / extensions.

          I have been used to building portlets for the Oracle Portal platform (http://download.oracle.com/docs/cd/B14099_01/portal.1012/b14134/pdg_pdk_plsql.htm) . Building upon this experience I would like to see the following.

          As outlined before by Patrick using stored packages in the application schema seems like a good idea. You could also install them in a separate shared library schema and grant the proper rights to each application schema that requires it. Thus we would need a registration process to register a plsql package as an Apex extension (during the installation process via an API call) .

          It should be possible to install it via the GUI and also silently via the command line. It should not be a requirement to have access to the FLOWS_xxxx schema but to a privileged account in the workspace.

          Using optional parameters is the key and should definitely be possible. We would need to be able to provide an Apex application which will configure the optional parameters. This way we could provide step by step wizards for more complex needs. Passing a return – url to the configuration application we could return to the calling context once the configuration is completed. This configuration application would be registered, too. The parameters for each extension could be a single value but also a list of multiple values.

          I would also like to separate the general parameters for an extension (global for all instances of the extension) from the parameters for each instance of an extension. This could be achieved by the developer using multiple pages in the configuration application for the global and instance specific parameters.

          Many widgets would use additional files (CSS, images, javascript libraries). For ease of deployment I would like to see them in the database. Mitigating the performance issue we would need a caching mechanism for them (this will be useful for all static files anyway, http headers for caching should be used). Optionally it would be great if we could also change the registration from the uploaded files to a url which will be served by an Apache.

          Including these libraries for the different extensions could cause conflicts (order of CSS files / Javascript libraries). It could be helpful, if the order of inclusion of these widgets could be changed. Or, if the libraries are included in the order in which they are installed, then it should work, too. Thus we could remove the extensions and reinstall them in the proper order.

          <h4>Pie in the sky</h4>
          Ultimately, I would like to be able to provide extensions not only for custom item types, but also for pages and regions as well, where we could build more complex modules. Then we could also generate application processes, validations and other Apex elements, like the built-in wizards.

          It would also be great to somehow "attach" these elements to the extensions. When you look at a COM component for example, the "behavior" is included in the component via event handlers. A grouping mechanism would be really helpful to build true components. Right now, the elements belonging to a component are quite cluttered on the page.

          One example for this could be to generate application parts like the built-in authorization pages (uses a wizard to create a new page). We would walk the user through some wizard steps and finally generate the tables, procedures, page and processes to manage the application specific authorization.


          Message was edited by:
          Dietmar Aust
          • 17. Re: Custom Item Types in future APEX version.

            Stuff that has been added for 3.1

            So I would propose a new one like CUSTOM_WIDGET=[internal widget name] (internal widget name is the name as it is registered with APEX).......

            Internally we also have a call that goes to our Widget 'Factory' for lack of a better term it works basically how you've described. Extending that for direct calls to user widgets absolutely makes sense.

            I'm not so sure yet about parameter passing. Normally in an on-demand process call we write the values to application or page items.......

            OnDemand Process's and the Widget 'Factory' now have access to the global f array and there are 20 global varchar variables ( and one clob) that can be accessed for each request, so there is no more need for application level items and such to hold temporary values.

            So in 3.1 you will be able to take advantage of these features in your OnDemand Process's which is then a small step to User Item/Widgets.


            Message was edited by:
            Carl Backstrom
            • 18. Re: Custom Item Types in future APEX version.

              To fill and use the global f array and the 20 global varchar variables, do we have to use POST now, our still just a normal GET request? I assume we have to use the &f04=abc&f04=xy&f05=... syntax instead of the current f procedure syntax P5_TEST,P5_TEST2:abc,xy to set the values.

              I think it will be a great simplification if it isn't necessary to define application items for the temp. values anymore.

              My APEX Blog: http://inside-apex.blogspot.com
              The ApexLib Framework: http://apexlib.sourceforge.net
              The APEX Builder Plugin: http://sourceforge.net/projects/apexplugin/
              • 19. Re: Custom Item Types in future APEX version.
                For on-demand processes and for the new widget factory interface the engine is invoked by POSTing to wwv_flow.show, the same way on-demand processes work today except that there will be 20 new fxx input array parameters defined in the procedure spec.

                • 20. Re: Custom Item Types in future APEX version.

                  The lines of code
                    p.open("POST", this.base, this.syncMode);            
                  You can see an example already of using the global arrays today in the Save Large Code example http://apex.oracle.com/pls/otn/f?p=22370:8.

                  Instead of posting to a OnDemand Process it posts to a page populating the global arrays. This as just been applied and extended a bit to OnDemand Processes and 'Widget Factory'.

                  • 21. Re: Custom Item Types in future APEX version.
                    Scott: Sorry for being dense but I am not sure I understand how to use the new fxx arrays and not use temp/app items.

                    Today, we do
                    var get=new htmldb_Get(...);
                    get.add('G_ITEM1','some value');
                    The htmldb_Get object POSTs to wwv_flow.show, saving all the .add()ed values into session state thus making them available for use by the on-demand process.

                    What is the new, improved version of this?

                    • 22. Re: Custom Item Types in future APEX version.
                      Scott: Sorry for being dense but I am not sure I understand how to use the new fxx arrays and not use temp/app items.


                      Just so we have this straight these new arrays / items will not be available till "3.1". But it's a usage is basically the same for the global items you will use this something like this.


                      x01 - x020 being new global varchar variables that can be used for posting, they are not saved in session state.

                      And to populate the global fXX arrays you will do something like this (which can be done today if you are using a page as a pseudo OnDemand Process , see the Save Large Value Example)


                      but there will be some new calls in 3.1 to even make populating the global arrays easier.



                      For OneOff OnDemand AJAX functionality it doesn't make a huge difference and application items are still the way to go, especially if you need to hold on to a value. But for building generic AJAX components and user custom items it is essential so as not to clutter applications with items that have no other value than to hold transitory values.


                      It doesn't sound hugely exciting to most people but as a APEX framework change I've had a smile on my face since it was check into Subversion, it makes building most of this stuff immensely easier.

                      Sorry about the 3.1's everywhere I just wanted to be absolutely sure no one wastes time trying to use this today.

                      • 23. Re: Custom Item Types in future APEX version.
                        Carl> Though this is kind've outside the current discussion there will be many ways of getting JSON outputs in a near future version of APEX. Internally we are sold on JSON , well at least I am and everybody else has to listen to me rant about it.

                        Just wondering if there is any update? when can we expect json
                        1 2 Previous Next