[JEE] Verslag interactief maken in webapplicatie

zondag 16 juli 2006 16:07

Design-by-buzzword fanatic

Je wilt dus eigenlijk een template waarin de gebruiker kan typen op de daarin aangegeven plaatsen? Een soort Excel template waarin bepaalde zaken ingevuld worden en andere zaken gelocked zijn?

Dat is volgens mij vrij lastig op het web, tenzij je zo'n eenvoudige template hebt met alleen header, content, footer ofzo waarin de content ingevuld moet worden.

Als je iets meer controle wilt, leg dan tekstvelden neer op de invulbare plaatsen en eventueel een FCK Editor zonder werkbalken.

Dit voldoet volgens mij wel, zolang je template maar vastligt.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

zondag 16 juli 2006 16:54

Carpe Diem!

Topicstarter

In principe hoeven de delen niet gelockt te worden.
Er moet wel mogelijkheid zijn tot templating (zoals aangegeven), waarin de dynamische velden afhankelijk van de gebruiker en context ingevuld worden. Deze rendering wordt dan aan de gebruiker getoond (in een rich-text), waarin deze hem nog kan aanpassen en op het moment van 'saven' hem deze tekst als PDF ter download aangeboden wordt.

Het gaat me eerder om de keuze van het verwezenlijken van dergelijke template. Hoe bouw ik deze het best op en welk framework gebruik ik daar dan het beste voor? Er zijn veel mogelijkheden.

In de toekomst zou het eventueel zelfs mogelijk moeten zijn dat de gebruiker een eigen vorm van templating zal gebruiken, die de default overrulen (maar hier houdt ik tot dusver geen rekening mee)

Acties:

maandag 17 juli 2006 09:01

Design-by-buzzword fanatic

JasperReports is zeker een goeie optie lijkt mij. Die kan namelijk zowel PDF als andere opmaak genereren, zoals HTML en XML. Dat geeft je redelijk veel opties, zoals het versturen/printen van het uiteindelijke verslag in PDF, terwijl het in HTML aangepast wordt. Het aanpassen van die HTML kan dan weer prima in een editor zoals FCK.
Ook kun je er een mooi tooltje bij gebruiken voor het maken van de templates, namelijk IReport:
http://ireport.sourceforge.net/

Ik heb er zelf geen ervaring mee, maar bij ons op het werk zijn er wel verschillende collega's vrij enthausiast over.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

maandag 17 juli 2006 09:10

Carpe Diem!

Topicstarter

Zijn er nog andere mogelijkheden buiten Jasperreports? Op zich leek me dit wel een goede match te zijn, vooral owv de verschillende export mogelijkheden in combinatie met deze interactie (dus eerst HTML, aanpassingen, PDF) en is deze terugkoppeling wel mogelijk of is het beter om vanuit de HTML rechtstreeks de PDF te genereren?

Welke toegevoegde meerwaarde kan Velocity oid bvb bieden?

Ik heb zelf ook al goede dingen over Jasperreports gehoord, daar niet van, maar ik zou toch graag de mogelijkheden openhouden en de keuze laten vallen op de tool/framework die het meest bij mijn requirements aansluit. Daarom wil ik andere opties zeker nog even open houden.

Acties:

maandag 17 juli 2006 09:37

Design-by-buzzword fanatic

Overigens moet je wel opletten bij het genereren van PDF's. Dat kan, zeker als ze wat groter zijn, weleens wat processortijd kosten. Stukken zwaarder dan HTML.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

dinsdag 18 juli 2006 07:31

Misschien kun je wat met Reportmill
Voor een ongeveer zelfde situatie hebben wij ooit in het verleden gekozen voor XML templating met en Docbook DTD en de grafische XMLMind XMLEditor. De uiteindelijk XML-files werden dan gerenderd naar PDF met Docbook FO.
Dit was echter in een fat client.

Acties:

dinsdag 18 juli 2006 09:57

Design-by-buzzword fanatic

JKVA schreef op maandag 17 juli 2006 @ 09:10:
Overigens moet je wel opletten bij het genereren van PDF's. Dat kan, zeker als ze wat groter zijn, weleens wat processortijd kosten. Stukken zwaarder dan HTML.

Weet iemand eigenlijk hoe zwaar JasperReports is? Ik heb deze wijsheid van horen zeggen, maar nu zit ik eigenlijk met dezelfde vraag.

Voor mijn project moeten we ook lijsten gaan printen. En HTML/CSS biedt niet genoeg opties waardoor we bijna aan PDF vastzitten. Bovendien zijn het vrij grote lijsten, waardoor performace (zoals altijd) wel een issue kan worden...

Iemand hier ervaring mee?

Fat Pizza's pizza, they are big and they are cheezy

Acties:

woensdag 19 juli 2006 11:19

JKVA schreef op dinsdag 18 juli 2006 @ 07:31:
[...]

