[servlet+js] submit() geeft geen value terug naar servlet

[Verwijderd]

Beste medetweaker.

Mijn probleem is op dit moment dat ik geen waardes terug krijg via javascript naar mijn java/servlet toe.
De bedoeling is dat er vanuit een comboSelect Box de waarde terug komt in mijn servlet.
Selectbox staat in een html.table.

code:

 <td><form name="form1" method="post" action="/servlet1/app1">
        <div align="right">
    <SELECT  NAME="ItemBox" onChange="setCurrItem()"> OPTION VALUE="s">Small
          </SELECT>
        </div>
      </form></td>

De jsFunctie ziet er als volgt uit:

code:

<script language="JavaScript1.2" type="text/JavaScript1.2">
function setCurrItem()
{
var var1=form1.ItemBox.value;
document.form1.submit();
}
</script>

De javaCode in mijn servlet is:

code:

  public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
  {
    String str1 = request.getParameter("var1");
    ixPageProducer1.servletGet(this, request, response);
  }

Indien ik een item uit selectbox selecteer komt 'event' wel in de servlet terecht, dus dat werkt, alleen de value is null.
Met document.location.waarde in js werkt het wel, maar start telkens nieuwe app op met beginwaarden wat niet de bedoeling is.

Help?

[Glimi]

Je Option heeft geen openingstag

[Verwijderd]

Op moment dat Servlet zijn werk gedaan heeft ziet de htmlCode er als volgt uit.
Verder weet ik niet wat je bedoelt met openingstag?

code:

<select name="ItemBox" size="1" onchange="setCurrItem()">
<option selected="selected" value="b_0">b_0</option>
<option value="b_1">b_1</option>
<option value="b_2">b_2</option>
<option value="b_3">b_3</option>
<option value="b_4">b_4</option></select>

Maar ik krijg dus nog steeds geen waarde terug in mijn servlet met submit()
met document.location.... krijg ik dus wel de currentWaarde terug.

[Verwijderd]

method="post"
public void doGet

Tja, dat werkt natuurlijk niet. Gebruik method="get" en doGet, of method="post" en doPost.

[Verwijderd]

Dank voor je reactie, maar in de volgende methode staat een do_Get :

code:

  public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
  {
       doGet(request, response);
  }

Maar zoals ik vertelde werkt het prima met document.location
Ook met een submitButton werkt het prima.

[Verwijderd]

Iemand enig idee? of wordt er niet veel met deze combinatie gewerkt en is er meer know-how en aandacht voor bv. php en asp.

[Verwijderd]

Verwijderd schreef op 17 December 2002 @ 09:05:
Iemand enig idee? of wordt er niet veel met deze combinatie gewerkt en is er meer know-how en aandacht voor bv. php en asp.

Ik denbk dat je met deze conclusie wel in de richting zit, ik heb zelf ook geen idee, maar je zou es kunnen kijken op http://groups.google.com misschien dat er een groep bij zit die re iets meer van weet.

[Verwijderd]

een waarde die gezet is in javascript wordt nooit teruggestuurd naar de server door de browser .... je moet de waarde uit je combobox opvragen...

dus niet
String str1 = request.getParameter("var1");
maar
String str1 = request.getParameter("ItemBox");

of als je toch perse waardes vanuit javascript wilt zetten moet je een hidden field door javascript laten zetten of zo iets

[Verwijderd]

String str1 = request.getParameter("ItemBox");
ipv. String str1 = request.getParameter("var1"); werkt perfect, ik krijg nu inderdaad de waardes in mijn servlet terug.
Maar door 'document.form1.submit();' in js, en de doGet(...) methode in de servlet, wordt de htmlPage opnieuw 'opgestart'.
Nu is het geselecteerde item in de 'select name' box verdwenen en vervangen door item #1.
En volgens mij is dit niet op te lossen

[Glimi]

Verwijderd schreef op 17 December 2002 @ 10:11:
(..)
wordt de htmlPage opnieuw 'opgestart'.
Nu is het geselecteerde item in de 'select name' box verdwenen en vervangen door item #1.
En volgens mij is dit niet op te lossen

Opgestart? Hij submit het formulier naar uw pagina welke dan de HTML ouput, die de client dan weer ontvangt. *hint*

[Bobco]

Je wilt eigenlijk een verschil maken tussen een eerste keer dat een gebruiker een pagina opvraagt en de volgende keren dat dat gebeurt doordat er een item wordt geselecteerd en jouw stukje JavaScript de pagina submit.

Daar is maar een methode voor: tussen de requests bijhouden of dit een eerste of een volgende keer is dat de servlet door een gebruiker wordt aangeroepen:

Java:

// controle op eerste keer:
if (request.getSession().getAttribute("firstCall")  == null) {
  request.getSession().setAttribute("firstCall", new Boolean(true));
  // doe de initialisatie
} else {
  // doe de afhandeling van de submit van je JavaScript
}

[Verwijderd]

