[Discussion] Browser Unresponsive when Loading Entity with Large Results

[Devanshu Vyas-2]

Hello Guys,

Recently, I came across a situation where an entity was taking too much of
a time(browser asked me to either wait or kill) while loading/searching
results in the Webtools application. The entity had close to 5M records,
and I checked the server responded timely but the rendering of the screen
was taking time.
When I explored the issue I came across a macro which renders the
pagination on the screen, and it had a code block which was causing the
screen rendering delay.
{code}

<#assign x=(listSize/viewSize)?ceiling>
  <#list 1..x as i>
    <#if i == (viewIndex+1)><option selected="selected"
value="<#else><option value="</#if>${i-1}">${i}</option>
  </#list>

{code}
This code seems logical enough to me, and what I gather from this is that
the list will render a select box with 250,000 options.

I would like to propose a change in this UI/UX from select box to an input
text box so a user can navigate to any page, similar to a navigation input
box in a PDF document reader application.

Please let me know your thoughts on this and share some more ideas to how
we can improve/resolve this issue. Looking forward to your replies!



Thanks & Regards,
Devanshu Vyas.

[taher]

before proposing the solution we need a diagnosis. What is the strain
happening on the browser?
On Fri, Dec 14, 2018 at 9:11 AM Devanshu Vyas <[hidden email]> wrote:

>
> Hello Guys,
>
> Recently, I came across a situation where an entity was taking too much of
> a time(browser asked me to either wait or kill) while loading/searching
> results in the Webtools application. The entity had close to 5M records,
> and I checked the server responded timely but the rendering of the screen
> was taking time.
> When I explored the issue I came across a macro which renders the
> pagination on the screen, and it had a code block which was causing the
> screen rendering delay.
> {code}
>
> <#assign x=(listSize/viewSize)?ceiling>
>   <#list 1..x as i>
>     <#if i == (viewIndex+1)><option selected="selected"
> value="<#else><option value="</#if>${i-1}">${i}</option>
>   </#list>
>
> {code}
> This code seems logical enough to me, and what I gather from this is that
> the list will render a select box with 250,000 options.
>
> I would like to propose a change in this UI/UX from select box to an input
> text box so a user can navigate to any page, similar to a navigation input
> box in a PDF document reader application.
>
> Please let me know your thoughts on this and share some more ideas to how
> we can improve/resolve this issue. Looking forward to your replies!
>
>
>
> Thanks & Regards,
> Devanshu Vyas.

[Devanshu Vyas-2]

Hello Taher,

The FTL is trying to render a list(select box) with a large number of
options(around 250,000 in my case) which takes a lot of time and the
browser usually asks to either kill the page or wait for it to load
completely.

Thanks & Regards,
Devanshu Vyas.


On Fri, Dec 14, 2018 at 2:18 PM Taher Alkhateeb <[hidden email]>
wrote:

> before proposing the solution we need a diagnosis. What is the strain
> happening on the browser?
> On Fri, Dec 14, 2018 at 9:11 AM Devanshu Vyas <[hidden email]>
> wrote:
> >
> > Hello Guys,
> >
> > Recently, I came across a situation where an entity was taking too much
> of
> > a time(browser asked me to either wait or kill) while loading/searching
> > results in the Webtools application. The entity had close to 5M records,
> > and I checked the server responded timely but the rendering of the screen
> > was taking time.
> > When I explored the issue I came across a macro which renders the
> > pagination on the screen, and it had a code block which was causing the
> > screen rendering delay.
> > {code}
> >
> > <#assign x=(listSize/viewSize)?ceiling>
> >   <#list 1..x as i>
> >     <#if i == (viewIndex+1)><option selected="selected"
> > value="<#else><option value="</#if>${i-1}">${i}</option>
> >   </#list>
> >
> > {code}
> > This code seems logical enough to me, and what I gather from this is that
> > the list will render a select box with 250,000 options.
> >
> > I would like to propose a change in this UI/UX from select box to an
> input
> > text box so a user can navigate to any page, similar to a navigation
> input
> > box in a PDF document reader application.
> >
> > Please let me know your thoughts on this and share some more ideas to how
> > we can improve/resolve this issue. Looking forward to your replies!
> >
> >
> >
> > Thanks & Regards,
> > Devanshu Vyas.
>