Weet iemand eigenlijk hoe zwaar JasperReports is? Ik heb deze wijsheid van horen zeggen, maar nu zit ik eigenlijk met dezelfde vraag.

Voor mijn project moeten we ook lijsten gaan printen. En HTML/CSS biedt niet genoeg opties waardoor we bijna aan PDF vastzitten. Bovendien zijn het vrij grote lijsten, waardoor performace (zoals altijd) wel een issue kan worden...

Iemand hier ervaring mee?

Bij grote rapporten, met name bij subrapporten, vraagt het inderdaad nogal veel.

Acties:

woensdag 19 juli 2006 11:57

Carpe Diem!

Topicstarter

Vraagt het idd nogal veel? Dat is wel een erg onduidelijke beschrijving waar niemand iets aan heeft imho. Ik ben er trouwens nog altijd niet uit.

Vooral omdat ik niet goed weet wat er nu het best in mijn situatie past. Jasperreports is idd een optie, maar lijkt me eerder een reporting tool te zijn ipv van het generen van brieven/verslagen, die altijd op een A4 moeten passen. Langs de andere kant, kan je er wel mooi template-files mee creëeren (iReport), die dan dienst kunnen doen als algemeen ontwerp. Maar dan zit ik wel met veel faseringen binnen een enkele use case.
ReportTemplate -> HTML -> HTML bewaren in DB -> PDF generen.

Als er dan dus iets aan de reportTemplate verandert, worden deze veranderingen niet doorgevoerd op de plaatsen waar er enkel HTML gebruikt werd. Ook kunnen de gebruikers op deze manier de layout wel erg goed naar de haaien helpen.

Alle ideeën nog steeds welkom dus

Acties:

jAnO!

lalalavanillevla

Snelle lightweight oplossing:
Form voor de dynamische velden en vrije textveld. > Database

Los templatefiles in xml, van waaruit pdfjes gemaakt kunnen worden.

Vullen templates doe ik zo:

Java:

  private void doUpdate(final String whatever1, String whatever2) throws IOException, UpdateException {
    StringBuffer request = readFile("mijnTemplate.xml"); //$NON-NLS-1$

    replaceString(request, "Voornaam", //$NON-NLS-1$
        whatever1);
    replaceString(request, "Achternaam", //$NON-NLS-1$
        whatever2);
    doErIetsMee(request);

  }
  /**
   * Reads a file with name fileName from the request templates dir and returns
   * the content of the file as a StringBuffer.
   * @param fileName name of the file to be read. The file is expected to be in
   *          the request templates dir.
   * @return the content of the file
   * @throws IOException if the file can not be found or opened or read
   */
  private StringBuffer readFile(final String fileName) throws IOException {
    FileInputStream fis = null;
    InputStream is = null;
    InputStreamReader isr = null;
    StringBuffer request = new StringBuffer();
    int bufsize = 1000;
    char[] input = new char[bufsize];
    int nrRead;
    try {
      is = this.getClass().getClassLoader().getResourceAsStream(
          "requesttemplates/" //$NON-NLS-1$
              + fileName);
      isr = new InputStreamReader(is);
      while ((nrRead = isr.read(input, 0, bufsize)) != -1) {
        String s = new String(input, 0, nrRead);
        request.append(s);
      }
    } catch (FileNotFoundException fnfe) {
      throw fnfe;
    } finally {
      if (fis != null) {
        fis.close();
      }
    }
    return request;
  }

  /**
   * Replaces oldValue with newValue in StringBuffer s. If s does not contain
   * oldValue, nothing changes.
   * @param s a StringBuffer in which one substring must be replaced by another
   *          String
   * @param oldValue a substring of s that must be replaced
   * @param newValue the String that replaces the specified substring in s
   */
  private void replaceString(final StringBuffer s, final String oldValue,
      final String newValue) {
    int index = 0;
    if ((index = s.indexOf(oldValue)) != -1) {
      s.replace(index, index + oldValue.length(), newValue);
    }
  }

gaat in mijn projectje als de spreekwoordelijke brandweer.

When some people work at a place for ten years they get ten years of experience, other people work at a place for ten years and get one year of experience ten times.

donderdag 20 juli 2006 18:09

Acties:

maandag 24 juli 2006 15:51

Carpe Diem!

Topicstarter

jAnO! schreef op woensdag 19 juli 2006 @ 11:57:
Snelle lightweight oplossing:
Form voor de dynamische velden en vrije textveld. > Database

Los templatefiles in xml, van waaruit pdfjes gemaakt kunnen worden.

Vullen templates doe ik zo:
Java:
1
//implementatie
gaat in mijn projectje als de spreekwoordelijke brandweer.