Onafhankelijk van je testProcedure, moet ik de methode doGet(...) aanroepen.
Na deze aanroep wordt de htmlPage opnieuw 'opgebouwd'.
Ik maak gebruik van 2 QueryDataSets waarvan 1 voor mijn 'select name box' content.
De andere wordt voor een rapportage gebruikt.
Om dynamiek te krijgen wordt via de 'select name box' een SQL-filter opgebouwd voor de rapportage (QueryDataSet #2).
Om deze veranderde content te laten zien moet ik de goGet(...) methode laten uitvoeren.
Met de vervelende bijsmaak dat 'select name box' weer op item #1 gaat staan.

Ik hoop dat ik een beetje duidelijk de case heb kunnen uitleggen.

[Bobco]

Ik begrijp het probleem nog steeds niet, geloof ik.

Afhankelijk van de waarde die de gebruiker kiest in de select-box gebruik je een bepaald filter voor de rapportage. Als dit filter alleen afhankelijk is van de gekozen waarde lijkt het me niet zo moeilijk.

Eerlijk gezegd begrijp ik nog steeds niet waarom je in de doGet() van de servlet meteen de doPost() aanroept. Als een gebruiker de eerste keer de servlet aanroept, gebeurt dat dan via een linkg (en dus een HTTP GET) of via een ander formulier (en dus een HTTP POST)? In het eerste geval hoef je je dus helemaal niet druk te maken of dit de eerste of een volgende keer is: een GET is de eerste, een POST de volgende.

Je kunt denk ik beter iets als:

Java:

private String buildListBox(Object defaultWaarde) {
   // bouw hier je listbox
}

opnemen. Je kunt dan vanuit de doGet en de doPost dezelfde opbouw gebruiken, alleen in het doPost geval zet je een andere defaultWaarde.

Kun je anders voor de duidelijkheid nog een keer de flow uitleggen? Zo van: gebruiker doet get, gebruiker doet post, servlet roept blabla aan etc...

[Verwijderd]

Bij het opbouwen van je select moet je kijken of de waarde voor "ItemBox" die de browser verstuurd, overeenkomt met de waarde van de opties die je aan het schrijven bent. Indien deze overeenkomt geef je aan de option "selected" mee... aan de andere opties geef je niet selected mee

[Verwijderd]

Ik hoop dat ik een beetje duidelijk de case heb kunnen uitleggen.

Nee (niet voor mij iig
Let op (voor zover ik het begrepen heb):
1. je selecteerd wat in een combobox. (je zou hier al kunnen kiezen in Js voor een onChange event en de waarde in een hiddenfield oid op te slaan)
2. Stuur het naar de server
3. Op de server draait een servlet. Die haalt alles binnen (doGet of doPost n.a.v. een POST of een GET natuurlijk)
4. Haal de waarde eruit. (bewaar deze ? )
5. Bouw HTML op met deze waarde en stuur terug dmv HTTP REPLY

Is mijn "flow" zo goed ? En zo ja waar zit dan de fout precies?

[Verwijderd]

Bedankt voor de reacties,
De flow is inderdaad zoals vcb beschreven heeft.
Alleen punt 5 (Bouw HTML .... dmv HTTP REPLY) is misschien iets anders.
In de methode doGet (..) wordt van een internetBean gebruik gemaakt ::ixPageProducer
Hiermee hoef ik geen gebruik te maken zoals

code:

    PrintWriter out = response.getWriter();
    out.println("<html>");
    out.println("<head><title>DBServlet</title></head>");
    out.println("<body>");
    enz.

ixPageProducer is een data- and servlet-aware componentBean, om template pages te renderen (rendering) voor dynamische content.
Hiermee is weinig code nodig.

Dus punt 5 wordt min of meer vervangen door doGet (...) (zie code in openingsTopic)

[Verwijderd]

Wat ik altijd doe is mijn pagina in een string opbouwen om duidelijk HTML en andere code van Java code gescheiden te houden zoals:

code:

String strHtml = new String()
strHtml  = "<HTML>";
strHtml+="<head><title>bla<title><head>";
strHtml+="<body>";
/*eventuele java code for lusjes SQL queries en wat al niet meer om je
HTML op te bouwen */
etc
etc

Of je gebruikt al direct een stringbuffer gaat ff om het idee
Wat ik zeggen wil is dat als je het op bovenstaande manier doet en opbouwt heb je meer
controle over je op te bouwen pagina dan als je daar een ixPageProducer of wat dan al niet meer daar voor gebruikt. (loopt deze zin nog?)
Voordeel is dat je de fout in je eigen code zoekt ipv andermans code waar je je dan enorm moet in verdiepen.

Maar dat is een afweging die je zelf moet maken natuurlijk

[Glimi]

Als de pagina en de items die die bean voor je uitpoept niet configureeerbaar zijn adv parameters, zou ik hem übersnel wegrotten of aanpassen

[Verwijderd]

Verwijderd schreef op 17 December 2002 @ 13:02:
Voordeel is dat je de fout in je eigen code zoekt ipv andermans code waar je je dan enorm moet in verdiepen.

Maar dat is een afweging die je zelf moet maken natuurlijk

Klopt, dat is ook altijd de vraag. Of je maakt alles zelf of je gebruikt libraries van derden, zodat je niet meer over detailgeneuzel hoeft te bekommeren.
Je kan je dan wel beter concentreren op functionaliteits-problematiek en zo grotere projekten behappen.