Eigen audio progje in Java (V2)
- Thread starter Almeros
- Start date
Origineel geplaatst door Meinte37
Iets zal toch ooit 'ns die
out.println( "<table border=\"0\">" );
moeten gaan doen
ja de renderer maar die is generiek
in een nutshell gaat het zo
out.println( "<" );
out.println( component.getTagName() );
out.println( component.getAttributeString() );
out.println( ">" );
out.println( component.getText() );
Object[] childrenArray = component.getChildren().toArray();
for (int i = 0; i < childrenArray.length; i++)
{
IBaseComponent child = (IBaseComponent) childrenArray;
child.render();
}
out.println( "</" );
out.println( component.getTagName() );
out.println( ">" );
Tsja, tags (of Components in jouw framework) bouwen heb ik ook wel 'ns gedaan, dus ik weet hoe het werkt
M'n punt is: dat of JSP maakt eigenlijk geen zak uit. Het zijn allebei manieren om een Web frontend te genereren, elk met hun specifieke voor- en nadelen. Dat jij daar een eigen (niet-J2EE/JSP) framework voor wilt bouwen, prima: da's geheel je eigen keuze. Maar om nou te zeggen dat dat in 1x veel beter werkt...
Origineel geplaatst door Meinte37
Tsja, tags (of Components in jouw framework) bouwen heb ik ook wel 'ns gedaan, dus ik weet hoe het werkt
M'n punt is: dat of JSP maakt eigenlijk geen zak uit. Het zijn allebei manieren om een Web frontend te genereren, elk met hun specifieke voor- en nadelen. Dat jij daar een eigen (niet-J2EE/JSP) framework voor wilt bouwen, prima: da's geheel je eigen keuze. Maar om nou te zeggen dat dat in 1x veel beter werkt...
het werkt voor mij veel beter omdat ik geen OO sematiek verlies op deze manier en ook mijn code refactorable blijft tot in de view laag, jsp's breken waar je bij staat, hoeveel tijd (lees geld) daar al niet mee verloren is gegaan, maar ieder zijn meug hoor, ik ben meer component minded dan page minded
Refactorability is inderdaad een duidelijke issue, hoewel ik dat (in het geval van een veelgebruikte DSL als JSP) vooral een tekortkoming van de IDE's vind: er is geen enkele reden waarom een JSP editor niet zelf kan zien dat er iets gebroken is, maar dat gebeurt nog maar heel mondjesmaat (RAD6.0 deed het althans nog niet zo goed), helaas.
Het hangt er wel vanaf of je (frontend) code nog door iemand onderhouden moet worden, want mainstream technologies zijn er helemaal voor niks. Bovendien is het natuurlijk wel weer voor de zoveelste keer het wiel opnieuw uitvinden; sterker nog: of je (bestaande, bijv. JSF-) components nu via "echte JSP" activeert of gewoon op de ouderwetse servlet-manier, maakt functioneel gezien helemaal niks uit. Maar dan hoef je die component i.i.g. niet zelf te bouwen (en m.n. de Web-container niet).
het is niet te doen voor een editor om compile time uit te vinden waar runtime expressie toe leiden, volledige refactorability in een viewlaag welke geen java is zal dus nooit mogelijk zijn, in mijn optiek
ik heb helaas een wiel moeten bouwen dat er nog niet was maar het was wel leuk en leerzaam, JSF is veel een veels te zwaar en te complex en mijn framework(je) draait natuurlijk op elke webserver die heb ik er niet zelf bijgebouwd
sorry Almeros voor de deze afdwaling
Maar JSP vertaalt ook gewoon naar Java en gezien het bestaan van JDT is het dus prima mogelijk om in de editor precies evenveel informatie tot je beschikking te hebben (i.h.b. reflective info over beans e.d.) als de Webserver op het moment van class loaden. Daarna kan er nog steeds wat misgaan, maar persoonlijk heb ik slechts 1x een compiled JSP hoeven te debuggen en dat was nog met een heel oude versie van de plugins op een tamelijk oude Eclipse.
Leuk en leerzaam, allicht, maar in het kader van onderhoudbaarheid is het nogal de vraag of zo'n keuze je later niet opbreekt. Mijn ervaring met eigen taglibs en dat soort fratsen is dat je veel tijd kwijt bent met het maken van precies dezelfde fouten die ondertussen al uit de bestaande frameworks gehaald zijn. Ooit 'ns een dag bezig geweest met een issue omdat een custom taglib (die we helaas wel moesten gebruiken) Exception-s inslikte en dan geen logmelding gaf, wat nogal lullig is op het moment dat het een Reflection Exception is...
Rvooh
Gepokt en gemazeld
maybe
zal het eens opzoeken zodra ik mijn Scheme boek terugheb
variabelen buiten een methode maken.. is dat niet tegen de java regels?
(en dan denk ik aan die ellendige getters en setter werkwijze die ik zo ontzettend stom vind)
ivm performantie op men G4: ja het werkte wel,
maar ik weet dat mn processor al lastig doet als ik een echo effect gebruik op realtime audio.
ik test het liever eens op men pa zen intel mac
Origineel geplaatst door rvooh
maybe
zal het eens opzoeken zodra ik mijn Scheme boek terugheb
variabelen buiten een methode maken.. is dat niet tegen de java regels?
(en dan denk ik aan die ellendige getters en setter werkwijze die ik zo ontzettend stom vind)
Even het simpelste van het simpelste voorbeeld wat ik kan bedenken (je kunt het zo gek maken als je zelf wilt natuurlijk
) om te laten zien wat ik bedoel.public class RecursieTest()
{
private int teller = 0;
public void recurse(){
teller++;
if(teller < 100)
recurse();
else{
System.out.println("Damn... that was the most useless recursive program I've EVER seen
");}
}
}
Hmmm... ziet er wat onleesbaar uit. Dit forum pakt de spaties aan het begin van een regel niet op...
Hèhè ok... nouja, als je er aan toe komt ben ik zeer benieuwd naar je bevindingen!Origineel geplaatst door rvooh
ivm performantie op men G4: ja het werkte wel,
maar ik weet dat mn processor al lastig doet als ik een echo effect gebruik op realtime audio.
ik test het liever eens op men pa zen intel mac
ik waardeer je bezorgdheid maar ik heb er 5 jaar aan gewerkt en heb inmiddels meerdere professionele (lees geld opleverende) applicaties opgeleverd die retestabiel draaien en zeer onderhoudbaar zijn, ook heb ik er een administratief pakket mee gebouwd waar ik al enige tijd succesvol mijn adminstrtie mee pleeg van uren registratie tot aan de jaarrekening, als ik op locatie met j2ee aan de slag moet ben ik vaak 10 keer zoveel tijd kwijt aan de meest simpele zaken en ga ik elke dag gek van frustratie naar huis, standaarden zijn goed maar niet als ze fout zijn, nu hou ik echt op want het is niet theserverside hier
Rvooh
Gepokt en gemazeld
niet mee inzitten, ik snapt het wel
laat je de intel-mac test zeker weten
laat je de intel-mac test zeker weten
Ah, OK, maar dan ben je er dus wel 5 jaar mee bezig geweest, wat dus gelijk ook wel m'n punt illustreert: goede frameworks bakken kost veel tijd en je moet ze vaak kunnen gebruiken om het die tijd waard te laten zijn.Origineel geplaatst door dennisb
ik waardeer je bezorgdheid maar ik heb er 5 jaar aan gewerkt en heb inmiddels meerdere professionele (lees geld opleverende) applicaties opgeleverd die retestabiel draaien en zeer onderhoudbaar zijn, ook heb ik er een administratief pakket mee gebouwd waar ik al enige tijd succesvol mijn adminstrtie mee pleeg van uren registratie tot aan de jaarrekening, als ik op locatie met j2ee aan de slag moet ben ik vaak 10 keer zoveel tijd kwijt aan de meest simpele zaken en ga ik elke dag gek van frustratie naar huis, standaarden zijn goed maar niet als ze fout zijn, nu hou ik echt op want het is niet theserverside hier
J2EE is trouwens -als begrip/"concept"- ook wel erg breed, dus het is niet zo gek dat je daar gefrustreerd van raakt: het is zelfs de grootste makke aan Java, momenteel, omdat het platform zucht onder zowel de grote hoeveelheid frameworks (in varierende mate van bruikbaarheid en volwassenheid) als de grote behoefte aan "extra"/de facto standaarden, zoals Spring voor IoC en Hibernate voor Persistence. (Zaken als EJB3.0 zijn wat dat betreft een grote sprong voorwaarts, zeker als de JSR definitief is.)
Zelf heb ik op dit moment weinig met J2EE te maken: ik maak modelletjes die gebruikt worden om J2EE-applicaties mee te genereren
De boodschap klopt inderdaad behoorlijkOrigineel geplaatst door Almeros
Even het simpelste van het simpelste voorbeeld wat ik kan bedenken (je kunt het zo gek maken als je zelf wilt natuurlijk
In het algemeen: voor een zinnig recursief algorithme heeft de ruimtecomplexiteit (ofwel: hoeveel ruimte neemt alle data in de loop der tijd in) dezelfde orde van grootte als voor een iteratieve/niet-recursieve variant daarvan. Je hebt in totaal wel meer ruimte nodig, nl. voor elke recursieve call wat ruimte op de stack voor een return address, de parameters en de locale variabelen, maar als dat echte toestand betreft, dan moet je die in een niet-recursieve variant ook ergens opslaan.
Ik vermoed trouwens dat de JVM (of zelfs de compiler al) in jouw geval wel herkend dat het om tail-recursie gaat en de recursie ontrolt
Rvooh
Gepokt en gemazeld
wat ik me vooral herinner hieromtrend is dat je geheugenruimte net kon uitsparen met recursie omdat er geen counter of tussenresultaat moest worden bijgehouden zoals bij iteratief.
wat bedoel je met de "recursie wordt ontrold" door de compiler?
staartrecursie is dan ook niet echt recursie, juist?
// oja excuses dat deze thread in een nerdgesprek eindigt dat niets meer met muziek te maken heeft
wel leerrijk
wat bedoel je met de "recursie wordt ontrold" door de compiler?
staartrecursie is dan ook niet echt recursie, juist?
// oja excuses dat deze thread in een nerdgesprek eindigt dat niets meer met muziek te maken heeft
wel leerrijk
Alle leuk technologische discussies op een stokje, maar hij werkt gewoon op mijn mac. Ik heb dat nog niet eerder gezien zonder hercompileren en uitzoeken van platform afhankelijke dependencies. Ja, met een eenvoudig vb.net formulier onder mono, maar niet zo iets als dit.
Als dat het geval is, is het geen echte recursie. Bij het maken van een recursieve call wordt een return address opgeslagen (op de stack), zodat de JVM weet waarnaartoe hij terug op moet springen op het moment dat de call return'd. Dat kost dus ook geheugen (2x een int, dacht ik: 1x een int voor het method address en 1x een int voor het enclosing object).
Dat de compiler zelf wel ziet dat het geen echte recursie is en er een loopje van maakt met precies hetzelfde gedrag.
Hmmm, wanneer is iets "echt recursie"... Alle recursieve algorithmen kun je ook iteratief uitschrijven (moet ook kunnen, want een JVM moet het uiteindelijk toch sequentieel kunnen uitvoeren en gebruikt daar de stack-methode voor), alleen is dat vaak niet zo leesbaar. Recursie is dus goed bruikbaar om bepaalde problemen kernachtig mee op te lossen, denk aan quick- en merge-sort.
kefkekeyser
Ouwe rot
[nerd mode]Recursieve algorithme kunnen handige zijn bij AI. Ik heb eens in Java een sudoku solver geschreven en dat was een recursief algo, maar ik kwam wel rare errors tegen omdat de stack waar de functie calls opkomen te staan vol was.[/nerd mode]
On topic: nice gedaan, dit java proggie. Ik zou het zelf niet kunnen. Misschien kan je java gebruiken voor je gui en C code voor de dsp processing?
On topic: nice gedaan, dit java proggie. Ik zou het zelf niet kunnen. Misschien kan je java gebruiken voor je gui en C code voor de dsp processing?