Dat is natuurlijk wel een oplossing, maar imo niet echt een mooie. Je werkt eigenlijk gewoon met een aantal string patterns die at runtime ingevuld zullen worden met een aantal database variabelen. De oplossing die ik tracht te vinden is iets meer generieker.

Ik denk dat ik maar voor de JasperReports oplossing zal gaan, maar sta er toch niet 100% achter omdat ik het gevoel heb dat ik niet alle mogelijkheden op een deftige manier met elkaar heb kunnen vergelijken. Ik zit met deze oplossing namelijk nog steeds met data redundantie, aangezien ik de user-input uit het richtextbox volledig op correctheid aanneem en deze data ook zal bewaren in de database en dus niet de template met de ingevulde waarden. Op basis van deze html zal de pdf dan gegenereerd worden.

Als er nog andere en betere ideeën zijn, hoor ik deze graag natuurlijk!

Acties:

maandag 24 juli 2006 20:41

Wat vond je van mijn reportmill?

Acties:

dinsdag 25 juli 2006 07:03

Carpe Diem!

Topicstarter

Nog niet echt serieus naar gekeken. Ik vermoed dat het wat in dezelfde lijn als JasperReports ligt, maar ik weet niet in hoeverre het mijn probleem op kan lossen. Ik dien eerst van template naar HTML te gaan, zodat de gebruiker nog eventuele aanpassingen kan doen. En van die HTML moet er dan een document gegenereerd worden, die de eindgebruiker dan kan afdrukken.

Blijkbaar is dit niet zo triviaal dan ik eerst verwachtte, aangezien niemand een antwoord kan geven op het (duidelijke?) probleem.

Acties:

dinsdag 25 juli 2006 08:26

Design-by-buzzword fanatic

-FoX- schreef op maandag 24 juli 2006 @ 20:41:
Blijkbaar is dit niet zo triviaal dan ik eerst verwachtte, aangezien niemand een antwoord kan geven op het (duidelijke?) probleem.

Het woord "duidelijk" begin ik een beetje aan te twijfelen.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

dinsdag 25 juli 2006 14:44

Carpe Diem!

Topicstarter

Wat is er niet duidelijk dan?

Een webapplicatie moet printbare brieven kunnen genereren. Gewone html-pagina's kunnen geen dienst doen, aangezien deze nog altijd afhangen van de browser (er wordt bvb standaard de header/footer geprint die het webadres e.d. bevat). Deze brieven moeten opgemaakt worden adh van een soort templating systeem, aangezien deze variabele gegevens zal bevatten. De gebruikers krijgen dan een vooropgemaakte brief voorgeschoteld, waar zij nog een laatste aanvulling aan te dienen doen. Dan moet deze "ter print" ter beschikking gesteld worden.

Acties:

dinsdag 25 juli 2006 15:39

Design-by-buzzword fanatic

Dat begrijp ik, maar waarom we geen antwoord kunnen geven, zie ik even niet. Er zijn een paar opties genoemd. Het enige lastige lijkt me het netjes tonen van de brief terwijl je deze mag editen.

Als een previewoptie ook voldoet, is het niet zo moeilijk volgens mij, dan leg je gewoon een stel velden neer waar de params in gezet worden.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

matthijsln

Je kan ook zoiets maken met XSL-FO.

Input van gebruiker structureren in XML, eventueel met wat simpele opmaak tags. Transformeer die XML met een XSL stylesheet naar FO wat je met bv. Apache FOP naar een PDF kan omzetten.

Voor je opmaak tags kan je bijvoorbeeld wat simpele templates maken zoals dit:

XML:

<xsl:template match="p">
    <fo:block space-after="0.6cm">
        <xsl:apply-templates/>
    </fo:block>
</xsl:template>

<xsl:template match="br">
    <fo:block/>
</xsl:template>

<xsl:template match="b">
    <fo:inline font-weight="bold">
        <xsl:apply-templates/>
    </fo:inline>
</xsl:template>

Nadeel is wel dat je regelijk goed XSL-FO moet kennen en dat je geen standaard report framework hebt zoals met de andere mogelijkheden; je hebt niet 1-2-3 een rapport in elkaar geflanst.

Deze methode heb ik een keer gebruikt om een stuk of wat brieven te genereren voor een applicatie, opzich vind ik het wel een mooie oplossing. De complexiteit van die brieven en wat de gebruiker er aan kon wijzigen viel wel mee trouwens.

dinsdag 25 juli 2006 15:57

Acties:

TeeDee

CQB 241

En, misschien te simpel, maar als je nu een PDF formulier online zet? Als het minimale aanpassingen zijn lijkt me dat het makkelijkste.

Door 'ergens onderaan je form' een submit button te plaatsen kan je hiermee netjes de post vars uitlezen, zeker met iText (als iTextSharp het kan, moet iText het zeker kunnen).

Heart..pumps blood.Has nothing to do with emotion! Bored

dinsdag 25 juli 2006 18:18

Acties: