[Alg/Java] Webapplicaties en het werken met documenten

[-FoX-]

Ik open dit topic om de mening en visie van andere web developers te horen i.v.m. het werken met documenten via webapplicaties.

Eén van de nadelen van het werken met webapplicaties is het feit dat er geen sterke integratie is met het besturingssysteem van de eindgebruiker (tegelijkertijd is dit natuurlijk ook een voordeel). Met name bij het verwerken van documenten en rapporten.

Als voorbeeld kan ik misschien volgende (fictieve) requirement aanhalen:
Het moet voor de eindgebruiker mogelijk zijn om rapporten, verslagen en aanvragen af te drukken, waar het briefhoofd aangepast wordt aan zijn gegevens. Naast deze standaard brieven (A4), moet het ook mogelijk zijn om 'tickets' af te drukken op de matrixprinter, als bewijsje voor de klant.

Nu zijn er een aantal manieren waarop dit opgelost kan worden:
HTML rapport genereren
Voordeel: Snel, duidelijk en gemakkelijk te implementeren
Nadeel: Automatische browser header/footer (url), weinig controle (browser voert printopdracht uit)

PDF rapport
Voordeel: Layout verkrijgbaar zoals gewensts
Nadeel: Zwaar (vooral voor lichtere PC's), mindere controle (acrobat voert printopdracht uit)

RTF rapport
Voordeel: Gewenste layout, snel
Nadeel: Aanpasbaar, aangepaste versie moeilijk syncroniseerbaar met server

Applet gesigned
Voordeel: rechtstreeks printen, layout controle
Nadeel: Java runtime, zwaarder voor browser

... overige oplossingen?


Maar geen van allen voldoet eigenlijk perfect aan de noden van de requirement. Op welke manier zou jij het implementeren? Of zou je voor een workaround kiezen?

Zijn voor zulke requirements een webapplicatie eigenlijk wel geschikt?

Webapplicaties zijn op heden populair, is dit terecht? Hoe zie jij de toekomst in van de webapplicaties over het algemeen?

[Pino]

Ik denk dat het tijd wordt voor generieke systemen om webapplicacties 'te vertrouwen' en deels toegang te geven tot het bestandssysteem van de eindgebruiker. Ik ben dan ook benieuwd hoe bijvoorbeeld Microsoft dit bijvoorbeeld gaat implementeren in 'on line office' enz.

[Janoz]

mwah, dat soort dingen zijn imho behoorlijke security risico's. MS krijgt het zelfs met ActiveX al moeilijk voor elkaar om alles goed dicht te krijgen.

Als ik naar die eis kijk maak ik daaruit op dat het hier om een controleerbaar (client) systeem gaat in een gesloten omgeving. In dat geval zou je kunnen kijken of de server misschien niet toegang zou kunnen krijgen tot de verschillende printers. Het printen kan dan vanaf de server gebeuren.

Een ander voordeel van een gecontroleerde omgeving is dat je de mogelijkheid hebt om bij de client je eigen plugin te instaleren. Hiervoor zou je bijvoorbeeld een ActiveX object (Of firefox plugin) kunnen schrijven die dit printen voor je afhandeld.

[Pino]

Janoz schreef op zondag 06 november 2005 @ 13:38:

Een ander voordeel van een gecontroleerde omgeving is dat je de mogelijkheid hebt om bij de client je eigen plugin te instaleren. Hiervoor zou je bijvoorbeeld een ActiveX object (Of firefox plugin) kunnen schrijven die dit printen voor je afhandeld.

Dat is dus wat ik bedoel, dat moet je eigenlijk een beetje generiek maken voor bepaalde toepassingen.

[Janoz]

Mwah, in principe wil je dat neit generiek maken omdat je eigenlijk niet wilt dat iedereen zomaar die functionaliteit in je browser aan kan spreken. Vandaar ook dat ik het hier over een gecontroleerde omgeving hebt. Een omgeving waarbij je naast de baas over de server, ook enige invloed uit kunt oefenen op wat er allemaal op de clients staat.

[-FoX-]

Op welke manier zie je dergelijke implementatie dan?

Enerzijds heb ik het idee dat dergelijke functionaliteit eigenlijk niet in een webapp thuis hoort. Anderzijds zou het toch wel mogelijk moeten zijn. Een Applet/ActiveX zou wel een oplossing zijn, maar dan hang je natuurlijk weer af van de browser die de client gebruikt. Ik weet ook niet in hoeverre het sandbox model van applets deze functionaliteit toelaten (dus het aansturen van verschillende type printers op de client, al dan niet aanwezig)

[ Voor 82% gewijzigd door -FoX- op 06-11-2005 13:58 ]

[misfire]

Het is wat je zelf al zegt: web applicaties zijn voor dit soort requirements eigenlijk niet zo heel geschikt. Zodra je hebt over een gecontroleerde userbase die bijna de hele dag van een toepassing gebruik maken dan zie je meestal ook requirements die buiten de document-georienteerde gedachte van web technolgie vallen.

Als dit je enige requirement is die niet makkelijk in een web-app te realiseren is, en de web-techniek heeft concrete voordelen voor je project, dan zou ik gaan voor een ActiveX control of Java applet. Waarschijnlijk zul je echter wel wat meer dingen tegenkomen die niet echt lekker werken in een browser. Waarom dan niet gewoon een dikke client maken, en die lekker Webstarten of ClickOncen?

[H!GHGuY]

waarom kun je niet op de server een document genereren en dan de client linken naar het document?

als de browser het ondersteunt verschijnt het document (pdf bvb)
en anders zal de client het downloaden.

het afdrukken moet die dan evt zelf maar doen ?

[momania]

-FoX- schreef op zondag 06 november 2005 @ 12:39:
PDF rapport
Voordeel: Layout verkrijgbaar zoals gewensts
Nadeel: Zwaar (vooral voor lichtere PC's), mindere controle (acrobat voert printopdracht uit)

pdf is toch niet zo zwaar?
Het genereren gebeurt toch op de server en niet bij de client

Ik gebruik het nu zelf ook door objecten direct om te zetten naar xml en die door te transformeren via apache FOP naar pdf. Dit alles gebeurt gewoon op de server en is nog redelijk snel ook. Die pdf wordt dan direct aangeboden aan de gebruiker.

Enige dat aan de client kant gebeurt is dan het openen van die pdf

[ari3]

momania schreef op zondag 06 november 2005 @ 16:26:
[...]

pdf is toch niet zo zwaar?
Het genereren gebeurt toch op de server en niet bij de client

Jawel, maar de gegenereerde PDF moet ook nog gerenderd worden op de client. PDF rendering is erg zwaar voor lichtere PCs. Dit geldt ook voor zware PCs trouwens als het gaat om veel pagina's zoals bij PDF-versies van boekwerken; dan kun je gewoon fijn 1 seconden wachten voor iedere keer dat je Page Down indrukt...

[koppie]

momania schreef op zondag 06 november 2005 @ 16:26:Enige dat aan de client kant gebeurt is dan het openen van die pdf

Voor gewone documenten zoals brieven en rapporten kan dat inderdaad het simpelst.

Tickets en andere speciale printerdocumenten, die speciale actie vereisen is dat vrijwel geen optie. Dan kan je waarschijnlijk beter gebruik maken van een Java-applet, die in nauwe (of nouwe??) samenwerking met de server het document afdrukt op de client. Waarschijnlijk is dat het gemakkelijkst met de bijgeleverde print-API. Dan kan je wel alle security toepassen op de webserver.

Staat de webserver in dezelfde omgeving (of VLAN), kan je het afdrukken ook geheel op de server laten afhandelen. Maar dit is vaak geen optie in grotere organisatie's waarbij er dan veel geconfigureerd op netwerkgebied moet worden.

-FoX- schreef op zondag 06 november 2005 @ 13:57:Op welke manier zie je dergelijke implementatie dan?

Ik weet ook niet in hoeverre het sandbox model van applets deze functionaliteit toelaten (dus het aansturen van verschillende type printers op de client, al dan niet aanwezig)

Oh ja, waarschijnlijk moet je de applet signen, en dient de gebruiker 1x op JA te klikken. Dan kan je de applet toegang geven tot afdrukfunctionaliteit. Dat is ook de enige functionaliteit waar je toegang voor moet aanvragen. Dit moet je dan waarschijnlijk even uitzoeken hoe op te zetten.

[ Voor 27% gewijzigd door koppie op 06-11-2005 16:40 ]

[Varienaja]

Ik heb een applicatie geschreven in Delphi die luistert op een bepaalde poort. Dit programma kan op commando word-documenten genereren uit (een soort) html. In mijn java-webapplicatie bouw ik dus html op, en stuur dat door naar het Delphi-programma. Dat programma handelt vervolgens de word-specifieke zaken af.

Het fijne is hier dat je nu nog steeds je Java-code op alle platforms kunt draaien.

[misfire]

Het nadeel van pdf's is dat je overal acrobat reader moet installeren en dat extra gebruikershandelingen nodig zijn om de printactie te starten. Dat is niet vriendelijk als de applicatie gebruikt wordt terwijl er iemand zit te wachten op de kaartjes.

[Verwijderd]

ari3 schreef op zondag 06 november 2005 @ 16:37:
[...]

[url=]http://www.foxitsoftware.com/pdf/rd_intro.php]Foxit (PDF) Reader[/url]
Opstarttijd: < 1 seconde

...

Een ander probleem m.b.t. documenten.
Heb nu een probleem dat men via FreeTextBox of een andere WYSIWYG editor brieven kan maken. De tekst wordt in de database opgeslagen. Maar men moet de brief ook in Microsoft word kunnen bewerken. Dus op de server een Word document genereren en als output naar de client sturen.
Maar hoe moet nu het document weer terug naar de server komen? ... Zodat het document, op de server, opgeslagen kan worden. De server staat niet in het intranet.

[Verwijderd]

Ik gebruik in princiepe aantal technieken:

Indien gebruiker flash heeft geef ik document in flash (flashpaper of pdf2swf) formaat...
Indien gebruiker geen flash heeft maar wel PDF, geef ik het weer in pdf
anders geeft ik de keuze tussen een plain text file of een image..

[Bbfreak]

Zoals hierboven wil ik me aansluiten bij de PDF keuze.
Heb vaak PDF documenten in moeten vullen en moeten printen.
Ik vind de seconde opstarttijd van Acrobat Reader verwaarloosbaar.
PDF is ook een gevestigde standaard en volgens mij mag je er wel vanuit gaan dat iedereen het heeft.
Ik weet niet precies wat de eisen van je app zijn natuurlijk.

Toekomst voorspellen vind ik erg moeilijk maar wat MS nu aangekondigd heeft met Live.com
vind ik veel belovend. Dit is dus ook Word documenten aanpassen, printen, opslaan whatever.
Het zal voorlopig een echte desktop applicatie niet vervangen maar een interessante ontwikkeling is het zeker!

[Hydra]

momania schreef op zondag 06 november 2005 @ 16:26:
pdf is toch niet zo zwaar?

Absoluut niet. PDF is weinig meer dan PostScript+. Als je HP printer van 10 jaar terug dat kan renderen, kan elke PC dat. Het enige wat 'zwaar' is, is Adobe reader bij het opstarten.

[-FoX-]

Inderdaad, de PDF's op zich zullen licht tot zeer licht zijn (puur tekst), maar het gaat er mij meer om hoe de gebruiker het ervaart: als log en zwaar dus, aangezien de browser integratie tot voor v7 slécht was/is.

Het probleem ligt er ook in dat er 2 type's van printers aangestuurd dienen te worden. Een normale (A4) en een matrix printertje voor de ticketjes. Indien er PDF's gegenereerd worden en deze naar de gebruiker gestuurd, zal de gebruiker nog altijd zelf de printer moeten kiezen waarmee hij het document af wil drukken. Maar dit is iets waar je sowieso niet onderuit kan komen (denk ik?).

Het nadeel is, dat de gebruiker sowieso verplicht is om al dan niet acrobat/java runtime/activeX/ ... geïnstalleerd/geactiveerd moet hebben om van de software gebruik te kunnen maken.
Daarom ben ik er ook nog niet echt helemaal uit, hoe ik dit op zal lossen.

[MisterData]

Is SVG niet een optie eigenlijk? Ik weet niet hoe het zit met SVG en tekst, maar ik weet wel dat het qua rendertijd in ieder geval meevalt... Daarnaast hebben Firefox en Opera volgens mij al standaard SVG in de nieuwste (bèta) versies Of het goed printbaar is weet ik eerlijkgezegd ook niet...

[Verwijderd]

-FoX- schreef op maandag 07 november 2005 @ 18:53:
Het probleem ligt er ook in dat er 2 type's van printers aangestuurd dienen te worden. Een normale (A4) en een matrix printertje voor de ticketjes. Indien er PDF's gegenereerd worden en deze naar de gebruiker gestuurd, zal de gebruiker nog altijd zelf de printer moeten kiezen waarmee hij het document af wil drukken. Maar dit is iets waar je sowieso niet onderuit kan komen (denk ik?).

Ja kan dmv de Java printing API de windows printerlijst opvragen en een printjob naar een specifieke printer sturen zonder tussenkomst van de gebruiker.
Ik denk dat dit de meest aangewezen methode is... nadeel is dat je zelf zal moeten instaan om de pagina's te "renderen"... Misschien kan je een mix gebruiken van PDF (dmv XSFL-FO?) voor de tekst en het ticket render je zelf en rolt automatisch uit de matrix printer.

[-FoX-]

Verwijderd schreef op dinsdag 08 november 2005 @ 00:05:
Ja kan dmv de Java printing API de windows printerlijst opvragen en een printjob naar een specifieke printer sturen zonder tussenkomst van de gebruiker.
Ik denk dat dit de meest aangewezen methode is... nadeel is dat je zelf zal moeten instaan om de pagina's te "renderen"... Misschien kan je een mix gebruiken van PDF (dmv XSFL-FO?) voor de tekst en het ticket render je zelf en rolt automatisch uit de matrix printer.

Met zelf renderen bedoel je dan via een activeX of een applet?