1 2 Previous Next 23 Replies Latest reply on Nov 15, 2007 12:08 PM by Wrightusr-Oracle

    Custom Item Types in future APEX version.


      Per this comment by Patrick Wolf

      Re: APEX 3.1 Enhancements

      The APEX team is looking for more opinion and feedback on this particular feature.

      How would you like it to work?
      What would your minimum requirements be ?
      What would you pie in the sky features be ?
      Should it be application level , workspace level, schema level etc...............

      Patrick has a very complete write up of what he would like in a custom item type so please take a look at that first before posting.

      Looking forward to your comments.

        • 1. Re: Custom Item Types in future APEX version.
          Just my 2c.

          See Scriptaculous

          IMHO it is not that difficult to integrate third party controls/widgets into an APEX application. It all depends on how sophisticated and "pluggable" the client-side library you use is.

          Most of the professional JS widget frameworks out there (http://www.turboajax.com/products/turbowidgets/examples) don't really expect any particular web development tool, they can be plugged into any existing application. For instance, they would convert a standard text input box into either a slider or a "autocomplete/suggest" and attach the necessary client-side Javascript to manipulate the DOM. Accept processing wouldn't even care about all this stuff since as far as it is concerned, it is just getting the usual POST with traditional HTML form inputs.

          The new Shuttle item type introduced in v3.0 is an example of this. The core APEX engine (server side) has no clue that this item type even exists as far as accept processing is concerned. All that seems to have been done is add "Shuttle" to the Display As LOV on Page 4000:4311. The rest of the page is unchanged. We could just as well have created 2 textarea items with the arrow images between them and called Carl's magic dhtml_ShuttleObject to initialize all the client-side Javascript necessary. And use the _2 textarea item's value as the real value to use for that item. Something like that. Same goes for the color picker item. There are dozens of client-side color pickers out there that can be very easily integrated into an APEX page. There was no need (IMHO) for APEX to add it as a display-as type.

          Don't get me wrong, Patrick's feature request write-up is top-notch, I just don't see the need for the APEX team to invest time/effort into this. Just provide us as many hooks as possible into the DOM, make it as "open" as possible so that we can easily plug in our JS widget library of choice.
          • 2. Re: Custom Item Types in future APEX version.

            I think it's not so much for the people that 'can' build the javascript which I agree is easy.

            But for the declarative / wizard only developer that can get a custom item edit page and and integrated javascript and custom html rendering at runtime.

            • 3. Re: Custom Item Types in future APEX version.
              But for the declarative / wizard only developer

              But that's just it. A custom item type, taking Patrick's first-cut proposal, would take a high degree of proficiency with PL/SQL. What with writing custom PL/SQL to render the item and what not. So, right there, it would turn off the "declarative/wizard-only developer", your target audience for this feature!

              Or just target this feature for the experienced PL/SQL developer who is not-so-comfortable with client-side Javascript/DOM scripting (I am sure that is a large audience!)
              • 4. Re: Custom Item Types in future APEX version.
                I think what is important in Patrick's proposal is that these "customer types" could be reused without deep understanding of underling pl/sql, javascript, html, .... Most of the users don't need to know how for instance POPUP LOV is implemented - we just select type from drop down list.

                Add-Ons made FireFox much better browser than IE (at least for me). I don't know how FireBug works but I use it every day.

                I don't think that Vikas's and Patrick's suggestions contradict one another - we need both - create our own functionality and reuse functionality created by others.

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

                  I think the discussion shouldn't be to much about if the developer is skilled enough to add some javascript code or to write PL/SQL code.

                  I see it more from a productivity point of view for all developers, independent of there skills. Sure I can add the necessary Javascript code for each page item which I want to change into another widget. Look into the documentation which code I have to use, add it somewhere onto the page so that the code is executed. But wouldn't it be much more productive to just select the widget type from the select list and then I'm done??? Isn't that why APEX development is so productive, because it's a declarative development tool and not a code generator like most Java IDEs?

                  And I think it's much more self declaring if I or someone else is looking a month later into the page and immediately see which widget type is used and I don't have to look where I put the javascript code to change the widget.

                  I tend to reduce the complexity and the amount of code I have to write, because in the end you always have to maintain this code. That was for example also a reason why I started to write the ApexLib framework. Sure there was Carl's excellent example how to write an AJAX cascading lov. Sure I could have written each time the necessary Javascript code and on-demand processes. But in the end it's not productive and with the framework I don't have to care anymore. Now a cascading lov is a 1 min action.

                  Do we remember the pre-3.0 time when we didn't have the Shuttle control? Have a look at Carl's example page at http://apex.oracle.com/pls/otn/f?p=9655:5 for how many steps you have to do to integrate it. Sure it's doable, but look now in 3.0, it's just a click away...

                  Another reason why I proposed that enhancement request, was that I thought it would help to open up APEX a little bit and create a plugin "market" (not commercial). Just look at the Firefox and Eclipse community. Easy pluggable solutions instead of long "How-Tos", I think that's the way to go.

                  Just my two cents for the discussion, but I think Carl is more looking for technical aspects and ideas what developers would require from such a feature... :-)

                  My APEX Blog: http://inside-apex.blogspot.com
                  The ApexLib Framework: http://apexlib.sourceforge.net
                  The APEX Builder Plugin: http://sourceforge.net/projects/apexplugin/
                  • 6. Re: Custom Item Types in future APEX version.
                    John Edward Scott
                    I agree with everything said so far ;)

                    I think we have to make the differentiation between the developers who are comfortable adding AJAX and JavaScript libraries to their application and the other (far higher) number of developers who either aren't comfortable doing it or (more likely) don't have time in the project schedule to even begin what sometimes seems like a huge task initially.

                    So, I think a 'plugin' type of functionality would be very useful, not just because it would make every developers life easier, but also it could (if implemented that way) allow people to create their own plugins that could be reused by other people. For example at the moment integrating the Google AutoSuggest is not that difficult, however it could be made much easier if APEX developers were able to download a plugin that someone else had already pre-created which performed 99% of the things that you need to do (I don't think we'd ever achieve 100% integration simply because it's too difficult to cover all the angles).

                    Ideally I guess I'd like to see the "HTMLDB Studio" reinvigorated with various 'plugins' that developers could download make the integration of 'Foo Widget' or 'Bar Widget' much easier. Although obviously anyone who has looked at the Studio lately will see that ultimately these things only work if people contribute to them too.

                    I agree 100% with Patrick about the 'plugin market', other communities seem to do this easily, whereas with APEX we just don't seem to 'share' those things as much (for various reasons, some of which are very valid of course).

                    So, I haven't added anything of technical merit here, but I did want to cast a vote to see a feature like this implemented (although I appreciate that it's far from straightforward).
                    • 7. Re: Custom Item Types in future APEX version.
                      Hi All

                      I agree that it would be good to have a custom type so advanced developers could build their own widgets.

                      What I would prefer instead is just the data, either in an XML or JSON format.
                      This gives the maximum flexibility, allowing the developer to manipulate the data any way they want, before passing the data back in the same format for processing.

                      Ideally, you could also optionally pass metadata about the fields also, such as datatype, optional/mandatory, upper/lower bounds for numbers, format masks, allowable values for LOVs etc.
                      This would preferably be done in a separate AJAX request.

                      There are already many advanced AJAX toolkits available, just see http://ajaxpatterns.org for a list.

                      The Apex pl/sql engine is where the product excels, in it's role as a controller in a MVC architecture.
                      The current templates and widgets are looking decidedly "Web 1.0".
                      With so many "Web 2.0" toolkits available, Oracle needs to update the engine to output just data so developers can bolt in their favorite AJAX toolkit, or,
                      update the templates currently provided to have a "Web 2.0" flavor.

                      Presently I am using a "grid" control which allows users to resize columns, hide/show columns, lock and sort columns. Any changes the user makes persist between page refreshes.
                      All of this functionality is provided by the AJAX toolkit I am gradually integrating into our application.
                      But in order to implement it, I use a basic HTML table template, and then use javascript to interpret it, convert it to JSON and then re-render it using the AJAX toolkit.

                      Obviously eliminating these extra steps is preferable.

                      In summary, a custom type which just provides the data in JSON or XML format would be a winner for me.


                      Mark Lancaster
                      • 8. Re: Custom Item Types in future APEX version.

                        But in order to implement it, I use a basic HTML table template, and then use javascript to interpret it, convert it to JSON and then re-render it using the AJAX toolkit.

                        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.

                        • 9. Re: Custom Item Types in future APEX version.
                          Something technical :-)

                          1) Reading through Mark's posting, I was thinking if it wouldn't be useful to have an optional second hook for same basic validations of the custom widget. Which is called when the page is submitted (eg. before the validations are fired), so that the custom widget can do a check if the integrity of the submitted value is ok. For example to check for upper/lower bounders, numberic, ..., values contained in lov. Because as we know, the data from the browser can be faked, but also to offer some automatic validations the developer doesn't have to care of.

                          2) Because Carl wrote "What would you pie in the sky features be?" :-)
                          So let's talk about the definition of additional properties for the custom widget. In my initial posting I have written that this feature could be optional. But if I'm thinking about it, it would be very helpful to be able to define all setting for the customer widget. So that the "end user" can set all setting the declarative way as he is used too and doesn't have to use some tags in a long string field to parameterize the widget.

                          If it's not possible to show it immediatly on the page (because of the dynamic nature), I'm sure a button "Additional Settings..." which opens a popup with this settings is also fine.

                          My APEX Blog: http://inside-apex.blogspot.com
                          The ApexLib Framework: http://apexlib.sourceforge.net
                          The APEX Builder Plugin: http://sourceforge.net/projects/apexplugin/
                          • 10. Re: Custom Item Types in future APEX version.
                            Dimitri Gielis
                            Ok, here are my first thought...

                            First thing to say: I like the others comments and I agree to a lot of them. It's not my goal to say "my way is best way", just to provide my ideas and discuss with others...

                            How would you like it to work?
                            I want something that goes further then "Custom Item Types", I'm calling it "Custom Components"

                            I'm thinking about something at Workspace Level (if you wish an app called "Custom Components"), where you've all widgets in. In that app all widgets (google suggest, slider, ...) are specified. We get some widgets out of the box, but it's open so we can import others or create new ones ourselves. This part is mainly to manage all the custom widgets.

                            The implementation: In my applications, I can now choose these components, preferable subscribe to them.
                            That would be easier than what Patrick is suggesting or telling why not to put the Custom Item Type at workspace level. If you could subscribe to your "custom component", you would have a copy of it in your app, but it's linked with the workspace Custom Type, so you could easily upgrade to new versions (refresh).

                            I think a Custom Item Type is still limiting you, I believe in the "Custom Components" section of APEX also other "AJAX reports" could be included or "AJAX tabular form regions". Another reason why I'm calling it "Custom Components" is because for some widgets you need to change some things on different places, so "just" an item wouldn't be sufficient.

                            What would your minimum requirements be?
                            I think like Patrick describes it, it's the first step... so that would be minimal ;-)

                            What would you pie in the sky features be?

                            What I described above.
                            For ex.: If Patrick's ApexLib framework would be in the "Custom Components" section (imported from Source Forge!) and I can just go inside my app and select to use the ApexLib custom component, that would be awesome ;-)

                            Another example would be a livechat component. With one click I would get a mic/video conf. possibility in my app! Am I'm dreaming?!? ;-)

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

                              I've always wanted to do that :)

                              • 12. Re: Custom Item Types in future APEX version.
                                Hint: to bump a thread all you have to do is edit one of your posts in that thread. So just add a space some where and it bumps the thread to the top of forum without having to create a new post. Of course creating a new posting on a thread does inflate your post count;)

                                • 13. Re: Custom Item Types in future APEX version.
                                  Arie Geller

                                  I agree that custom item is a good idea, although I’m pretty sure Patrick is a bit optimistic about its target audience (“junior developer/power user”). I don’t considered myself an expert, but I gained some experience in the APEX environment, and I’m not sure I understand what we’ll need to do, according to Patrick model, in order to create this new custom item. Maybe Patrick can take one example – like Google suggest, which involved both rendering issues and on-demand processes (client side and server side) – and populate some of the definitions he proposed. At least for me, it will be much easier to assess what we are facing.

                                  Vikas is also correct to some degree. Almost everything can be done using JavaScript, but it’s not the same. The shuttle item is good example. Vikas is right; you can take two area text items, some graphics in between, and Carl’s JavaScript code and you have self made shuttle item. However, in order to do that you need to think like a programmer, and the vast majority of the target audience is lacking this kind of thinking. Another point is that every page code generated on the server side is much more efficient. The APEX translating mechanism is good example. Prior to version 3.x I spent a lot of time and energy using JS code, to translate various internal engine strings. It worked OK, but when you are working over the internet, often enough there is this flicker effect (the original string is displayed before the onload JS code had a chance to replace it). With the APEX translating mechanism most of it is in the past. Having said that, I absolutely agree with Vikas request to ‘provide us as many hooks as possible into the DOM, make it as "open" as possible’. This is a very important request (and need) regardless of the custom item issue. It’s particularly important in all the popup windows that are being rendered using an internally generated JS code.

                                  As I see it, this custom item should ultimately create something similar to the packaged application market. Experience programmers will be able to create this widgets, and the target audience will be able to easily import them into their application/workspace.

                                  I’m allowing myself few more words in general, as I understand from Carl that these days the APEX team is finalizing the features list to the next version. As Always in these cases, the list is very long and the resources are very limited. It’s all about priorities. Vikas voiced his opinion about that, regarding the custom item, and I tend to agree with him. The UI portion of APEX has evolved considerably over the last few versions. The number of built-in items has increased (and I believe they are covering the majority of the user’s needs) and the ease of use also improved (e.g. drag&drop etc.). There are other areas that IMHO needs the attention of the team, much much more then the UI. First and foremost, the report engine. Everyone following this forums knows that printing issues are the least to be answered and solved. Printing PDF is great, but the content of the reports are much more important. Report break issues, master details report, and many others are very important issues that need to be address. The BI publisher is a great tool, but it’s a very expensive one (corporate level). More simple, built in solutions for hard copy reports (not PDF but simple hard copy printing) is much more important, IMHO, then almost anything else on the enhancement request list.

                                  Just my (long) 2c,
                                  • 14. Re: Custom Item Types in future APEX version.
                                    Hi Arie,

                                    the target audience for writing the customer widget code are experienced pl/sql and javascript developers, the target audience to use them are junior developer/power user.

                                    But your posting made me thinking and you are right I missed another piece in my original proposal. An interface on the server which is called with AJAX when the widget needs additional data. Normally you would write an on-demand process, but we want to avoid that because the goal is to be done with all the coding when the custom widget is installed.

                                    So what do we need?

                                    Another entry point which APEX can call when it is called with AJAX. Currently APEX has already some predefined request types, like FLOW_EXCEL_OUTPUT... , FLOW_XMLP_OUTPUT... or APPLICATION_PROCESS=...

                                    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).
                                    With that information APEX can lookup the PL/SQL entry point which is configured for AJAX calls for that widget. This code would behave like a normal on-demand process and has to generate all the HTML/XML/JSON output.

                                    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. We can do that here too, but some of the values like page-item-id/column-id or the current value can not be passed that way. Maybe there could be some predefined internal application items like (WIDGET_PAGE_ID, WIDGET_ID, WIDGET_VALUE1, WIDGET_VALUE2, ...) for that purpose. Just a thought.

                                    About your question Arie, based on Google Suggest:

                                    A experienced developer would write a pl/sql package (eg my_cool_google_suggest) with 3 entry points:
                                    a) renderer: generates the necessary html code and the javascript calls/code.
                                    b) AJAX-callback: gets the ID of the widget so that it can read the widget definition like the lov query and execute it with dynamic sql (EXECUTE IMMEDIATE) to get a new result set based on the value the user has entered. The result is returned as XML or JSON stream.
                                    c) validation: could check the value against the defined lov query and raise an error if there is no matching value.

                                    If a developer/power user wants to use it he first has to
                                    a) install the package into his application schema
                                    b) register the custom widget in shared components\custom widget by entering a internal name: GOOGLE_SUGGEST, display name: Google Suggest, Renderer: my_cool_google_suggest.render, Ajax-callback: my_cool_google_suggest.callback, Validation: my_cool_google_suggest.validation
                                    or do the above step with some kind of installation script (would be more convenient).

                                    And afterwards he just uses it as a regular APEX widget by selecting it in the Display As select list of page items/report columns.

                                    So as you can see the hard work is done by the customer widget creator, but it doesn't differ much from what you have to do now if you want to use a widget which isn't supported by APEX. Maybe you have to think a little bit more generic (like with the dynamic SQL), but in the end it's pretty much the same.

                                    Hope that makes it more clear
                                    My APEX Blog: http://inside-apex.blogspot.com
                                    The ApexLib Framework: http://apexlib.sourceforge.net
                                    The APEX Builder Plugin: http://sourceforge.net/projects/apexplugin/
                                    1 2 Previous Next