[Devanshu Vyas-2]

Hello Taher,

The browser becomes unresponsive to a user in this case, as the browser is
busy in preparing the large '*select*' DOM element(a drop-down with around
250,000 options).
I found some points related to our discussion here
<https://developers.google.com/web/tools/lighthouse/audits/dom-size>.


Thanks & Regards,
Devanshu Vyas.


On Fri, Dec 14, 2018 at 3:56 PM Devanshu Vyas <[hidden email]>
wrote:

> Hello Taher,
>
> The FTL is trying to render a list(select box) with a large number of
> options(around 250,000 in my case) which takes a lot of time and the
> browser usually asks to either kill the page or wait for it to load
> completely.
>
> Thanks & Regards,
> Devanshu Vyas.
>
>
> On Fri, Dec 14, 2018 at 2:18 PM Taher Alkhateeb <
> [hidden email]> wrote:
>
>> before proposing the solution we need a diagnosis. What is the strain
>> happening on the browser?
>> On Fri, Dec 14, 2018 at 9:11 AM Devanshu Vyas <[hidden email]>
>> wrote:
>> >
>> > Hello Guys,
>> >
>> > Recently, I came across a situation where an entity was taking too much
>> of
>> > a time(browser asked me to either wait or kill) while loading/searching
>> > results in the Webtools application. The entity had close to 5M records,
>> > and I checked the server responded timely but the rendering of the
>> screen
>> > was taking time.
>> > When I explored the issue I came across a macro which renders the
>> > pagination on the screen, and it had a code block which was causing the
>> > screen rendering delay.
>> > {code}
>> >
>> > <#assign x=(listSize/viewSize)?ceiling>
>> >   <#list 1..x as i>
>> >     <#if i == (viewIndex+1)><option selected="selected"
>> > value="<#else><option value="</#if>${i-1}">${i}</option>
>> >   </#list>
>> >
>> > {code}
>> > This code seems logical enough to me, and what I gather from this is
>> that
>> > the list will render a select box with 250,000 options.
>> >
>> > I would like to propose a change in this UI/UX from select box to an
>> input
>> > text box so a user can navigate to any page, similar to a navigation
>> input
>> > box in a PDF document reader application.
>> >
>> > Please let me know your thoughts on this and share some more ideas to
>> how
>> > we can improve/resolve this issue. Looking forward to your replies!
>> >
>> >
>> >
>> > Thanks & Regards,
>> > Devanshu Vyas.
>>
>

[taher]

Yeah so what you are describing is a pagination issue right? The root
cause is pagination, not type of widget being used? I'm a little
confused by the proposal?

On Fri, Dec 14, 2018 at 4:08 PM Devanshu Vyas <[hidden email]> wrote:

