Reprise du message précédent :
OH MON DIEU JE VOIS LA RUE EN HDR§§§

MAIS POURQUOI ON LAISSE FAIRE DU HDR A N'IMPORTE QUI §§§§§
 
IL DEVRAIT IL Y AVOIR UN PERMIS §§ COMME POUR VOTER OU ETRE PARENT §§§§

Exact
 
Mais tu as le tuning de béthune et celui d'AMG

Harko >
http://forum.hardware.fr/hfr/Photo [...] 6776_1.htm
 
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0

Et quelqu'un a dejà utilisé la fonctionnalité intégrée à iPhoto ? Qui fait le tirage quand on le commande directement dans iPhoto ?

je suis un traine savate

Salut

J'ai pas de Mac. Mais le logiciel Fujifilm permet de faire pas mal de trucs.
Exemple ici: http://forum.hardware.fr/hfr/Photo [...] m#t1479663

J'ai commencé un album hier, ça va vite. Mais je vais le retoucher ce soir avant la commande.

Bon, j'arrive pas à trouver une solution satisfaisante pour modéliser un truc coté base de données.
Mon appli doit permettre aux utilisateurs de créer des ressources, et ensuite de permettre à d'autres personnes de s'identifier pour  y accéder.
Jusqu'ici pas de problème, mais là où je coince c'est qu'à chaque ressource doit pouvoir correspondre un mode d'identification différent, pas forcément connu au moment de la conception du soft.
Par exemple on doit pouvoir à la fois avoir une ressource utilisant une identification SSO, une autre à laquelle on accède via un mot de passe/identifiant personnel diffusé par ailleurs, et une troisième qui permet l'accès à n'importe-qui.  
Vous voyez un moyen propre de stocker les paramètres d'identification pour chaque type d'identification sans les connaitre forcément tous à l'avance?

 
Ben Non.
 
Et je vois pas trop comment cela serait possible.
 
A moins de tout prévoir à l'avance évidemment, mais ca répond plus vraiment à ta question.

Moi non plus, mais comme je suis pas forcément infaillible et que j'ia un forum d'experts sous la main...

Bon, on verra ça plus tard, on va commencer par faire une version qui gère les 3/4 modes d'identification dont je suis sûr d'avoir besoin, pour commencer.

 
Ben ca me semble être un peu la seule solution.

Note que l'objectif c'est pas que l'appli soit capable de gérer des nouveaux modes d'identification à la volée (là ça tiendrait de la magie, vraiment ), hein, mais que je sois pas obligé de retoucher la base de données pour stocker les paramètres qui sont propres à un mode pas prévu à la base...

