Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien
Toon posts:

Waarom reageren mijn webapp buttons zo slecht?

Pagina: 1
Acties:

Verwijderd

Topicstarter
Wanneer ik op een button klik in mijn webapp geven zij vaak niet gelijk een respons. De ene button reageert nog slechter dan de ander. De buttons zonder afbeelding reageren overigens wel beter dan die met afbeelding.

Er moet een betere code zijn dan wat ik nu gebruik. Iemand goed advies?

Alvast bedankt!

Dit is mijn code:

CSS
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
[class*="button"] {
position: relative;
display: inline-block;
padding: 6px 12px;
margin: 0;
font-weight: bold;
text-align: center;
cursor: pointer;
border-radius: 6px;
z-index: 10;
font-size: 12px;
color: #fff;
text-shadow: 0 -1px 0 rgba(0,0,0,.3);
background-color: #DF3317;
background-image: -ms-linear-gradient(top,#DF3317 0%,#CB2F14 100%);
background-image: -moz-linear-gradient(top,#DF3317 0%,#CB2F14 100%);
background-image: -o-linear-gradient(top,#DF3317 0%,#CB2F14 100%);
background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0,#DF3317),color-stop(1,#CB2F14));
background-image: -webkit-linear-gradient(top,#DF3317 0%,#CB2F14 100%);
background-image: linear-gradient(to bottom,#DF3317 0%,#CB2F14 100%);
border: 1px solid #8E3523;
-webkit-box-shadow: 0px 1px 1px rgba(255,255,255,0.25);
-moz-box-shadow: 0px 1px 1px rgba(255,255,255,0.25);
box-shadow: 0px 1px 1px rgba(255,255,255,0.25);
}
#button_left_wScr, #button_left_spts, #button_left_winqs {
position: absolute;
top: 8px;
left: 6px;
}
.tab-icon {
height: 22px;
margin: 0 auto;
}


JAVA EE
code:
1
2
3
4
5
6
7
<div class="button" id="button_left_wScr">
                <h:form>                   
                    <h:commandButton id="Back" value="#{msg.back}"
                                     action="#{ProjectMainAppManager.startMainPage}"
                                     styleClass="tab-icon" 
                                     image="img/back.png"/> </h:form>
            </div>


vertaald naar html is dat

code:
1
2
3
4
5
<form id="j_idt7" name="j_idt7" method="post" action="/Project/AndroidFiles/PictureScreen.xhtml" enctype="application/x-www-form-urlencoded">
<input type="hidden" name="j_idt7" value="j_idt7">
<input id="j_idt7:Back" type="image" src="img/back.png" name="j_idt7:Back" class="tab-icon">
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="-3755854209444710919:-7904307992137192045" autocomplete="off">
</form>

  • kwaakvaak_v2
  • Registratie: Juni 2009
  • Laatst online: 10-10 08:02
Ik gok dat de button ansich wel reageert zoals ie zou moeten, maar het je applicatie nogal traag is met interpreteren van de click.

Driving a cadillac in a fool's parade.


  • _Thanatos_
  • Registratie: Januari 2001
  • Laatst online: 05-09 14:39

_Thanatos_

Ja, en kaal

[class*="button"] :?

.button was te makkelijk? Bedenk wel dat complexere CSS langer duurt om te parsen/resolven. Heeft meer met laadtijd te maken, maar ook voor een deel met hover/active/focus states.

De html die uit je java komt, lijkt niet helemaal te kloppen. Een form met twee hiddens en een image-input. (serieus, gebruiken we die nog?) Maar daar zit dus geen button in. Iets zegt me dus dat er nog wat omheen zit waar die class op staat, waarbij je dus het *hele* form indrukt... Ofzo. Geen wonder dat het traag is.

Maak er eens gewoon een <button type=submit> van en submit daarmee het form. Dat is tenminste een standaard-iets en werkt overal.

[ Voor 52% gewijzigd door _Thanatos_ op 13-08-2013 21:09 ]

日本!🎌


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 22-11 13:46

Janoz

Moderator Devschuur®

!litemod

_Thanatos_ schreef op dinsdag 13 augustus 2013 @ 21:05:
De html die uit je java komt, lijkt niet helemaal te kloppen. Een form met twee hiddens en een image-input. (serieus, gebruiken we die nog?) Maar daar zit dus geen button in. Iets zegt me dus dat er nog wat omheen zit waar die class op staat, waarbij je dus het *hele* form indrukt... Ofzo. Geen wonder dat het traag is.
html klopt 'gewoon'. De hiddens worden automatisch door JSF toegeovegd voor allerlei state informatie en de type=image is gewoon en submitbutton in de form van een plaatje. Uiteindelijk is het wel de div die de boel naar een button styled, maar dat lijkt me gewoon een clientside dingetje.

De traagheid zou je even moeten profilen. Het zou best kunnen dat de startMainPage methode een stuk meer doet dan je verwacht waardoor de server best lang bezig kan zijn.
Maak er eens gewoon een <button type=submit> van en submit daarmee het form. Dat is tenminste een standaard-iets en werkt overal.
type image en type submit zijn net zo standaard. Daarnaast heeft de topicstarter geen controle over de directie html (vanwege de JSF tussenlaag). Het mixen van wel en niet door jsf gemanagde html kan eerder meer dan minder problemen veroorzaken.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • _Thanatos_
  • Registratie: Januari 2001
  • Laatst online: 05-09 14:39

_Thanatos_

Ja, en kaal

Janoz schreef op donderdag 15 augustus 2013 @ 12:29:
[...]

html klopt 'gewoon'. De hiddens worden automatisch door JSF toegeovegd voor allerlei state informatie en de type=image is gewoon en submitbutton in de form van een plaatje. Uiteindelijk is het wel de div die de boel naar een button styled, maar dat lijkt me gewoon een clientside dingetje.
Het is niet "gewoon een clientside dingetje". Kijk uit met dat soort uitspraken. Je kunt niet een sloot html uitkotsen en dan verwachten dat dat zomaar even goed gestyled kan worden. Punt blijft dat de styling op een div om het hele form heen zit en je dus feitelijk op het hele form probeert te klikken. Ik weet niet of dit de reden dat het traag werkt, maar het verbaast me niets als de browser dit niet leuk vind.

Ja het is correct, maar syntactisch correct is nog niet per se "goed". Maak gewoon een <button type=submit> ipv die <input type=image> en style daarop.

日本!🎌


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 22-11 13:46

Janoz

Moderator Devschuur®

!litemod

_Thanatos_ schreef op donderdag 15 augustus 2013 @ 20:56:
[...]

Het is niet "gewoon een clientside dingetje". Kijk uit met dat soort uitspraken. Je kunt niet een sloot html uitkotsen en dan verwachten dat dat zomaar even goed gestyled kan worden. Punt blijft dat de styling op een div om het hele form heen zit en je dus feitelijk op het hele form probeert te klikken. Ik weet niet of dit de reden dat het traag werkt, maar het verbaast me niets als de browser dit niet leuk vind.
Ja, de button ziet er uit als een button, maar het enige ding dat werkt is toch echt die image. Ik zie geen styling die werkt op de onclick dus de enige 'load' is bij het voor het eerst renderen van de pagina, niet bij het drukken.
Ja het is correct, maar syntactisch correct is nog niet per se "goed". Maak gewoon een <button type=submit> ipv die <input type=image> en style daarop.
Het gaat hier om gegenereerde html code. Om een submit te genereren zul je zeer waarschijnlijk een commandbutton moeten gebruiken zonder een image, maar dan krijg je gewoon een standaard button met tekst die gewoon exact hetzelfde werkt. Ik kan me onmogelijk voorstellen dat dat ook maar iets met performance van doen heeft. Sterker nog, de button heeft annimaties met de clickacties terwijl een image dat niet heeft.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Verwijderd

Topicstarter
Bedankt voor jullie reacties. Ik vind het een interessante discussie.

Concreet brengt mij dit op de vragen:

- Is de performance beter wanneer ik het image attribuut in de jsf button tag vermijd? Zo ja hoe los ik het dan met css op?

- Is het slecht om een div met style attribuut, om een button tag heen de plaatsen? Ik zou de style ook aan de style attribuut van de button tag kunnen koppelen is dat beter?

-Op welke andere vlakken valt er winst te behalen om de performance van mijn mobile webapp buttons te verbeteren?

  • Bosmonster
  • Registratie: Juni 2001
  • Laatst online: 19-11 09:49

Bosmonster

*zucht*

Wat bedoel je met "niet direct respons"? Is het enkele seconden, of reageren ze gewoon net een fractie later?

Dat laatste is vrij gebruikelijk bij normale links en buttons op touchscreens namelijk, tenzij je het om gaat scripten naar touch-events.

Als het echt om grote verschillen gaat ligt het aan de traagheid van je backend en maakt het helemaal niks uit hoe je markup eruit zien (en kunnen je eerste twee vragen met "nee" worden beantwoord).

Ga nu eerst eens analyseren waar de vertraging precies zit middels een profiler, ipv wilde aannames over of een divje of button type verschil gaat maken ;)

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 22-11 13:46

Janoz

Moderator Devschuur®

!litemod

Verwijderd schreef op donderdag 15 augustus 2013 @ 23:38:
Bedankt voor jullie reacties. Ik vind het een interessante discussie.

Concreet brengt mij dit op de vragen:

- Is de performance beter wanneer ik het image attribuut in de jsf button tag vermijd? Zo ja hoe los ik het dan met css op?
nee
- Is het slecht om een div met style attribuut, om een button tag heen de plaatsen? Ik zou de style ook aan de style attribuut van de button tag kunnen koppelen is dat beter?
nee
-Op welke andere vlakken valt er winst te behalen om de performance van mijn mobile webapp buttons te verbeteren?
Ik zou bijna zeggen: Geen JSF gebruiken. Ik kan me goed voorstellen dat er tijdens JSF cycle heel wat meer gebeurd dan je op dit moment verwacht (Zijn er misschien een heleboel request scoped beans die aangemaakt worden? Heb je een onnodig grote session?). Daardoor zal de afhandeling van je request een stuk langer duren.

Echter kun je hier pas echt wat over zeggen wanneer je daadwerkelijk eens geprofiled hebt waar de vertraging nu daadwerkelijk vandaan komt.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • msentinelb
  • Registratie: Juli 2002
  • Laatst online: 23:22

msentinelb

Arghhhhh!

Indien het probleem zich alleen op touch apparaten voor doet kan ik deze microlib aanraden. Gemaakt door een nederlander.

http://eightmedia.github.io/hammer.js/

I told you, homeboy / You CAN touch this

Specs van mijn bak Hier!

Pagina: 1