>
> Hello Taher,
>
> The browser becomes unresponsive to a user in this case, as the browser is
> busy in preparing the large '*select*' DOM element(a drop-down with around
> 250,000 options).
> I found some points related to our discussion here
> <https://developers.google.com/web/tools/lighthouse/audits/dom-size>.
>
>
> Thanks & Regards,
> Devanshu Vyas.
>
>
> On Fri, Dec 14, 2018 at 3:56 PM Devanshu Vyas <[hidden email]>
> wrote:
>
> > Hello Taher,
> >
> > The FTL is trying to render a list(select box) with a large number of
> > options(around 250,000 in my case) which takes a lot of time and the
> > browser usually asks to either kill the page or wait for it to load
> > completely.
> >
> > Thanks & Regards,
> > Devanshu Vyas.
> >
> >
> > On Fri, Dec 14, 2018 at 2:18 PM Taher Alkhateeb <
> > [hidden email]> wrote:
> >
> >> before proposing the solution we need a diagnosis. What is the strain
> >> happening on the browser?
> >> On Fri, Dec 14, 2018 at 9:11 AM Devanshu Vyas <[hidden email]>
> >> wrote:
> >> >
> >> > Hello Guys,
> >> >
> >> > Recently, I came across a situation where an entity was taking too much
> >> of
> >> > a time(browser asked me to either wait or kill) while loading/searching
> >> > results in the Webtools application. The entity had close to 5M records,
> >> > and I checked the server responded timely but the rendering of the
> >> screen
> >> > was taking time.
> >> > When I explored the issue I came across a macro which renders the
> >> > pagination on the screen, and it had a code block which was causing the
> >> > screen rendering delay.
> >> > {code}
> >> >
> >> > <#assign x=(listSize/viewSize)?ceiling>
> >> >   <#list 1..x as i>
> >> >     <#if i == (viewIndex+1)><option selected="selected"
> >> > value="<#else><option value="</#if>${i-1}">${i}</option>
> >> >   </#list>
> >> >
> >> > {code}
> >> > This code seems logical enough to me, and what I gather from this is
> >> that
> >> > the list will render a select box with 250,000 options.
> >> >
> >> > I would like to propose a change in this UI/UX from select box to an
> >> input
> >> > text box so a user can navigate to any page, similar to a navigation
> >> input
> >> > box in a PDF document reader application.
> >> >
> >> > Please let me know your thoughts on this and share some more ideas to
> >> how
> >> > we can improve/resolve this issue. Looking forward to your replies!
> >> >
> >> >
> >> >
> >> > Thanks & Regards,
> >> > Devanshu Vyas.
> >>
> >

[Deepak Dixit-4]

Pagination widget tries to generate select with a huge number of options so
browser takes too much time to prepare dom and causing unresponsiveness.

So we can say that the root cause is in the pagination widget that
prepares select option. We need a different pattern rather than select
element for rendering the page (VIEW_INDEX)

Thanks & Regards
--
Deepak Dixit



On Sat, Dec 15, 2018 at 7:14 PM Taher Alkhateeb <[hidden email]>
wrote:

> Yeah so what you are describing is a pagination issue right? The root
> cause is pagination, not type of widget being used? I'm a little
> confused by the proposal?
>
> On Fri, Dec 14, 2018 at 4:08 PM Devanshu Vyas <[hidden email]>
> wrote:
> >
> > Hello Taher,
> >
> > The browser becomes unresponsive to a user in this case, as the browser
> is
> > busy in preparing the large '*select*' DOM element(a drop-down with
> around
> > 250,000 options).
> > I found some points related to our discussion here
> > <https://developers.google.com/web/tools/lighthouse/audits/dom-size>.
> >
> >
> > Thanks & Regards,
> > Devanshu Vyas.
> >
> >
> > On Fri, Dec 14, 2018 at 3:56 PM Devanshu Vyas <[hidden email]
> >
> > wrote:
> >
> > > Hello Taher,
> > >
> > > The FTL is trying to render a list(select box) with a large number of
> > > options(around 250,000 in my case) which takes a lot of time and the
> > > browser usually asks to either kill the page or wait for it to load
> > > completely.
> > >
> > > Thanks & Regards,
> > > Devanshu Vyas.
> > >
> > >
> > > On Fri, Dec 14, 2018 at 2:18 PM Taher Alkhateeb <
> > > [hidden email]> wrote:
> > >
> > >> before proposing the solution we need a diagnosis. What is the strain
> > >> happening on the browser?
> > >> On Fri, Dec 14, 2018 at 9:11 AM Devanshu Vyas <
> [hidden email]>
> > >> wrote:
> > >> >
> > >> > Hello Guys,
> > >> >
> > >> > Recently, I came across a situation where an entity was taking too
> much
> > >> of
> > >> > a time(browser asked me to either wait or kill) while
> loading/searching
> > >> > results in the Webtools application. The entity had close to 5M
> records,
> > >> > and I checked the server responded timely but the rendering of the
> > >> screen
> > >> > was taking time.
> > >> > When I explored the issue I came across a macro which renders the
> > >> > pagination on the screen, and it had a code block which was causing
> the
> > >> > screen rendering delay.
> > >> > {code}
> > >> >
> > >> > <#assign x=(listSize/viewSize)?ceiling>
> > >> >   <#list 1..x as i>
> > >> >     <#if i == (viewIndex+1)><option selected="selected"
> > >> > value="<#else><option value="</#if>${i-1}">${i}</option>
> > >> >   </#list>
> > >> >
> > >> > {code}
> > >> > This code seems logical enough to me, and what I gather from this is
> > >> that
> > >> > the list will render a select box with 250,000 options.
> > >> >
> > >> > I would like to propose a change in this UI/UX from select box to an
> > >> input
> > >> > text box so a user can navigate to any page, similar to a navigation
> > >> input
> > >> > box in a PDF document reader application.
> > >> >
> > >> > Please let me know your thoughts on this and share some more ideas
> to
> > >> how
> > >> > we can improve/resolve this issue. Looking forward to your replies!
> > >> >
> > >> >
> > >> >
> > >> > Thanks & Regards,
> > >> > Devanshu Vyas.
> > >>
> > >
>

