Wednesday 29 March 2017

How to preview your local image in HTML?

Web design tip

Preview an image from your PC live in your app

Nifty way to hack this problem - non APEX related


It is totally APEX unrelated but still can be used by developers regardless of technology.

Ever wanted to preview how your newly designed image will look like once you upload it to an app. I know what you will say why would I even want/need to do this now when we have apex-frontend-boost or by doing it directly in your app.

What if you do not have access to DEV/PROD environment or application server and need to deliver newly designed image for your client application? Or maybe you do not want to bother setting these up. Or just wanna do one-off thing.

If you google this more than once probably means you need to write it down, doesn't it. So doing the same for my future reference.


Situation: Create a logo for client Facebook account. You spent time to design a new logo and now it is time to try it before it gets deployed by your client.

How do we go about to test this?

Again google is your friend, I found this solution there too and I am sure all of them work in a similar way.

If you inspect your FB page you are looking for section containing "_qa1" class this is where normally FB logo sits:
<div class="_qa1"><a aria-label="Profile picture" class="_2dgj" href="....." rel="theater"><img class="_4jhq img" src="..." alt="" width="170" height="170"></a><!-- react-empty: 8 --></div>
  1. Open browser inspector tool. Please remember not to refresh the page at any point as changes will be lost.
  2. Find an image you want to temporary replace. Check if it has ID assigned if not assign one to it by changing its DOM HTML with ID = "your_ID".
  3. After the image add this code into your HTML:
    <input onchange="document.getElementById('your_ID').src = window.URL.createObjectURL(this.files[0])" type="file" >

What this will do is let you upload the file from your local PC. Simple. 

Once you show it to your client and you all are happy, it is deployment time.

Thanks,
SLino

Tuesday 28 March 2017

APEX 5.1.1 patch release

APEX 5.1.1 patch released

Available on OTN for download

Time to upgrade again


New APEX patch 5.1.1 is available from OTN - download

List of patch set notes can be found here -> 5.1.1 Patch notes.

As you can see list is a really long one so we better start upgrading our 5.1 instances.
 
Cheers,
SLino

Wednesday 8 March 2017

APEX 5.1 Interactive grid - Making columns readonly

APEX 5.1 Interactive grid

Making columns readonly

My second APEX 5.1 post


This is just a simple post on how to make some of the columns read only.

If you want to know in details how IG is structured and all those nice hidden little features please visit John Snyder blog

Again John did amazing job giving us tips from behind the scene even before APEX 5.1 was publicly available. Thanks John.

Situation: we created Interactive Grid for users to view/edit some table data. Now we realized some columns (other than primary key column) content is better not to be updated by end user. Further we want to allow them to enter new rows but disable them from updating the existing ones. How do we do this?

Check out this example:
We have a standard looking IG in editable mode. There are multiple ways how we can sort this one out.

Notice how rows except the first one are highlighted in gray. Showing it as "read only" and not accessible by end users.

First we can use Allowed Row Operations Column setting in Attributes section of your report where we define a column in our query that will dictate which rows can be updated or deleted.

But again this is now row based control.

What if we only want a particular column to be controlled? Then there is setting siting under your column properties Query Only that can preserve the value and make it inaccessible for Insert or Update operation.

Using this setting you can make it read only but trouble is then it is read only in all modes. Even when users try to enter a new row which is not what we want.
To achieve read only per column needed I used these steps. Assign an class "is-readonly" to your desired column in my example this is Department name.



Then add Dynamic Action Event: Mouse enter with td.is-readonly as selector.
Executing Javascript code:
$( "td.is-readonly:empty" ).removeClass( 'is-readonly' );

Live demo


18/04/2017 Update 
Easiest  how to do this is by setting Column Properties as 


 
Thanks,
SLino

Thursday 2 March 2017

APEX 5.1 - Interactive grid limitation

APEX 5.1 IG limitation

Deleting long text columns producing an error

Error: Request Entity Too Large


This is a quick post on thing I noticed on APEX 5.1 IG last night that I wanted to share.

It is highly recommended to have a user friendly error message handler on your application so that users do not get a nasty ORA messages but also importantly that malicious code does not expose any details it does not need to see.

On top of this a good practice is to keep track of all error messages that arise in your app which I have done using submit_feedback procedure.


This is exactly where my problem showed up.

I detected an error on a page so I went in to see my feedback records using internal APEX feedback UI -> Team development -> Feedback link.

All feedback were listed here as expected. I immediately notices how interface for this site has changed comparing to 5.0 as this used to be interactive report. I said great perfect example where to use IG. After a while I got more and more records in and after all issues were cleanup I decided why don't I delete some rows from my feedback list.

This is where this error showed up:

To expose all components of my error handling function that was posting feedback, all I was using was a proven method of:

apex_util.submit_feedback (
p_comment => '[message]= ' || l_reference_id|| ' - ' || p_error.message||chr(10)||'[additional_info]=' || p_error.additional_info||chr(10)||'[display_location]=' || p_error.display_location||chr(10)||'[association_type]=' || p_error.association_type||chr(10)||'[page_item_name]=' || p_error.page_item_name||chr(10)|| '[region_id]=' || p_error.region_id||chr(10)||'[column_alias]=' || p_error.column_alias||chr(10)||'[row_num]=' || p_error.row_num||chr(10)||'[error_backtrace]=' || p_error.error_backtrace||chr(10)||'[component_type]=' || p_error.component.type||chr(10)||'[component_id]=' || p_error.component.id||chr(10)||'[component_name]=' || p_error.component.name, p_type => 3, p_application_id => v('APP_ID'), p_page_id => v('APP_PAGE_ID'), p_email => null);
Seems like APEX is comfortable with saving this value but when it comes to deleting IG is hitting some sort of character limitation.

Please let me know if this sounds like something you encountered before. If really there is a limit in the buffer somewhere what does it mean and where does that sit currently. Last thing we want is for users to pick on this once application goes live, right?

I know there is a million other ways how I can store error log and review it. Simply I used this method before and it always worked so wanted to share my thoughts. I still find IG to be one of the best features of APEX 5.1.

Appreciate your feedback on this. Also to note that I am perfectly fine deleting 1 or 5 rows but all(19) seems to hit the limit.

 
Thanks,
SLino