This discussion is archived
1 9 10 11 12 13 14 Previous Next 201 Replies Latest reply: Oct 30, 2007 4:38 AM by 478676 Go to original post RSS
  • 150. Re: APEX 3.1 Enhancements
    135285 Oracle ACE
    Currently Being Moderated
    Hi Mike,

    about the HTML Editor which should support images, have a look at Carsten Czarski solution for that. See http://inside-apex.blogspot.com/2007/07/enable-add-picture-for-html-editor.html

    Patrick
  • 151. Re: APEX 3.1 Enhancements
    Learco Brizzi Oracle ACE
    Currently Being Moderated
    Better and easier error handling for Database errors.

    Learco Brizzi
  • 152. Re: APEX 3.1 Enhancements
    DietmarAust Oracle ACE
    Currently Being Moderated
    Better and easier error handling for Database errors.
    I think this is really important. Some kind of exception handler for the onSubmit processes processes would be nice. Where we could set an error message ourselves programmatically.

    Also, a better support for real Oracle transactions in the submit processing is absolutely needed. Right now an implicit commit occurs, when a session variable is assigned a value. From my testing apex_util.set_session_state doesn't cause an implicit commit, but many will fall into the "trap" and have unexpected results and inconsistencies using the :P1_x := 'xx' syntax.

    Regards,
    ~Dietmar.
  • 153. Re: APEX 3.1 Enhancements
    135285 Oracle ACE
    Currently Being Moderated
    What a coincident Dietmar, I was thinking to write a more detail description of the error handling for the hole week. :-)

    So here we go. Comments are welcome!

    Summary of the current problems and business need for error handling enhancements:
    <ol><li>Errors raised<ul>
    <li>By different APEX DML processes which raise error messages (eg. lost update detection)
    ORA-20001: Error in DML: p_rowid=1, p_alt_rowid=PRODUCT_ID, p_rowid2=, p_alt_rowid2=. ORA-20001: Current version of data in database has changed since user initiated update process. current checksum = "82D6868C0A20A626BB5B7F3A690E9061" application checksum = "EE2D6F7E7F16060FA5186B580A8472AC"
    Error      Unable to process row of table DEMO_PRODUCT_INFO.
    </li>
    <li>By constraint violations
    ORA-20001: Error in DML: p_rowid=21, p_alt_rowid=PRODUCT_ID, p_rowid2=, p_alt_rowid2=. ORA-00001: unique constraint (DEMO_PATRICK.DEMO_PRODUCT_INFO_IDX1) violated
    Error      Unable to process row of table DEMO_PRODUCT_INFO.
    </li>
    <li>Or business exceptions in triggers
    ORA-20001: Error in DML: p_rowid=21, p_alt_rowid=PRODUCT_ID, p_rowid2=, p_alt_rowid2=. ORA-20999: A business exception. ORA-06512: at "DEMO_PATRICK.DEMO_PRODUCT_INFO_T1X", line 3 ORA-04088: error during execution of trigger 'DEMO_PATRICK.DEMO_PRODUCT_INFO_T1X'
    Error      Unable to process row of table DEMO_PRODUCT_INFO.

    => can you actually spot the business error message here?</li></ul>
    The error message text is to "technical" which is ok for developers, but not for end users.</li>
    <li>No hook to transform the error message in a more user friendly version.</li><li>No hook to log errors.</li><li>No possibility to translate APEX error messages into a language which isn't one of the 12 supported languages.</li><li>No placeholder for the error message in the "Error page template"</li><li>No translation possibility for the "1 error has occurred" message</li></ol>
    A proposal for a possible solution.
    <ul><li>For 1-4:
    <ul><li>There should be a new process type "On error" which is available on page and application level.</li> <li>This process(es) should fire each time when in a process/computation/validation or some other area an error is raised/returned.</li><li>As context for this process the following information should be accessible:
    <ul> <li>Type/ID of the object (process/computation/...) which raised the error => for enhanced logging to help the developers</li> <li>APEX-error-code => to check for errors raised by APEX (eg. current version of data, not authorized, page not found, ...), so that we don't have to parse the error message. NULL in case of "normal" errors</li><li>SQLCODE => in case of an ORA error. NULL in case of an APEX error.</li> <li>Error message => SQLERRM or the APEX error message (without the "ORA-20001: Error in DML: ..."</li> <li>Process/Validation/... error message</li><li>Row number => in case of a tabular form error</li> <li>Additional info => like the SQL statement which caused the error -> again for logging</li> </ul></li>
    <li>The process should have the possibility to set the following values (for example with a procedure call) which are then used by APEX when the error is displayed.
    <ul> <li>Error message</li> <li>Process/Validation/... error message</li><li>Additional info</li> </ul></li> <li>If no error process exists, APEX should behave as it currently does and add the
    ORA-20001: Error in DML: p_rowid=21, p_alt_rowid=PRODUCT_ID, p_rowid2=, p_alt_rowid2=.
    in front of the error message.</li> </ul> </li><li>For 5:
    In the error page template, there is currently no substitution string for the actual error, only the process/validation/... error message
    can be controlled with the #MESSAGE# placeholder. The error message is currently always added automatically at the beginning of the template.
    There should be two new placeholders:
    <ul> <li>#ERROR_MESSAGE# and</li> <li>#ADDITIONAL_INFO#</li>
    </ul></li><li>For 6:
    There should be the possibility to translate the "1 error has occurred" and "x errors have occurred" messages as it
    is available for report placeholders. Business need: For languages which are not one of the 12 supported languages.</li>
    </ul>Business need:

    The above enhancements should give us more flexibility how errors are handled in APEX and still use the existing and helpful processes of APEX (eg for DML). Currently we have to write our own DML processes if we want wo enhance the error handling, but that requires a re-development of the "change update detection", ... functionality of APEX which is a lot of work. But users request more "non technical" error messages". For administration purpose it's also sometimes necessary to log error messages, not only the unexpected technical ones, also business errors from validations. Furthermore it also helps APEX developers which develop applications for languages which are not one of the supported languages.

    That would be a huge enhancement for our development productivity and end user friendliness of APEX applications.

    Thanks
    Patrick
    ----------------------------------------------------------------------------------------------------
    My APEX Blog: http://inside-apex.blogspot.com
    The ApexLib Framework: http://apexlib.sourceforge.net
    The APEX Builder Plugin: http://sourceforge.net/projects/apexplugin/
  • 154. Re: APEX 3.1 Enhancements
    60437 Employee ACE
    Currently Being Moderated
    Very well specified. Thank you, Patrick.

    Scott
  • 155. Re: APEX 3.1 Enhancements
    DietmarAust Oracle ACE
    Currently Being Moderated
    Two more request ;) (sorry if they are duplicates)

    1) Ability to pass parameters (with default values when no value is passed) to any template. I often struggle with setting a specific width on a region or report. I do not want to create different versions of the template with different widths. And the CSS solutions are a bit tricky and not well maintainable.

    2) Pre-text on a region or item. This way we can more easily wrap tags around a region or item. Currently we have to create a dummy region for this.

    Thanks,
    ~Dietmar.
  • 156. Re: APEX 3.1 Enhancements
    VANJ Journeyer
    Currently Being Moderated
    Dietmar:

    1. You can use &FOO. substitutions in your template and set with onload computations to effectively pass in parameters to templates

    2. v3.0 added a PreLabel text attribute to items for this purpose. For regions, you can just modify the region template to add your wrapper tags (again using the &FOO. substitutions to get some more dynamic behaviour). Using the new REGION_STATIC_ID feature would also be beneficial here.
  • 157. Re: APEX 3.1 Enhancements
    Arie Geller Guru
    Currently Being Moderated
    Hi Vikas,

    >> v3.0 added a PreLabel text attribute to items for this purpose

    I was looking just for that the other day and couldn’t find it. Following your post, I re-checked it today, but I still don’t see any pre-label text attribute. Could you, please, be more specific on what you meant?

    Thanks,
    Arie.
  • 158. Re: APEX 3.1 Enhancements
    Justin Patterson Explorer
    Currently Being Moderated
    Arie,

    Here is where it is located.

    http://i12.tinypic.com/68a6e89.jpg

    Justin
  • 159. Re: APEX 3.1 Enhancements
    Arie Geller Guru
    Currently Being Moderated
    Hello Justin,

    Thanks for your reply; however this is a pre element attribute, and not a pre label attribute. In addition, this pre element attributes are only referring to radio group and checkbox options. As I understand it, it’s not meet Dietmar request (and my needs).

    Regards,
    Arie.
  • 160. Re: APEX 3.1 Enhancements
    VANJ Journeyer
    Currently Being Moderated
    <p>
    <i>however this is a pre element attribute, and not a pre label attribute</i>

    <p>Well, you could insert "pre-label" text just by creating your own custom label template. A pre-element attribute was what was Why not Pre-Element feature? and 3.0 added that.

    <p><i>this pre element attributes are only referring to radio group and checkbox options</i>

    <p>That's not true. The text you specify there is inserted before rendering the item, regardless of its display-as type.
  • 161. Re: APEX 3.1 Enhancements
    Arie Geller Guru
    Currently Being Moderated
    Hi Vikas,

    Thanks on your reply.

    >> A pre-element attribute was what was missing and 3.0 added that.

    Yes. The pre-element field can indeed solve some of the issues you raised in that post. Still, I believe that a pre-label field is also needed, if you want to easily manipulate the page item as one unit, and not as a label and element (like in the case where you want to hide the item).

    >> That's not true. The text you specify there is inserted before rendering the item, regardless of its display-as type.

    Yes, you are correct. I was misled by the help text of this item, which was probably copied from someplace else, and need to be changed.

    Regards,
    Arie.
  • 162. Re: APEX 3.1 Enhancements
    VANJ Journeyer
    Currently Being Moderated
    if you want to easily manipulate the page item as one unit

    What I was trying to highlight is that this can already be done without a product enhancement.

    See threads like

    Re: Give textfield label an id
    Re: Label still displayed when using html_HideElement How do I get rid of t
  • 163. Re: APEX 3.1 Enhancements
    135285 Oracle ACE
    Currently Being Moderated
    <h2>Custom Item Types</h2>
    I think Dietmar has already requested a similar feature and I had a brief discussion about that with Joel during the ODTUG conference. I put some more thoughts into that and have written together what I would expect and how the feature should/could be used. I thought it's a good idea to summarize the idea in more detail than just say "Hey Oracle, invent something nice!" and then complain if it's not that way as I wanted to have it.

    As always, comments are welcome! Ok, let's start.

    <h3>Business need</h3>
    Oracle APEX has a standard widget set which is growing with each release, but it will never be able to have all of them which are requested by developers. Currently it's quite hard and not straitforward if a developer wants do add his own widget, like a slider, Google suggest, ... He has to do a lot of manual coding each time (on the server and probably on the client with Javascript) when he wants to use the widget on a page and it's probably not something a junior developer/power user can do.

    It also makes the application much more complicated and unmaintainable. If a bug is discovered in the late development process, probably in a lot of places the code has to be corrected. There is also no easy possibility to exchange that widget code with other developers and immediatly use it in another application.

    So the idea is to open-up the fixed widget set of Oracle APEX with plugable item types which fit seamless into the existing widget set.

    <h3>Proposal for a possible solution</h3>
    <ol><li>Configuration

    There should be a Shared Component "Custom Item Type" on application level which allows to store some general meta data about the new widget. For example:<ul>
    <li>Internal Name: which is stored in the display as column</li><li>Display Name: for the select list</li><li>Name of the PL/SQL render function: name of the stored function/... which has to match to a defined interface</li><li>List of userdefined properties which are displayed for that item type (optional, would be a goody) :-)</li></ul>
    Why not store this information on workspace level? The reason is a much more complicated export, which currently doesn't export workspace related stuff. Also the version problem (different applications could use different versions of the widget) would have to be considered. By having the meta data configuration on application level all that is avoided.
    </li>
    <li>Usage

    The developer can select this new custom item types as he does with the standard widgets in the "Display As" lov of the page items and report columns. Optional: The configurable properties are displayed and the developer can enter data to adjust the behavior of the widget.
    </li>
    <li>Rendering workflow

    The PL/SQL rendering function has to comply to a defined interface. The function itself is stored in the application schema. So it's not necessary to load the package into the FLOWS schema, it's just part of the application. That will also help that there are no security issues, because in the FLOWS schema the package would have too many privileges.

    How could the interface look like and for what should the render function be responsible?
    First of all, I think it would make sense to seperate between the rendering for page items and report columns. => They should have a different interface. I'm just describing the page item interface here.

    For what is APEX responsible and for what the render function?

    APEX:
    <ol>
    <li>Reads the item meta data</li>
    <li>Checks if the user authorized to see the page item => render function is not called if not</li>
    <li>Checks if the condition is true => render function is not called if not</li>
    <li>Evaluates the read-only condition but just stores the outcome</li>
    <li>Renders everything before the item (eg. table structure for the layout grid, the label itself)</li>
    <li>Calls the custom render function which renders the widget</li>
    <li>Renders everything after the item (eg. closing table structure, ...)</li>
    </ol>
    Custom render function:
    <ol>
    <li>Gets a record with the items meta data</li>
    <li>Gets TRUE/FALSE if it's a read-only item</li>
    <li>Current value of the item/column</li>
    <li>The report rendering interface would probably have the row number as an additional parameter (for the unique id generation)</li>
    <li>IN OUT parameters with the last index for the p_txx, p_vxx, ... arrays. The render function is responsible to increase the necessary index.</li>
    <li>Renders the necessary javascript library loading code, if it's the first item of that type on the page. The widget has to track that with a internal static variable.</li>
    <li>Render widget (including internal hidden html items like p_arg_names items) based on the read-only parameter.</li>
    </ol></li></ol>
    This kind of integration should help to make the custom code for the render function as slim as possible.

    Thanks for your attention :-)
    Patrick
    ----------------------------------------------------------------------------------------------------
    My APEX Blog: http://inside-apex.blogspot.com
    The ApexLib Framework: http://apexlib.sourceforge.net
    The APEX Builder Plugin: http://sourceforge.net/projects/apexplugin/
  • 164. Re: APEX 3.1 Enhancements
    DietmarAust Oracle ACE
    Currently Being Moderated
    Hi Vikas,
    1. You can use &FOO. substitutions in your template
    and set with onload computations to effectively pass
    in parameters to templates
    I tend to like more of a clear interface for passing parameters. Although this will work, it will have side-effects and is not easily maintainable. And this will effect all regions using this template.

    But your second point does solve it. Using the #REGION_STATIC_ID# instead of the #REGION_ID# will do the trick. This way I can use plain CSS to format each region individually. It doesn't work easily for PPR reports ( #REGION_STATIC_ID# does not work in report template for PPR ), perhaps I can use the REGION_STATIC_ID as an additional class attribute instead.

    Thanks, ~Dietmar.