[taher]

Ahh, so you want an auto complete text box that fetches from server on
the fly using jQuery right? If so, sure +1

On Sun, Dec 16, 2018 at 11:41 AM Deepak Dixit <[hidden email]> wrote:

>
> Pagination widget tries to generate select with a huge number of options so
> browser takes too much time to prepare dom and causing unresponsiveness.
>
> So we can say that the root cause is in the pagination widget that
> prepares select option. We need a different pattern rather than select
> element for rendering the page (VIEW_INDEX)
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
>
> On Sat, Dec 15, 2018 at 7:14 PM Taher Alkhateeb <[hidden email]>
> wrote:
>
> > Yeah so what you are describing is a pagination issue right? The root
> > cause is pagination, not type of widget being used? I'm a little
> > confused by the proposal?
> >
> > On Fri, Dec 14, 2018 at 4:08 PM Devanshu Vyas <[hidden email]>
> > wrote:
> > >
> > > Hello Taher,
> > >
> > > The browser becomes unresponsive to a user in this case, as the browser
> > is
> > > busy in preparing the large '*select*' DOM element(a drop-down with
> > around
> > > 250,000 options).
> > > I found some points related to our discussion here
> > > <https://developers.google.com/web/tools/lighthouse/audits/dom-size>.
> > >
> > >
> > > Thanks & Regards,
> > > Devanshu Vyas.
> > >
> > >
> > > On Fri, Dec 14, 2018 at 3:56 PM Devanshu Vyas <[hidden email]
> > >
> > > wrote:
> > >
> > > > Hello Taher,
> > > >
> > > > The FTL is trying to render a list(select box) with a large number of
> > > > options(around 250,000 in my case) which takes a lot of time and the
> > > > browser usually asks to either kill the page or wait for it to load
> > > > completely.
> > > >
> > > > Thanks & Regards,
> > > > Devanshu Vyas.
> > > >
> > > >
> > > > On Fri, Dec 14, 2018 at 2:18 PM Taher Alkhateeb <
> > > > [hidden email]> wrote:
> > > >
> > > >> before proposing the solution we need a diagnosis. What is the strain
> > > >> happening on the browser?
> > > >> On Fri, Dec 14, 2018 at 9:11 AM Devanshu Vyas <
> > [hidden email]>
> > > >> wrote:
> > > >> >
> > > >> > Hello Guys,
> > > >> >
> > > >> > Recently, I came across a situation where an entity was taking too
> > much
> > > >> of
> > > >> > a time(browser asked me to either wait or kill) while
> > loading/searching
> > > >> > results in the Webtools application. The entity had close to 5M
> > records,
> > > >> > and I checked the server responded timely but the rendering of the
> > > >> screen
> > > >> > was taking time.
> > > >> > When I explored the issue I came across a macro which renders the
> > > >> > pagination on the screen, and it had a code block which was causing
> > the
> > > >> > screen rendering delay.
> > > >> > {code}
> > > >> >
> > > >> > <#assign x=(listSize/viewSize)?ceiling>
> > > >> >   <#list 1..x as i>
> > > >> >     <#if i == (viewIndex+1)><option selected="selected"
> > > >> > value="<#else><option value="</#if>${i-1}">${i}</option>
> > > >> >   </#list>
> > > >> >
> > > >> > {code}
> > > >> > This code seems logical enough to me, and what I gather from this is
> > > >> that
> > > >> > the list will render a select box with 250,000 options.
> > > >> >
> > > >> > I would like to propose a change in this UI/UX from select box to an
> > > >> input
> > > >> > text box so a user can navigate to any page, similar to a navigation
> > > >> input
> > > >> > box in a PDF document reader application.
> > > >> >
> > > >> > Please let me know your thoughts on this and share some more ideas
> > to
> > > >> how
> > > >> > we can improve/resolve this issue. Looking forward to your replies!
> > > >> >
> > > >> >
> > > >> >
> > > >> > Thanks & Regards,
> > > >> > Devanshu Vyas.
> > > >>
> > > >
> >