(ça va finir par une liste de modes d'identification dans la base et un fichier de conf par mode, tout ça...)

au pire tu fais une table de parametrage a la con, genre (ressource, paramName, paramValue)

Moué, j'y ai pensé, mais ça pue le bloatware...
Pour l'instant le plus censé que j'ai trouvé c'est de maintenir une table des modes d'identification, avec l'id qui va bien dans celle des ressources, et tout le rete dans des fichiers de conf.

Quand on commence a prévoir pour des cas hypothétique, on est déjà a fond dans le bloat.
 
 

Ce qui revient donc exactement au même, au moyen de stockage près. Tu peux aussi mettre ton fichier de conf dans un clob

 
Plus ou moins hypothétiques, j'ai au moins 3 cas très différents à gérer, déjà (pas de restriction, plusieurs SSO CAS, mot de passe/identifiant externe)...
 

 
Oui, c'est une idée aussi...moins pratique qu'un bête fichier de conf, mais au moins tout serait dans la base...

 
En Java, ce que je ferais, c'est que je mettrais dans la base un nom de classe d'identification, et un id.
 
Charge à la classe d'identification d'aller chercher les données dont elle a besoin où elle veut, en utilisant l'ID.
 
Chargement de la classe par reflexivité, tout ça, tu peux ajouter des méthodes facilement
 
Et si la classe est pas trouvée, boum, ça pète.
 
 
Mais c'est peut être complètement con, hein, chépas

Je parlais uniquement de la modélisation coté base de données, là.

je crois que la question porte spécifiquement sur la partie en gras.  
pour le reste, un nom de classe ou un nom de type, c'est kif kif.

 
.....mouais. Perso, je vois àça comme un plugin : le système qui l'utilise n'a pas besoin de savoir où et comment sont stockées les données du plugin, ni sa conf. Chaque plugin se démerde : il a une doc, qui explique comment le configurer, mais ça ne concerne pas le système client : il utilise le plugin, point barre.
 

J'avais oublié que j'avais passé tout le weekend avec un tatouage Firefox sur la joue gauche

c'est un geek stamp?

Ouais mais après je dois aussi pouvoir savoir qui a utilisé une ressource...
Grosso merdo l'idée c'est d'avoir une table d'utilisateurs, et de stocker d'une manière ou d'une autre l'identifiant externe correspondant au mode d'identification qu'il utilise.
...oui, c'est le bordel... (surtout dans le cas où on ouvre à tout le monde.)

Je pige pas ton truc...

Les utilisateurs dans ta table, ils sont créés comment? A la mimine?

on ouvre à tout le monde mais on impose pas une migration vers un gros annuaire commun, évidement sinon ça aurait été trop simple

 
Soit les utilisateurs s'inscrivent sur le site (ce sera du ouaibe), soit par d'autres applis - l'appli en question est supposée fournir un service à d'autres applis.
 
Mettons que t'as une appli "toto" qui permet à une utilisateurs de s'inscrire dans un groupe.
Une fois inscrit, "toto" doit pouvoir prévenir mon appli à moi que le type utilisant l'identifiant "machin" avec le mode d'identification "truc" aura accès à telle ressource.
 

 
Mettre en place un annuaire commun c'est pas faisable, il y a même pas forcément un annuaire - quand je dis ouvert à tout le monde, ça peut être des gens qui ne figurent dans aucun SI connu.
D'où la gestion d'utilisateurs en interne, sinon on pourrait déléguer complètement aux systèmes d'identification externes...

(oui, c'est bloaté d'avance.)

http://www.canardpc.com/news-37890 [...] coup_.html

http://encyclopediadramatica.com/Kenny_Glenn

pourquoi pas faire une table users contenant les utilisateurs avec un champ group_id reliant à une table groups content les groupes d'utilisateurs, cette table étant elle même reliée à une table "rights" contenant les droits

parce-que la notion de groupe n'a aucun sens dans ce problème?

parce que tu veux avoir des droits spécifiques aux utilisateurs et pas à des groupes d'utilisateurs ?

 
....ah ouais...
 
Et si tu donnes 3 points d'entrée aux développeurs de plugins d'authentification :
 
1 - une table de config, avec IDdePlugin | CLE | Valeur
 
2 - une table de règles, où ils mettent ce qu'ils veulent.  (ID de règle, id de plugin, clé, valeur)
 
3 - une table de users (ID de plugin, id user qui est utilisé pour accéder à la resource, clé, valeur)
 
Et dans ta table de resources, tu as une règle et un plugin.
 
Quand tu dis "l'appli me prévient que blabla", ça revient à entrer des trucs dans la table de règles.
 
Quand qqun demande une resource, tu chopes ses infos pour ce plugin dans la table 3, tu récupères les infos de la règle dans la table 2, et tu checkes la règle en utilisant la config de la table 1 (tu envoies les infos de la règle et les infos du user à l'appli, qui te répond ok ou ko)
 
Mais bon, je pige peut être encore de travers.
 

Openoffice 3 avec son extension 'PDF Import' http://extensions.services.openoff [...] /pdfimport

Sinon des trucs de barbus, genre PDFEdit
http://www.kdedevelopers.org/node/2654
http://www.kdedevelopers.org/node/2657
http://sourceforge.net/projects/pdfedit/

 
Si j'introduis une notion de groupes j'ai potentiellement autant de groupes que de ressources, ça ne fait que rajouter une couche de merde.
Mon exemple avec des groupes c'est de la gestion interne d'une AUTRE appli, je n'ai pas à connaitre ça dans la mienne...
 

 
C'est une idée - mais finalement les seuls développeurs de plugins c'est nous, donc autant rester simples avec les fichiers de conf.
Et l'id de plugin ne peut pas être dans la table des users, ça concerne d'abord la ressource - un user utilise potentiellement plusieurs modes d'identification en fonction de la ressource.

 
Ah,mais la table des users, c'est pas TA table des users. C'est une table de données additionnelles dont les plugins peuvent avoir besoin. C'est pour permettre de stocker des données relatives à un user dans le cadre de l'authentification par un plugin. Le lien avec tes users à toi est fait par l'id du user utilisé pour accéder à la resource. Ca permet de mapper, ou de stocker le password pour un plugin, ou des trucs comme ça.
 
Evidement, a veut dire que ton plugin doit aussi exposer un service de provisionning de ces données, déclenché par l'ajout d'un user dans la table des users de ton appli.

 
moué, ça pue le bloat cette appli, vraiment.