[ALG] X-Platform ontwikkelen ... Suggesties?

[Zeppo]

Hallo,

ffe voorstellen ...
ik ben Zeppo, maker van Offline Rekening Overzicht ([mbr][norml]www.spamvrij.nl[/][/]),
en ik zit te denken aan ver/her nieuwbouw (a la de Biereco's )van mijn programma.

Nu niet meteen naar VS.Net grijpen, maar eerst hier eens navragen wat aardige alternatieven zijn waarmee X-platform ontwikkeld kan worden, en de *x en Mac gebruikers niet default 'vergeten' worden. Zit je dan meteen vast aan Java? Of is bijv. Mono al een serieuze kandidaat? Of andere ontwikkelomgevingen waar ik niet eens van het bestaan weet?

Reacties graag

Zeppo

[ Voor 5% gewijzigd door NMe op 27-04-2005 00:40 ]

[NMe]

Er zijn zoveel verschillende talen/omgevingen die gebruikt kunnen worden voor crossplatform programma's. Het hangt eigenlijk een beetje af van wat je wil gaan doen. Zelf zou ik voor een standalone applicatie snel naar Java grijpen, maar het kan best zijn dat iemand anders meer ziet in Python of een andere taal. Het is behalve persoonlijk dus ook productafhankelijk.

[Zeppo]

Nou,

het is dus vooral een database applicatie, en ik neem aan dat dat de keuze al wat beperkt.., maar waar die db nou moet staan .. in eerste natuurlijk op de localhost, maar een andere vorm is misschien ook een mogelijkheid.
Wat ik maar wil zeggen: toen ik een tijdje geleden begon met deze app was ik nog een complete newbie kwa VB, en zijn een aantal keuzes misschien niet verstandig geweest.
Ik denk nu: wat als ik een tweede kans zou krijgen? (een taal is maar een taal: het meeste werk zit in het bedenken?)
Wat zou voor een db-app een goede keuze zijn?

Z

[NMe]

Zeppo schreef op woensdag 27 april 2005 @ 00:51:
Wat zou voor een db-app een goede keuze zijn?

Wederom hetzelfde verhaal: Wat zijn de eisen? Wat is je persoonlijke voorkeur?

Als je niet vertelt wat de eisen aan je applicatie zijn, dan heeft dit topic weinig zin.

[Johnny]

Databases zijn nog vrij simpel om cross-platform te doen, je kunt ze namelijk op ieder gewoon via een ODBC-bridge benaderen.

[Zeppo]

Tsja,

zoals gezegd..
De huidige applicatie slaat data op in een database, en biedt de gebruiker een gemakkelijke manier om de opgeslagen data te bevragen. Vooral dat laatste (gemak) dient voorop te staan. En daarnaast moet er een (voor de gebruiker) leuke (,want erg veel htk-gebruikers) GUI beschikbaar zijn.

Lange tijd heeft mijn complete ontwikkelomgeving eruit gezien als MultiEdit (MS-DosVersie, want Clipper en de NG's (Shift-F1!) van Clipper) en sinds kort weer het programmeren (met VB) opgepakt met dit project.

Ik ben dus niet bang voor een die-hard, 'text-only' ontwikkelomgeving, maar vraag me alleen af wat een goede omgeving zou zijn. Voorwaarde die ik stel: genoeg openbaar te raadplegen bronnen en fora om problemen voor te leggen, en voor de uiteindelijke gebruiker : minimale fuzz, dus niet: download en installeer eerst xyz, en pas daarna uitbreiding abc, en dan tenslotte mijn eigen leuke brouwseltje.

Met een installatie van een JRE zou nog wel te leven zijn, net als een MS-framework (Mono?)

So......


Z

[djc]

Voor het bijhouden van een lokale database heb je in principe een paar standaard-opties (die cross-platform werken, en vaak gebruikt worden): gewoon werken met een zelfbedacht tekst-formaat, een op XML gebaseerd formaat, of een simpele database engine. Van die laatste is SQLite tegenwoordig vrij populair, maar met name als je met Java ontwikkelt zijn er nog wel een paar andere opties, volgens mij (HSQLDB ofzo?). Maar als je SQLite, tekst- of XML-bestanden gebruikt ben je nog niet beperkt tot een taal.

Het hangt er dus echt vanaf wat je graag wil. Wil je meer of minder object-georienteerd programmeren? Wil je een taal die statisch of dynamisch is getypeerd? Wat voor GUI wil je, neem je genoegen met Swing of wxWidgets of wil je native shizzle? Misschien is het Mozilla-platform wel iets voor jou.

[Alarmnummer]

Manuzhai schreef op woensdag 27 april 2005 @ 01:35:
Voor het bijhouden van een lokale database heb je in principe een paar standaard-opties (die cross-platform werken, en vaak gebruikt worden): gewoon werken met een zelfbedacht tekst-formaat, een op XML gebaseerd formaat, of een simpele database engine. Van die laatste is SQLite tegenwoordig vrij populair, maar met name als je met Java ontwikkelt zijn er nog wel een paar andere opties, volgens mij (HSQLDB ofzo?). Maar als je SQLite, tekst- of XML-bestanden gebruikt ben je nog niet beperkt tot een taal.

Data opslag != Database. Database heeft veel meer te bieden dan alleen dataopslag, oa ondersteunt het ook de ACID eigenschappen en dan is het sowieso uitgesloten om zelf met files te pielen.

Het hangt er dus echt vanaf wat je graag wil. Wil je meer of minder object-georienteerd programmeren? Wil je een taal die statisch of dynamisch is getypeerd? Wat voor GUI wil je, neem je genoegen met Swing of wxWidgets of wil je native shizzle?

Dat zijn denk ik geen vragen die je aan iemand moet stellen die er niet zo in thuis is als jij. Ik denk dat argumenten als kosten, gemak van de taal, goeie omgeving, goeie documentatie veel belangrijker zijn.

Misschien is het Mozilla-platform wel iets voor jou.

Wat niet goed gedocumenteerd is, bestaat niet imho. Er zijn wel wat boeken, maar die vallen in het niet bij een van de weinige volledig crossplatform oplossingen: Java.

De vraag is trouwens of je crossplatform bezig wilt. Niet windows omgevingen zijn maar een fractie van de gebruikers, ik zou me concentreren op de massa en daar mijn tools op afstemmen. Steek geen tijd in een fractie van de mensen (imho). En als vb daarvoor de beste oplossing is, so be it.. Het voordeel aan echte windows omgevingen is dat je er in no time een vet gelikte gui hebt waar iedere java programmeur op loopt te kwijlen. Integratie met bv word of excel is geen probleem (met java is het huilen).

Dus mijn advies: weet zeker voor welke groep mensen je gaat. Wil je de rekening betalen van cross platform, weet dan ook dat je de winst eruit haalt (betaal nooit een rekening zonder de voordelen).
En verder: uit je verhaal maak ik op dat je geen doorgewinterde programmeur bent. Stem hier je tools dan ook op af. Als je met Java aan de slag gaat, en je wilt het op de 'voorgeschreven' manier doen, ben je over 10 jaar nog niet klaar. Ik denk dat je het moet zoeken in de Delphi/VB hoek.

[ Voor 3% gewijzigd door Alarmnummer op 27-04-2005 08:22 ]

[Verwijderd]

Voor een crossplatform tool, zou ik ook in de eerste instantie voor Java gaan. Wat wel opgemerkt moet worden voor Java is dat bijna geen enkel OS de VM nog standaard installeerd. Zo ver ik weet doet alleen Mac OS X dat en natuurlijk de Sun aanbiedingen (Solaris & hun Linux distributie).

Zowel Windows als zo'n beetje elke Linux distributie komen niet met de VM.

Tevens, wat mensen bij Java op de desktop vaak over het hoofd zien is dat er nog andere toolkit libraries zijn dan diegene die Sun meeleverd. Een andere goede toolkit, die je apps een meer native look geven op elk platform en tevens een betere performance hebben, is SWT. -de- voorbeeld applicatie die met deze toolkit is gebouwd is Eclipse. Info over deze toolkit kun je vinden op: http://www.eclipse.org/swt/ . Ik denk dat ik zelf voor deze toolkit zou kiezen als ik voor een cross-platform app zou gaan. De 'richness' factor is iets lager dan Swing, maar het feit dat je met bijna native widgets werkt en de performance winst, maken dat meer dan goed.

In een Java applicatie benader je je DB met JDBC. Je kunt dan makkelijk van DB wisselen, mits je je queries in zo standaard mogelijk SQL schrijft.

Vervolgens moet je nog gaan denken aan je installer. Zeker voor Windows gebruikers kun je eigenlijk niet gaan eisen dat ze zelf de JVM, SWT, en de DB gaan downloaden en installen. Als je een simpele db gebruikt (HSQLDB) dan kun je deze makkelijk meeleveren. Gebruik je een fully features DB (postgreSQL), dan wordt het install verhaal alweer wat ingewikkelder. SWT is gelukkig klein (2MB), maar de JVM is dat niet echt.

[pjvandesande]

Het ligt ook helemaal aan wat je zelf gewent bent. Ik hoor positieve verhalen voor RealBasic, maar ik kan me voorstellen als je zelf niet echt thuis bent in de basic syntax dat de drempel al wat hoger ligt.

Mono is een leuk alternatief, maar ik kan met de keuze voor java ook goed voorstellen.

Je geeft zelf al aan dat je in VB programmeerd, dus welicht is RealBasic een goed alternatief.

[MSalters]

Qt/C++ is crossplatform en heeft geen VM nodig (X-platform native applicaties). Daar staat tegenover dat C++ nou niet in 3 uur te leren is, dat kost je al gauw een week met een goed boek, en Qt is nog eens een week leren.

[djc]

MSalters schreef op woensdag 27 april 2005 @ 12:42:
Qt/C++ is crossplatform en heeft geen VM nodig (X-platform native applicaties). Daar staat tegenover dat C++ nou niet in 3 uur te leren is, dat kost je al gauw een week met een goed boek, en Qt is nog eens een week leren.

Je zou ook bijvoorbeeld PyQT kunnen gebruiken: wel het nut van QT, niet het gezeik van C++.

[dajappie]

En voor een embedded database kan je ook eens kijken naar CloudScape / Derby (http://incubator.apache.org/derby/). Prima in combinatie met Java.

[Alarmnummer]

MSalters schreef op woensdag 27 april 2005 @ 12:42:
Qt/C++ is crossplatform en heeft geen VM nodig (X-platform native applicaties). Daar staat tegenover dat C++ nou niet in 3 uur te leren is, dat kost je al gauw een week met een goed boek,

*Rolt van zijn stoel van het lachen*... goeie grap... of was dat geen grap?

Java is niet zo complex als c++ en dat leer je zeker niet in 1 week. Laat staan zoiets als c++.

[ Voor 12% gewijzigd door Alarmnummer op 27-04-2005 13:45 ]

[farlane]

Alarmnummer schreef op woensdag 27 april 2005 @ 13:45:
[...]

*Rolt van zijn stoel van het lachen*... goeie grap... of was dat geen grap?

Java is niet zo complex als c++ en dat leer je zeker niet in 1 week. Laat staan zoiets als c++.

Is denk alleen de syntax, en dan nog .... ik zou het niet kunnen denk'

[MSalters]

Alarmnummer schreef op woensdag 27 april 2005 @ 13:45:
[...]
*Rolt van zijn stoel van het lachen*... goeie grap... of was dat geen grap?

Java is niet zo complex als c++ en dat leer je zeker niet in 1 week. Laat staan zoiets als c++.

Aangenomen dat je al een andere taal beheerst, aangenomen dat je "Accelerated C++" koopt, en aangenomen dat je met "leren" bedoelt "leren gebruiken", ja.

Alle geemmer wat je met pointers hebt? Weet je dan nauwelijks iets van af. Dat is ook niet erg, als je het uit AC++ hebt geleerd dan gebruik je ze nauwelijks, en al helemaal niet op een manier dat ze kwaad kunnen (dwz buiten classes).

Alle functies van alle classes? Nee. Is ook niet erg, je kunt aan de slag zonder.

[MSalters]

offtopic:
domme server, [500] code en toch stiekem doorgaan

[ Voor 91% gewijzigd door MSalters op 27-04-2005 14:52 ]

[Alarmnummer]

MSalters schreef op woensdag 27 april 2005 @ 14:49:
Aangenomen dat je al een andere taal beheerst, aangenomen dat je "Accelerated C++" koopt, en aangenomen dat je met "leren" bedoelt "leren gebruiken", ja.

Alle functies van alle classes? Nee. Is ook niet erg, je kunt aan de slag zonder.

Ik zou de TS niet de illusie willen geven dat hij in een week tijd serieus met C aan de slag kan met zijn applicatie. c en c++ zijn complex (je kan er ook veel mee) en complexe dingen kosten tijd.

[Verwijderd]

Alarmnummer schreef op woensdag 27 april 2005 @ 14:56:
[...]

Ik zou de TS niet de illusie willen geven dat hij in een week tijd serieus met C aan de slag kan met zijn applicatie. c en c++ zijn complex (je kan er ook veel mee) en complexe dingen kosten tijd.

Een beetje hetzelfde verhaal als de C# programmeur die Java erbij wil doen, of de Objective-c guru die met C++ wil gaan beginnen. Als je opzich al kan programmeren, zeker als je al met de concepten bekent bent (OO, events, iteratief, procedures/functies/methods, etc) dan kun je met een week intensief leren een taal toch wel oppikken hoor.

Grootste gedeelte van de tijd gaat toch in de fijne kneepjes zitten en in het kennen van de libraries, veel minder in de taal.

Als je alleen basic kent, tsja, dan wordt een week wat krapjes...

[Alarmnummer]

Verwijderd schreef op woensdag 27 april 2005 @ 15:51:
[...]


Een beetje hetzelfde verhaal als de C# programmeur die Java erbij wil doen, of de Objective-c guru die met C++ wil gaan beginnen. Als je opzich al kan programmeren, zeker als je al met de concepten bekent bent (OO, events, iteratief, procedures/functies/methods, etc) dan kun je met een week intensief leren een taal toch wel oppikken hoor.

Taal != Syntax.

Een taal (of misschien beter platform) is een IDE (jaja.. hoort er imho echt bij), de syntax, maar ook de libraries, applicatie servers etc.

Grootste gedeelte van de tijd gaat toch in de fijne kneepjes zitten en in het kennen van de libraries, veel minder in de taal.

Precies...

[Verwijderd]

Alarmnummer schreef op woensdag 27 april 2005 @ 15:57:
[...]

Taal != Syntax.

idd. Wel geldt: Syntax => Taal

Het geval is dat een taal iha uit meerdere elementen bestaat:

tokens
syntax
semantiek

[Alarmnummer]

Verwijderd schreef op woensdag 27 april 2005 @ 16:22:
Het geval is dat een taal iha uit meerdere elementen bestaat:

Daar doelde ik niet op.

Ik doel op het feit dat een taal en de daarbij behorende ide`s, libraries, guidelines/blueprints en andere bagage niet gelijk zijn aan de syntax waarin je kan typen. Iedere Java aap kan binnen een week zich goed genoeg redden met .NET (syntax is toch bijna gelijk). Maar dat wil niet zeggen dat hij ook goeie oplossingen voor het .NET platform kan bedenken. Dus weten welke woorden je in moet typen om een compileerbaar programma in te typen is iets anders dan goeie oplossingen bedenken voor dat platform.

[ Voor 3% gewijzigd door Alarmnummer op 27-04-2005 16:44 ]

[D4Skunk]

Ik heb net zelf ff zitten zoeken, en dit lijkt me wel iets.

[BertS]

D4Skunk schreef op donderdag 28 april 2005 @ 10:05:
Ik heb net zelf ff zitten zoeken, en dit lijkt me wel iets.

Een webframework voor Offline Rekening Overzicht??

[D4Skunk]

bee-es schreef op donderdag 28 april 2005 @ 10:18:
[...]

Een webframework voor Offline Rekening Overzicht??

Inderdaad : In ruby zit standaard een webserver ingebakken, en gezien een webapp meestal een lagere instapdrempel heeft, lijkt me dit de ideale aanpak.
Het is trouwens volledig platformonafhankelijk.

Ieder zijn voorkeur natuurlijk, dit is slechts mijn mening

[igmar]

WxWidgets, FLTK, FOX, Java, QT om maar eens wat te noemen. eea is afhankelijk van je eisen pakket, en wat je al wel/niet beheerst.

[BertS]

D4Skunk schreef op donderdag 28 april 2005 @ 10:39:
Inderdaad : In ruby zit standaard een webserver ingebakken, en gezien een webapp meestal een lagere instapdrempel heeft, lijkt me dit de ideale aanpak.

Ok, duidelijk.
Maar om eerlijk te zijn lijkt het mij dan nog steeds geen succes, om een webserver mee te installeren met een dergelijk tooltje, en dat op 'elke willekeurige consumentenpc'

[D4Skunk]

De webserver start natuurlijk enkel op wanneer het scriptje opstart he =)

[Verwijderd]

Het is inderdaad een aanpak waar ik ook over zat te denken. Er is tegenwoordig veel technology beschikbaar voor web applicaties. Veelal zijn dat hele mooie cross-platform dingen die je eigenlijk niet voor desktop programmeer omgevingen hebt.

Een browser heeft iedereen, dus daarmee is de hele grafische kant universeel afgedekt. Het enige stukje wat nog mist in deze puzzel is een manier om een application server op een client te installeren EN er voor zorgen dat je een vrije poort krijgt. Dat laatste is het rottigste. Alhoewel, je kunt er van uit gaan dan 99% van de consumenten voor wie je app is bedoeld niet zelf al een web of application server draaien en diegene die dat wel doen wel weten hoe ze het moeten oplossen.

Ik heb het overigens toch wel wat vaker gezien dat voor de desktop bedoelde applicaties met een eigen webserver komen. Bekend voorbeeld is het help systeem van Eclipse: deze zoekt zelf een eigen vrije poort op.

Je hebt een aantal application servers die zelf ook weer crossplatform zijn. Tomcat is de bekendste maar je hebt ook nog Orion. Beiden draaien zelf op de java vm en dus zonder problemen op elk platform.

[eghie]

Als ik jou was zou ik Mono gebruiken met de taal c#. Zo leer je ook echt met Object Oriëntated Programming (met classes, objecten, etc) werken. De syntax is ook goed te doen en niet echt onduidelijk, alleen even wennen. Voor .NET is een boel aan info te vinden op internet, dus dat is ook geen probleem. En ik denk ook wel dat Mono al ver genoeg is om als serieuse kandidaat mee te doen. Mono gebruikt geloof ik de GTK library, waar veel mensen niet te spreken over zijn, maar hij ondersteund ook al een groot deel van Windows.Forms, dus zou ook native GUI kunnen gebruiken binnen Windows. Ik weet niet hoe het bij de overige OSsen word gedaan.

Je kunt ook Java doen, zoals hierboven ook al veel word gesuggereerd, maar dat is jou keuze. Voordeel van Java is wel dat de GUI native onder elke OS wordt ondersteund.

Voor beiden moet je een soort van VM of Framework installeren.

[Verwijderd]

eghie schreef op vrijdag 29 april 2005 @ 11:54:
Als ik jou was zou ik Mono gebruiken met de taal c#. Zo leer je ook echt met Object Oriëntated Programming (met classes, objecten, etc) werken.

Idd. Mono icm C# is zeker een goede keuze. Alhoewel het mischien nog een klein beetje vroeg is daarvoor. Java (of J2EE als je voor een embedded webserver gaat) is wat langer is gebruik en de VM + libs mischien wat stabieler.

Persoonlijk zou ik Mono nog even een half jaartje laten 'rijpen', maar dat is meer gevoel dan dat ik het echt met feiten kan onderbouwen.

[Alarmnummer]

Gezien java zijn bagger reputatie voor desktop tools en config hel van kleine servers, lijkt me dat een embedded webserver voor java redelijk uitgesloten is. Je kan verder ook niet van een klant verwachten dat hij eerst de service aanslingert en daarna met de browser naar de applicatie gaat.

Denk toch eens na jongens.. stuur iemand niet met een kluitje in het riet onder het mom: ik wou mijn ei kwijt op GoT. Maar geef iemand een echte oplossing.

Voor een echte clientside oplossing zou ik niet gaan voor een of andere webserver of iets in die geest. Gewoon een normale applicatie die normaal werkt. Op het moment dat een standaard tool bij mij gekke dingen wil doen, dan gaat bij mij het alarm af: voor jou 10 anderen.. uninstall.. daaaaggg...

@Ts: Zorg dat je zeker weet of je wel of niet platform onafhankelijk wilt zijn. Als 99% van mijn klantenmarkt windows zou gebruiken dan zou ik geen extra tijd steken in die ene procent. Als je voor een windows applicatie gaat, pak dan VB/Delphi. Gezien je hoeveelheid ervaring lijkt me dit de meest handige opties. Je kan er vet strakke applicaties in maken, integratie met alle office spul is peanuts.. c/c++ en Java zou ik mooi links laten liggen. Moeilijker doen dan nodig is... rekening betalen en er geen voordeel bij halen..

[ Voor 3% gewijzigd door Alarmnummer op 29-04-2005 13:26 ]

[D4Skunk]

Alarmnummer schreef op vrijdag 29 april 2005 @ 13:17:
[...]

Denk toch eens na jongens.. stuur iemand niet met een kluitje in het riet onder het mom: ik wou mijn ei kwijt op GoT. Maar geef iemand een echte oplossing.

Ik raad je nu toch aan ruby on rails eens uit te proberen; het is nl een zeer eenvoudige installprocedure, en niks service etc.. Evalueer eerst, vooraleer je een beoordeling maakt.

@Ts: Zorg dat je zeker weet of je wel of niet platform onafhankelijk wilt zijn. Als 99% van mijn klantenmarkt windows zou gebruiken dan zou ik geen extra tijd steken in die ene procent.
[...]

Bekijk dit eens

[Alarmnummer]

D4Skunk schreef op vrijdag 29 april 2005 @ 13:31:
[...]

Ik raad je nu toch aan ruby on rails eens uit te proberen; het is nl een zeer eenvoudige installprocedure, en niks service etc.. Evalueer eerst, vooraleer je een beoordeling maakt.

Ik heb geen problemen met Ruby on Rails (ben zelf naar Trails aan het kijken). Maar een gebruiker moet niet een of andere gekke server aan de praat slingeren als hij zijn applicatie wil gebruiken, en vervolgens met de browser zijn app benaderen.

Ik kan ook zeggen tegen de gebruiker: Mercedes.. Asus..
allemaal goeie dingen, maar heeft hij ook niets aan..

Bekijk dit eens

Wat moet ik daar aan zien.

[D4Skunk]

Alarmnummer schreef op vrijdag 29 april 2005 @ 13:36:
[...]

Ik heb geen problemen met Ruby on Rails (ben zelf naar Trails aan het kijken). Maar een gebruiker moet niet een of andere gekke server aan de praat slingeren als hij zijn applicatie wil gebruiken, en vervolgens met de browser zijn app benaderen.

Dat is het net met ruby, je hebt geen gekke server nodig. Onder windows is het een simpele clickonce installer. Hoeveel moeilijker kan het worden ? Heb je het uberhaupt al eens geprobeerd alvorens het af te keuren ? Het is niet omdat het veel tijd en/of complexiteit neemt om een java appserver te installen, dat er geen eenvoudige webservertjes bestaan specifiek om enkel de localhost te serven. Probeer vooraleer iets af te breken, dan heeft iedereen er iets aan imho...

Ik kan ook zeggen tegen de gebruiker: Mercedes.. Asus..
allemaal goeie dingen, maar heeft hij ook niets aan..

Wat bedoel je hier mee ?

[...]

Wat moet ik daar aan zien.

Lees het eens, daarvoor dient een link "The long tail" is een zeer gekende term bij ISV's. Ik kan me niet van de indruk ontdoen dat jij niet onder die noemer valt, terwijl de TS dit wel doet... Voor hem kan dit wel degelijk interessant zijn, alhoewel slightly offtopic. Het gaat er hem nl over dat voor ISV's de meerwaarde in de nichemarkt zit, en vandaar dat hij het natuurlijk multiplatform wil houden.
Soms is het beter om eens na te denken over de vraag waarom iemand x of z doet, in plaats van die persoon gewoon af te breken, en te denken dat je zelf de waarheid in pacht hebt.

Maar nu moet ik m'n mond houden, want ik ben zelf aan het zondigen tegen mijn principes

No hard feeelings, ok

[MSalters]

Alarmnummer schreef op woensdag 27 april 2005 @ 16:34:
[...]

Daar doelde ik niet op.

Ik doel op het feit dat een taal en de daarbij behorende ide`s, libraries, guidelines/blueprints en andere bagage niet gelijk zijn aan de syntax waarin je kan typen. Iedere Java aap kan binnen een week zich goed genoeg redden met .NET (syntax is toch bijna gelijk). Maar dat wil niet zeggen dat hij ook goeie oplossingen voor het .NET platform kan bedenken. Dus weten welke woorden je in moet typen om een compileerbaar programma in te typen is iets anders dan goeie oplossingen bedenken voor dat platform.

Hou er rekening mee dat ik ook nog een extra week inboekte voor Qt. En MSVC is als IDE ongetwijfeld beperkter dan Eclipse en Java consorten, maar wat het doet doet het beter (IMO). Refactoring is leuk, Intellisense is nuttiger.

Overigens zijn blueprints e.d. in mijn optiek iets overrated; goede patterns zijn behoorlijk taalonafhankelijk. Het enige relevante is misschien de canonieke implementatie van een pattern leren. Maar gezien de omvang van het project van de TS heeft hij genoeg aan een of twee patterns.

[Alarmnummer]

D4Skunk schreef op vrijdag 29 april 2005 @ 14:09:
[...]
Dat is het net met ruby, je hebt geen gekke server nodig.

Als jij een lokale webapplicatie hebt, dan zul je een server moet draaien punt.

Het is niet omdat het veel tijd en/of complexiteit neemt om een java appserver te installen, dat er geen eenvoudige webservertjes bestaan specifiek om enkel de localhost te serven. Probeer vooraleer iets af te breken, dan heeft iedereen er iets aan imho...

Het is een algemeen bekend feit dat java servers installeren tijd kost (en dat er altijd wel iets mis gaat). Verder is een een server moeten draaien, puur en alleen om via de browser je applicatie te kunnen krijgen imho een slechte oplossing.

[ Voor 3% gewijzigd door Alarmnummer op 29-04-2005 14:45 ]

[Alarmnummer]

MSalters schreef op vrijdag 29 april 2005 @ 14:34:
[...]
Hou er rekening mee dat ik ook nog een extra week inboekte voor Qt.

In een week krijg je zoiets niet onder de knie. Ik ben intussen een redelijk doorgewinterede Swing programmeur en ik ben er wel een paar jaar zoet mee geweest.

En MSVC is als IDE ongetwijfeld beperkter dan Eclipse en Java consorten, maar wat het doet doet het beter (IMO). Refactoring is leuk, Intellisense is nuttiger.

Uhh.. qua edit mogelijkheden zit VS echt nog in de vorige eeuw hoor. Intellisense is al zooooo oud... Trek eens idea naast VS.NET open.. (en ja.. VS.NET heeft ook al paar keer op mijn bak gestaan)

Overigens zijn blueprints e.d. in mijn optiek iets overrated;

Ben ik niet met je eens. Bij blueprints moet beter vermeld staan voor welke sitaties ze geschikt zijn. Iedere situatie is uniek en guidelines moet je daarop afstemen. Dus niet voor ieder probleem dezelfde oplossing, maar er genuanceerder mee omgaan. Maar zo gauw dat er bij staat, vind ik blue prints wel een meerwaarde hebben over patterns. Patterns zijn heel abstract en blueprints zijn een stuk concreter en beslaan een veel groter gebied. Met blueprints kan je developers dus beter helpen in praktische situaties.

[ Voor 7% gewijzigd door Alarmnummer op 29-04-2005 15:07 ]

[Verwijderd]

Alarmnummer schreef op vrijdag 29 april 2005 @ 14:44:
[...]
Als jij een lokale webapplicatie hebt, dan zul je een server moet draaien punt.

Klopt. Maar sommige web servers vereisen eigenlijk -bijna- geen configuratie. Je start ze op en ze draaien. Je hebt dan natuurlijk wel al de configs voor jouw web app aangemaakt, zodat je dat als geheel installeerd. Voor bijvoorbeeld tomcat is dat extreem simpel, alleen een directory aanmaken en daarje spullen in stoppen is voldoende. Orion vereist dan nog een miniscule veranderingen in de config file.

Maar goed. Deze veranderingen heb je al gedaan. Je doet dus alleen een local install van je voorgeconfigureerde server. Vervolgens maak je een heel klein Java desktop appje dat alleen de browser wrapped. In SWT heb je een standaard browser widget, dus die kan je hiervoor gebruiken.

De user start dus alleen een enkel jar filetje op, en deze code start op de achtergrond de (lokale) server op en geeft direct een browser scherm weer.

Dit hele kleine stukje wrapper code zou eigenlijk iets standaards moeten zijn. Ik geef toe dat het voor een beginner (als TS dat is) mischien net even te veel over-the-top is.

Verder is een een server moeten draaien, puur en alleen om via de browser je applicatie te kunnen krijgen imho een slechte oplossing.

Toch heb ik wel meer aps gezien die op deze manier werken.

[flowerp]

Je zou eigenlijk een hele basic voor 'localhost' achtige doeleinde implementatie van J2EE gewoon standaard bij je JRE moeten hebben, inclusief een wat makkelijkere manier om war's gewoon te runnen door bv een dubbelclick in windows.

Als er dan op de achtergrond een vrije poort wordt gezocht en een browser wordt opgestart zodat ik meteen mijn war kan bekijken zou dat toch wel handig zijn. Nog een stap verder is dan een standaard ultra light JDBC compatible DB voor het java platform, waar elke java applicatie zonder al te veel gedoe gebruik van kan maken.

Natuurlijk is die hele zooi dan geen enterprise grade, maar voor desktop gebruik hoeft dat ook niet.

[djc]

Alarmnummer schreef op vrijdag 29 april 2005 @ 14:44:
Als jij een lokale webapplicatie hebt, dan zul je een server moet draaien punt.

Maar je gaat er hier wel heel makkelijk vanuit dat jij uberhaupt doorhebt dat er een servertje achter draait. Misschien zie jij als doorgewinterde ontwikkelaar dat het een web-interface is (en dat er dus iets met een webservertje achterzit), maar je hoeft daar verder helemaal geen last van te hebben. Mijn ervaring ligt dan meer bij Python dan bij Ruby, maar ik neem aan dat ook daar geldt dat een lichtgewicht HTTP-servertje gewoon zit ingebouwd in de standard library, en die kan je heel gemakkelijk gebruiken in je applicatie, zonder dat daar uitgebreide configuratie voor nodig is (misschien alleen de poort waar het ding op draait, maar als je een voldoende obscure poort kiest is dat ws niet eens nodig).

[flowerp]

Manuzhai schreef op zaterdag 30 april 2005 @ 11:40:
(misschien alleen de poort waar het ding op draait, maar als je een voldoende obscure poort kiest is dat ws niet eens nodig).

Ik weet dat het help systeem van Eclipse (al genoemd hier) telkens een andere poort kiest voor de hidden http server. Het zijn altijd vrij obscure nummers.

[MisterData]

Heb je ervaring met XML en HTML? In dat geval zou je zelfs kunnen developen op het Mozilla-platform Je beschrijft je UI in XUL, een XML-dialect, en je code't in JS. Je kunt heel gemakkelijk op het internet met de API's van mozilla. Je app kun je zowel 'in' mozilla/firefox draaien als als een zelfstandige applicatie. Én het werkt op een hoop platforms. Ik gebruik het zelf ook (frontend-applicatie voor een CMS), en ik was best verrast over hoe simpel het allemaal in elkaar steekt Sommige dingen zijn wat slecht gedocumenteerd, dat wel... SQLite werkt volgens mij ook vanuit Mozilla, en anders is een XML-'database' of RDF ook easy

[Alarmnummer]

Manuzhai schreef op zaterdag 30 april 2005 @ 11:40:
[...]
Maar je gaat er hier wel heel makkelijk vanuit dat jij uberhaupt doorhebt dat er een servertje achter draait.

De gebruiker zal het aan moeten zetten en daarom is deze oplossing niet geschikt als standaard applicatie.

Normale gebruikers willen geen gekke dingen... alleen speciale gebruikers die accepteren speciale dingen.

Misschien zie jij als doorgewinterde ontwikkelaar dat het een web-interface is (en dat er dus iets met een webservertje achterzit), maar je hoeft daar verder helemaal geen last van te hebben.

Hij zal het moeten aanzetten. Dat is mijn probleem ermee. En verder vind ik het een onverstandige oplossing omdat je toch een client applicatie hebt, dus ook gebruik wilt maken een echte gui en niet van een webinterface. Integratie met allerlei office meuk is geen probleem met een echte gui, probeer jij maar eens een excel sheet in een webpagina te laden. In dit geval kan je gebruik maken van een rich client, maak er dan ook gebruik van.

[opmerking]
Ik zie dat er weer een typische GoT discussie wordt gevoerd. Iedereen die zegt maar wat.. hee.. ik weet ook een oplossing. Mag ik ook mag ik ook? Niemand denkt na of die oplossing ook praktisch is. Ik heb intussen de TS van genoeg info gezien, en hij moet maar weten wat hij er mee doet. Maar in dit topic reageer ik niet meer, want dit is zinloos.

[ Voor 25% gewijzigd door Alarmnummer op 30-04-2005 13:34 ]

[flowerp]

Alarmnummer schreef op zaterdag 30 april 2005 @ 13:30:
[...]
De gebruiker zal het aan moeten zetten en daarom is deze oplossing niet geschikt als standaard applicatie.

Nee hoor. Jammer dat je niet meer reageerd, maar als ik in Eclipse op help click merk ik helemaal niks van het feit dat het help systeem eigenlijk een ingebouwde webserver is die ongemerkt op de achtergrond draaid.

Integratie met allerlei office meuk is geen probleem met een echte gui,

Ook crossplatform?

Voor sommige dingen zijn standaard desktop widgets 'rijker', maar voor andere dingen is HTML weer 'rijker'. Je hebt overigens ook HTML desktop widgets in velen toolkits. Dat geeft aan dat er ook voor client applicaties toch wel behoefte is aan HTML.

[D4Skunk]

Alarmnummer schreef op zaterdag 30 april 2005 @ 13:30:
[...]

De gebruiker zal het aan moeten zetten en daarom is deze oplossing niet geschikt als standaard applicatie.

Normale gebruikers willen geen gekke dingen... alleen speciale gebruikers die accepteren speciale dingen.


[...]

Hij zal het moeten aanzetten. Dat is mijn probleem ermee.

Er moet niks "aangezet" worden. Dat is het net... Vandaar dat ik je net aanraadde van de zaken eens te bekijken alvorens te roepen tegen iedereen dat dit een slechte oplossing is. Naar mijn -bescheiden- persoonlijke mening, (en die van enkele anderen tesamen met me in dit topic blijkbaar) zou een locale webbased app wel eens een goede oplossing kunnen zijn.

offtopic:
Het valt me trouwens op dat je geen antwoord gegeven hebt op mijn opmerkingen mbt het ISV-gedeelte. Volgens mij ben jij werkzaam in een relatief groot bedrijf, waar er tijd, geld, middelen en vooral noodzaak is voor een gigantisch framework, gezien het type project.

[opmerking]
Ik zie dat er weer een typische GoT discussie wordt gevoerd. Iedereen die zegt maar wat.. hee.. ik weet ook een oplossing. Mag ik ook mag ik ook? Niemand denkt na of die oplossing ook praktisch is.

Alternatieven aangeven aan de TS is 1 ding, maar ik moet eerlijk zeggen dat je op een nogal 'assertieve' *cough* understatement *cough* manier de comments aanpakt van iedereen die niet jouw mening volgt.

Ik heb intussen de TS van genoeg info gezien, en hij moet maar weten wat hij er mee doet. Maar in dit topic reageer ik niet meer, want dit is zinloos.

Ik kon het zelf niet beter omschrijven