[Deepak Dixit-4]

Yes, something like this or even we can have a simple text box to enter the
page value or a much better solution.

Devanshu, Could you please open a ticket for this improvement?

Thanks & Regards
--
Deepak Dixit



On Sun, Dec 16, 2018 at 2:17 PM Taher Alkhateeb <[hidden email]>
wrote:

> Ahh, so you want an auto complete text box that fetches from server on
> the fly using jQuery right? If so, sure +1
>
> On Sun, Dec 16, 2018 at 11:41 AM Deepak Dixit <[hidden email]>
> wrote:
> >
> > Pagination widget tries to generate select with a huge number of options
> so
> > browser takes too much time to prepare dom and causing unresponsiveness.
> >
> > So we can say that the root cause is in the pagination widget that
> > prepares select option. We need a different pattern rather than select
> > element for rendering the page (VIEW_INDEX)
> >
> > Thanks & Regards
> > --
> > Deepak Dixit
> >
> >
> >
> > On Sat, Dec 15, 2018 at 7:14 PM Taher Alkhateeb <
> [hidden email]>
> > wrote:
> >
> > > Yeah so what you are describing is a pagination issue right? The root
> > > cause is pagination, not type of widget being used? I'm a little
> > > confused by the proposal?
> > >
> > > On Fri, Dec 14, 2018 at 4:08 PM Devanshu Vyas <
> [hidden email]>
> > > wrote:
> > > >
> > > > Hello Taher,
> > > >
> > > > The browser becomes unresponsive to a user in this case, as the
> browser
> > > is
> > > > busy in preparing the large '*select*' DOM element(a drop-down with
> > > around
> > > > 250,000 options).
> > > > I found some points related to our discussion here
> > > > <https://developers.google.com/web/tools/lighthouse/audits/dom-size
> >.
> > > >
> > > >
> > > > Thanks & Regards,
> > > > Devanshu Vyas.
> > > >
> > > >
> > > > On Fri, Dec 14, 2018 at 3:56 PM Devanshu Vyas <
> [hidden email]
> > > >
> > > > wrote:
> > > >
> > > > > Hello Taher,
> > > > >
> > > > > The FTL is trying to render a list(select box) with a large number
> of
> > > > > options(around 250,000 in my case) which takes a lot of time and
> the
> > > > > browser usually asks to either kill the page or wait for it to load
> > > > > completely.
> > > > >
> > > > > Thanks & Regards,
> > > > > Devanshu Vyas.
> > > > >
> > > > >
> > > > > On Fri, Dec 14, 2018 at 2:18 PM Taher Alkhateeb <
> > > > > [hidden email]> wrote:
> > > > >
> > > > >> before proposing the solution we need a diagnosis. What is the
> strain
> > > > >> happening on the browser?
> > > > >> On Fri, Dec 14, 2018 at 9:11 AM Devanshu Vyas <
> > > [hidden email]>
> > > > >> wrote:
> > > > >> >
> > > > >> > Hello Guys,
> > > > >> >
> > > > >> > Recently, I came across a situation where an entity was taking
> too
> > > much
> > > > >> of
> > > > >> > a time(browser asked me to either wait or kill) while
> > > loading/searching
> > > > >> > results in the Webtools application. The entity had close to 5M
> > > records,
> > > > >> > and I checked the server responded timely but the rendering of
> the
> > > > >> screen
> > > > >> > was taking time.
> > > > >> > When I explored the issue I came across a macro which renders
> the
> > > > >> > pagination on the screen, and it had a code block which was
> causing
> > > the
> > > > >> > screen rendering delay.
> > > > >> > {code}
> > > > >> >
> > > > >> > <#assign x=(listSize/viewSize)?ceiling>
> > > > >> >   <#list 1..x as i>
> > > > >> >     <#if i == (viewIndex+1)><option selected="selected"
> > > > >> > value="<#else><option value="</#if>${i-1}">${i}</option>
> > > > >> >   </#list>
> > > > >> >
> > > > >> > {code}
> > > > >> > This code seems logical enough to me, and what I gather from
> this is
> > > > >> that
> > > > >> > the list will render a select box with 250,000 options.
> > > > >> >
> > > > >> > I would like to propose a change in this UI/UX from select box
> to an
> > > > >> input
> > > > >> > text box so a user can navigate to any page, similar to a
> navigation
> > > > >> input
> > > > >> > box in a PDF document reader application.
> > > > >> >
> > > > >> > Please let me know your thoughts on this and share some more
> ideas
> > > to
> > > > >> how
> > > > >> > we can improve/resolve this issue. Looking forward to your
> replies!
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > Thanks & Regards,
> > > > >> > Devanshu Vyas.
> > > > >>
> > > > >
> > >
>

