Reprise du message précédent :

J'avais pensé à faire

 
Et ensuite t'aurais

 
A priori ça doit fonctionner...

 
Pourquoi ?

j'ai le sentiment de faire faire le boulot au système 2 fois.
 
C'est pas forcément rationnel (because une recherche de balise ça se fait super-vite) mais j'ai en tête un modèle de cycle de vie des pages incompatible avec ce genre de trucs (même si je le fais dans mon système de d'inclusion custom).

C'est mon aversion des systèmes en cascade aussi.

edit: bref, c'est de la merde, et j'insulte tous ceux qui utilisent ça

 
J'imaginais pas produire le code une première fois pour le reparser ensuite pour chercher les balises en fait.
Je pensais plutôt que le réécriveur nanti de toutes les règles nécessaires produisait un monstroparseur (à garder dans un coin, il doit pas être gratuit à générer lui...) qui à chaque balises teste quels Rewriters s'appliquent à la balise qu'il vient de parser et juste avant de balancer ça au client fait passer ça au onMatch qui vont bien *. Avec un parseur par défaut qui renvoie les données telles quelles.
(décrit comme ça j'ai un peu l'impression de decrire bison en fait )
 
Ou alors c'est ptêtre à autre chose que tu pensais en disant "faire faire le boulot 2 fois" ?
 
* La pluralité sur un match c'est peut-être pas la meilleure idée qui existe vu qu'elle implique de décider d'un ordre d'application des onMatch en fait... Ah et ça serait pas une mauvaise idée de limiter à un subset d'xpath ne contenant pas les siblings (comme les css IE6 quoi) sinon ça deviens plus que compliqué de savoir ce qui matche effectivement si on connait pas encore la suite du code...

bof, pour l'instant, ça me va ce que j'ai fait, la balise url, je vais lui faire générer la réécriture s'il le faut. J'ai pas l'impression que ce soit un enjeu de modifier ça en fait (à part l'esthétique de la balise emboitée moche).

ah fait chié... parce que c'est vraiment cette partie où je vois pas trop où aller/faire.

Dans les softs que j'ai essayé, vu, etc. la plupart utilisé une police de caractère pour afficher les notes. Le problème, c'est que quand tu zoom, les variations de la typo ne suivent pas forcement (genre des problèmes de hauteurs entre les notes, ou des lignes super fines & des notes enormes...), genre PowerTab et/ou abc4j ou sinon, genre sur DGuitar et TuxGuitar, c'est des bitmaps, et je trouve ça vraiment très moche.