[Devanshu Vyas-2]

Thanks Deepak and Taher.

I have created a JIRA ticket
<https://issues.apache.org/jira/browse/OFBIZ-10716> for the task.

Thanks & Regards,
Devanshu Vyas.


On Sun, Dec 16, 2018 at 2:33 PM Deepak Dixit <[hidden email]> wrote:

> Yes, something like this or even we can have a simple text box to enter the
> page value or a much better solution.
>
> Devanshu, Could you please open a ticket for this improvement?
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
>
> On Sun, Dec 16, 2018 at 2:17 PM Taher Alkhateeb <
> [hidden email]>
> wrote:
>
> > Ahh, so you want an auto complete text box that fetches from server on
> > the fly using jQuery right? If so, sure +1
> >
> > On Sun, Dec 16, 2018 at 11:41 AM Deepak Dixit <[hidden email]>
> > wrote:
> > >
> > > Pagination widget tries to generate select with a huge number of
> options
> > so
> > > browser takes too much time to prepare dom and causing
> unresponsiveness.
> > >
> > > So we can say that the root cause is in the pagination widget that
> > > prepares select option. We need a different pattern rather than select
> > > element for rendering the page (VIEW_INDEX)
> > >
> > > Thanks & Regards
> > > --
> > > Deepak Dixit
> > >
> > >
> > >
> > > On Sat, Dec 15, 2018 at 7:14 PM Taher Alkhateeb <
> > [hidden email]>
> > > wrote:
> > >
> > > > Yeah so what you are describing is a pagination issue right? The root
> > > > cause is pagination, not type of widget being used? I'm a little
> > > > confused by the proposal?
> > > >
> > > > On Fri, Dec 14, 2018 at 4:08 PM Devanshu Vyas <
> > [hidden email]>
> > > > wrote:
> > > > >
> > > > > Hello Taher,
> > > > >
> > > > > The browser becomes unresponsive to a user in this case, as the
> > browser
> > > > is
> > > > > busy in preparing the large '*select*' DOM element(a drop-down with
> > > > around
> > > > > 250,000 options).
> > > > > I found some points related to our discussion here
> > > > > <
> https://developers.google.com/web/tools/lighthouse/audits/dom-size
> > >.
> > > > >
> > > > >
> > > > > Thanks & Regards,
> > > > > Devanshu Vyas.
> > > > >
> > > > >
> > > > > On Fri, Dec 14, 2018 at 3:56 PM Devanshu Vyas <
> > [hidden email]
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Hello Taher,
> > > > > >
> > > > > > The FTL is trying to render a list(select box) with a large
> number
> > of
> > > > > > options(around 250,000 in my case) which takes a lot of time and
> > the
> > > > > > browser usually asks to either kill the page or wait for it to
> load
> > > > > > completely.
> > > > > >
> > > > > > Thanks & Regards,
> > > > > > Devanshu Vyas.
> > > > > >
> > > > > >
> > > > > > On Fri, Dec 14, 2018 at 2:18 PM Taher Alkhateeb <
> > > > > > [hidden email]> wrote:
> > > > > >
> > > > > >> before proposing the solution we need a diagnosis. What is the
> > strain
> > > > > >> happening on the browser?
> > > > > >> On Fri, Dec 14, 2018 at 9:11 AM Devanshu Vyas <
> > > > [hidden email]>
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > Hello Guys,
> > > > > >> >
> > > > > >> > Recently, I came across a situation where an entity was taking
> > too
> > > > much
> > > > > >> of
> > > > > >> > a time(browser asked me to either wait or kill) while
> > > > loading/searching
> > > > > >> > results in the Webtools application. The entity had close to
> 5M
> > > > records,
> > > > > >> > and I checked the server responded timely but the rendering of
> > the
> > > > > >> screen
> > > > > >> > was taking time.
> > > > > >> > When I explored the issue I came across a macro which renders
> > the
> > > > > >> > pagination on the screen, and it had a code block which was
> > causing
> > > > the
> > > > > >> > screen rendering delay.
> > > > > >> > {code}
> > > > > >> >
> > > > > >> > <#assign x=(listSize/viewSize)?ceiling>
> > > > > >> >   <#list 1..x as i>
> > > > > >> >     <#if i == (viewIndex+1)><option selected="selected"
> > > > > >> > value="<#else><option value="</#if>${i-1}">${i}</option>
> > > > > >> >   </#list>
> > > > > >> >
> > > > > >> > {code}
> > > > > >> > This code seems logical enough to me, and what I gather from
> > this is
> > > > > >> that
> > > > > >> > the list will render a select box with 250,000 options.
> > > > > >> >
> > > > > >> > I would like to propose a change in this UI/UX from select box
> > to an
> > > > > >> input
> > > > > >> > text box so a user can navigate to any page, similar to a
> > navigation
> > > > > >> input
> > > > > >> > box in a PDF document reader application.
> > > > > >> >
> > > > > >> > Please let me know your thoughts on this and share some more
> > ideas
> > > > to
> > > > > >> how
> > > > > >> > we can improve/resolve this issue. Looking forward to your
> > replies!
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > Thanks & Regards,
> > > > > >> > Devanshu Vyas.
> > > > > >>
> > > > > >
> > > >
> >
>