Je suis parti sur une solution à base de SVG mais je sais pas si c'est une bonne idée. Je maitrise mal, j'ai du mal a voir ce qui est gérable avec, niveau perf et tout et tout...(J'utilise Batik).

Il y a pas des endroits où je pourrais trouver des infos de l'aide ou quoi que ce soit ?

'a marche ?

Tain ouais, si <s:> a un attribut var, normalement ça fonctionne

bon, en plus je retrouve plus ce que j'avais fait, j'ai du le bazarder

\o/ http://francois.chastanet.free.fr/ [...] queXML.htm
Je sens que je vais me bouffer un peu de conversion C++ -> Java  

Bonjour,
 
Ma question ne vaut pas un topic dédié, je veux juste savoir si je m'y prends comme un manche ou si il n'y a pas de solution à mon problème.
 
Je suis sur le codage d'une librairie, et j'aimerais que les exceptions levées dans son code soient traitées en dehors de celle-ci. En gros, toutes mes exceptions throwent une MaLibException.
 
Le soucis, c'est que l'une des classes (disons Foo) implémente une interface (Bar pour être original), et l'une des méthodes de Bar que j'implémente doit thrower ladite exception... ce qui n'est évidemment pas le cas dans sa signature.
 
Pour résumer :
 

public class Foo implements Bar {
    public void barMethod() throws MaLibException {
        // Sauf que le throws jette évidemment une erreur...
    }
}

 
Problème de design ou impasse ?
 
Merci d'avance

public class Foo implements Bar {
    public void barMethod() throws MaLibException {
        // Sauf que le throws jette évidemment une erreur...
    }
}

 
bah ton interface Bar doit avoir la signature de cette méthode barMethod qui throws cette exception  
 
edit : en fait ton post est incomphréensible  

C'est vrai, il manque une info de taille : l'interface Bar est d'une lib extérieure, donc je ne peut pas toucher à la signature et évidemment, celle-ci ne contient pas la clause throws qui m'intéresse.
 
Edit : quota

Ben donc tu mets pas le throws

Si tu étends de java.lang.RuntimeException tu n'as pas besoin de spécifier de throw dans ta signature il me semble.

étrange j'ai jamais rencontré ce problème avec l'interface

c'est en général pas recommandé d'étendre runtime http://www.javaworld.com/javaworld [...] ional.html

les méthodes de sa lib réclameront toujours que ses exeptions soient catchées ou throwées (attrapées ou lancées )

(il me semble)

 
Précisément
Du coup, j'en fait quoi (le DTC est totalement exclu en milieu professionel, du moins hors négociations salariales) ? Ma question portait plus du point de vue design du code, vu que j'ai pas envie de traiter l'exception dans le code de la lib mais bien dans le code qui l'appelle.
 

L'exception est checked ou pas?
 
Si elle est pas checked, ben tu t'en branles, tu mets pas le throws et baste.
 
Si elle l'est, ben faut la catcher et la wrapper dans une RuntimeException

de toutes façons au niveau design les méthodes qui éxecuteront la méthode barMethode par exemple seront celles d'un framework, l'object et la méthode doit forcément avoir des limites de spécifications c'est l'interet des interfaces, et il n'aura aucun moyen de catcher ton MaLibException, donc au mieux tu la catches pour qu'elle remonte pas, ou tu la renvoie en runtime exeption, mais le processus appelant s'en relevera pas, sauf si il un prévu de récupérer les runtime exeption, mais ils conseillent plutot de les faire remonter tout en haut.

Si ton cas de figure ne correspond pas à ça, alors peut être que tu t'embêtes pour rien à vouloir que ton objet implemente Bar.

Yep, va pour le wrapping.
Merci à vous deux

url n'admet pas l'attribut var.

Et le c:set ?

pas testé, parce qu'il utilise aussi une balise dans une balise.

Ptin mais elle est complètement débile l'api Pattern/Matcher de Java

pkoi ?
 
elle est Thread-safe en tout cas (j'ai été voir).

Ben c'est le fait que Pattern ne serve qu'à générer des Matchers, et ensuite seulement t'as le droit d'appeler des méthodes bizarres qui modifient le Matcher récupéré

Je trouve l'API python largement plus logique (tu crées un Pattern, et ce pattern a des méthodes de matching qui renvoient un objet Match), elle évite de passer par des objets mutables (qui pètent de manière bizarre et pas vraiment claire quand t'as oublié que ouais quand t'as créé ton Matcher faut penser à appeler #matches, #lookingAt ou #find dessus ) et en bonus tu te retrouvent pas avec des méthodes genre groupCount dont je vois absolument pas l'intérêt (Matcher#groupCount ne renvoie pas le nombre de groupes matchés mais le nombre de groupes capturant dans le Pattern du Matcher, comme si tu pouvais pas les compter tout seul comme un grand)

ouais, effectivement.  
 
moi j'utilise ça comme ça :

 
donc j'utilise le comptage des groupes auto.

J'vais buter les mecs qui ont créé cette API débile

• il y a bien une méthode Pattern#matches, sauf qu'elle sert juste à récupérer un booléen pour savoir si une regexp matche bien sur un string, on peut pas chopper les matchgroups derrière (btw elle est statique, donc si tu as besoin de tester plusieurs chaînes tu perds toute l'optimisation liée à la précompilation des regexps)
• Il y a une jolie méthod Pattern#split qui fait ce qu'on en attend (c'est à dire qu'elle split le string fourni autour des matches du pattern), parfaitement logique si ce n'était que aucune autre opération de match n'est dans Pattern
• Comme déjà mentionné, un objet Matcher est mutable. Et n'est pas thread safe ()
• Faut appeler Matcher#matches, Matcher#find ou Matcher#lookingAt pour effectivement matcher, on notera qu'il n'y a pas de Matcher#split, puisque cette méthode est sur le Pattern Et ils renvoient un putain de booléen qu'il faut checker
• La doc de Matcher#group(int) indique que ça returns the input subsequence captured by the given group during the previous match operation. Ce qu'ils ont oublié d'indiquer, c'est que le group(0) c'est pas un match group, c'est l'intégralité du match, les matchgroups commencent à 1 et Matcher.group(0) correspond en fait à Matcher#group() (ça me gènerait pas si c'était indiqué dans la doc )
• Comme déjà mentionné, Matcher#groupCount ne sert à rien, ça ne fait que dumper le groupe de matchgroups dans le pattern original, ça ne donne pas le nombre de groupes ayant matché. D'ailleurs on peut l'appeler n'importe quand, pas besoin d'avoir appelé e.g. Matcher#matches pour que ça tourne
• #split est sur Pattern, mais pas #replaceFirst et #replaceAll... c'est d'une logique
• On peut récupérer son pattern originel, donc pour faire un split via un Matcher faut écrire matcher.pattern().split(string)

Et en bonus, apparement tout ce truc est apparu dans Java 1.4. Franchement avoir attendu 1.4 pour une daube pareille...

On sent que l'élection du nerd 2008 approche, ça sort les grandes tirades techniques sur les API  

mask > un Matcher est déjà bound sur la string, donc il n'a plus de raison de changer de thread. c'est la méthode pour transformer un pattern en matcher qui est protégée.

On peut le rebinder sur un autre string \o/

Ca transforme rien du tout, ça extrait un matcher du pattern

Et ya rien à protéger vu que les instances de Pattern sont immutables

bon les experts, j'ai une question de merde, sur une techno de merde
j'ai un beau Filter, qui me set mon contentType comme je veux. nickel.
un peu plus loin, je forward la request a une daubasse de jsp, et mon contentType est dès lors setté a text/html alors que y'a rien dans ma jsp. wtf ?

Salut, tu ne dois rien faire dans ta JSP, sinon, ca passe en text/html et pouf!
Tu peux passer par une Servlet, c efficace et précis! @+

bon alors, euh ...
 

tu peux pas forcer le content type sur la output stream dans une JSP ?

ben si mais justement, si j'ai un filtre qui le fait pour moi en amont, c'est pas pour aller hardcoder le machin dans ma jsp qui en l'occurence n'a pas la moindre foutue idée de ce qu'elle va cracher comme contenu...

Va voir ici, tu verras ...
J'ai perdu un temps fou avec ces JSP, pour la même chose que toi.
Maintenant, j'utilises une Servlet :
- C plus simple
- Je choisi le type mime que je veux
- Je donne la taille du contenu avant l'envoi : ca évite le double chargement par certains navigateurs
Défaut :  
- si j'ai une il faut une Servlet
 
Enfin, une dernière solution est de générer le fichier sur le serveur,
de proposer un lien avec la bonne extension, et HTTP va faire le reste (et peut-être le double chargement !)...
 
Vous en pensez quoi???

Oups!!! Voici un lien :
http://www.commentcamarche.net/for [...] xml-et-jsp
Dsl

non mais c'est gentil, mais j'ai pas le choix, j'output mon contenu depuis une jsp.
et mon contentType est setté correctement avant la jsp par un filtre, disais-je.
et la jsp est pas au courant du contentType de ce qu'elle output.
(enfin si il faut, elle pourrait, mais ça serait con, vu que le filtre peut le deviner)

Pour terminer, si tu as bien lu le lien que je t'ai fourni,c'est possible de faire ce que tu veux!
Seulement, il y a des conf par défauts, et ta JSP doit commencer par
<%
// Ton code
%>
Il ne faut rien au début du fichier...
 
J'ai fini par réussir à envoyer un fichier en JSP, mais ct trop tard...
J'avais déjà implémenté ma Servlet d'envoi de fichier générique,
et depuis, je l'utilises dans divers projets !