Salut ! Je poste pour vous signaler l'arrivée d'un CMF open source développé par moi même
Les 2 concept :
1 - Développer uniquement la partie logique/métier et laisser le framework + jQuery + jQueryUI générer les formulaires AJAX et la partie SQL automatiquement.
2 - Développer rapidement si on est pressé, tout en gardant la main sur la totalité du code (pas de langage de templating ou de trucs bizzares) .

Bref, c'est du 100% fonctionnel, il a déjà été utilisé sur des sites et j'aimerai le proposer à la communauté pour l'améliorer

Site : http://ufm.erraprod.com/

J'attend vos feedbacks

Si je comprends bien c'est un mixte entre un framework et un CMS ?

Oui, c'est un peu mix entre les 2 mais ça reste plus proche du framework.
Il est toujours destiné aux développeurs mais il y a énormément de fonctions faites pour faciliter la conception du site, notamment la création automatique des formulaires en ajax à partir des objets, une zone admin, qui évoluera dans le futur et qui te permet pour l'instant de traduire directement les contenus, créer des pages et des vues.
A terme, j'aimerai que les 3/4 de la conception d'un site ou d'une application passe par du visuel (créer des objets avec du wysiwyg, créer les templates avec du wysiwyg, etc...) pour limiter le coding obligatoire aux controlleurs (seuls comportements qu'on ne peut pas vraiment automatiser).

Salut,,
je vais rester limité dans mes commentaires. Je n'ai pas récupéré l'archive pour jeter un coup d'oeil dans le code, je me suis limité au site. Le point qui a attiré mon attention en particulier était le fait qu'on ait pas besoin d'écrire la moindre ligne en SQL. J'ai donc supposé la présence d'un ORM, Mais rien sur le site n'indique de quoi il est question.

Ici, on est sur PHPFrance, un site fréquenté par des développeurs essentiellement. Je fais partie de cette catégorie et un des éléments susceptible de retenir mon attention est le fait qu'on me présente une manière d'écrire moins de code pour le même résultat. Or là, je n'ai eu droit à rien du tout en matière d'information détaillée.

Mon premier (et probablement unique) conseil sera donc : pour intéresser le public cible, il convient de lui donner les informations qu'il s'attend à trouver. S'il s'agit d'un public de développeurs, il serait opportun de lui exposer des informations techniques claires.
Or là, on a un laïus, intéressant certes mais, assez insipide coté technique. Si tu veux intéresser le monde du développement en PHP et attirer une communauté susceptible de t'accompagner dans la suite du développement de ton outil, peut-être qu'il faudrait lui donner autre chose que de vagues généralités sur le projet

C'est « encore un autre framework » mais il peut éventuellement valoir la peine qu'on s'y intéresse : as-tu vraiment envie de le voir se développer ? Ces idées qui t'ont amené à le développer, crois-tu vraiment que d'autres seraient prêts à en adopter la philosophie pour s'y intégrer et y apporter leur propre expertise pour le faire évoluer vers quelque chose de vraiment intéressant pour un très grand nombre de développeurs ?

Merci Cyrano pour le conseil, je vais voir comment je peux présenter l'information pour la rendre intéressante. Je pense vraiment que ce framework peut apporter un gros gain de productivité dans les projets de petite et moyenne dimension. En ce moment je retravaille certaines parties du noyau du projet car j'ai eu des remarques à ce niveau là.

En fait, je propose ce framework parce que j'ai pu développer assez rapidement des sites pour mes clients (par ex http://freeloue.com) et je voulais faire croquer la communauté car le framework est basé sur une philosophie qui n'existe pas ailleurs (c'est pas celle de cakePhp ou symfony en tout cas). Un des gros principes c'est l'automatisation des opération de CRUD et de gestion de formulaires. Reste à trouver la meilleure formule pour montrer qu'effectivement ça fait gagner du temps sans faire perdre la main sur le code.

Enfin bref, vous aurez de mes nouvelles assez vite

[...] car le framework est basé sur une philosophie qui n'existe pas ailleurs (c'est pas celle de cakePhp ou symfony en tout cas). Un des gros principes c'est l'automatisation des opération de CRUD et de gestion de formulaires.

Je n'ai actuellement pas le temps d'étudier ton travail, je ne ferais donc pas de retour dessus, mais la phrase ci dessus me choque beaucoup.

Symfony dispose de task de génération CRUD (dépend de l'ORM) et d'un sous-framework de formulaire complet.

Symfony dispose de task de génération CRUD (dépend de l'ORM) et d'un sous-framework de formulaire complet.

Je crois que c'est assez symptomatique en matière de frameworks en général. Ça souligne un point important pour n'importe quel développement un peu avancé. Les deux points les plus importants lors du développement d'une application sont l'accès aux données et la gestion des formulaires. Les solutions proposées ne sont pas toujours très heureuses.

D'une certaine manière, je suis tenté de croire que ce sont précisément ces points qui ont déclenché les réactions sur ce sujet parce que même avec de l'artillerie lourde comme Symfony ou le ZF, l'utilisation de ces éléments n'est pas obligatoirement simple pour tout le monde. À cet égard, je peux ajouter que pour le développement en cours que j'effectue dans l'entreprise où je travaille, j'ai écarté ces deux frameworks précisément à cause de ça et j'ai implémenté mes propres solutions qui m'ont semblé plus rationnelles et moins compliquées par rapport à mon besoin spécifique.

Mais ça ne fait en fin de compte qu'illustrer davantage cette nécessité d'être plus clair et précis dans un projet qu'on veut présenter à une communauté de développement.

le framework est basé sur une philosophie qui n'existe pas ailleurs

Soit, je suis tout à fait disposé à l'admettre, mais présenté de cette manière, ça reste une généralité qui n'apporte rien aux développeurs parce que ce qui pourrait nous intéresser bien davantage, ce serait justement la description de cette philosophie. Par analogie, c'est un peu comme si je disais que tel outil existe sans autres explication : bon, ok, et alors ? Mais si je dis qu'il existe et que j'explique de quoi il est question, quel est le but recherché, à quoi il sert, là j'ai de bonnes chances d'éveiller un peu plus que la simple curiosité de ceux qui sont à l'affut de ce type de solution.

D'une certaine manière, je suis tenté de croire que ce sont précisément ces points qui ont déclenché les réactions sur ce sujet parce que même avec de l'artillerie lourde comme Symfony ou le ZF, l'utilisation de ces éléments n'est pas obligatoirement simple pour tout le monde. À cet égard, je peux ajouter que pour le développement en cours que j'effectue dans l'entreprise où je travaille, j'ai écarté ces deux frameworks précisément à cause de ça et j'ai implémenté mes propres solutions qui m'ont semblé plus rationnelles et moins compliquées par rapport à mon besoin spécifique.

Je comprend ton point de vue et je le partage sur la complexité, mais à chaque fois que j'ai tenté une approche qui soit suffisamment extensible et puissante, je suis tombé sur une solution complexe

Au final, on en reviens à l'éternel "simple mais limité" vs "complexe, mais extensible".

Au final, on en reviens à l'éternel "simple mais limité" vs "complexe, mais extensible".

C'est bien pour ça que j'ai mentionné une solution adaptée au besoin spécifique. La difficulté des concepteurs de frameworks est qu'ils doivent produire quelque chose qui soit très générique, d'où ce problème de complexité.

Pour reprendre rapidement le commentaire de zeus, je n'ai pas dit que symfony ou zend ne permettaient pas de faire des formulaires ou générer le crud, je sais qu'ils le font, ce que ces points sont le concept central de mon framework.

Les deux points les plus importants lors du développement d'une application sont l'accès aux données et la gestion des formulaires.

: 100% d'accord. J'ajouterai même que ce sont les deux points les plus redondants.

Quand je parle de nouveau concept Cyrano, en effet je dois faire un effort pour préciser. Déjà sur la terminologie j'aurai plutôt du dire framework web, vu que jQuery et jQueryUI font presque partie du noyau.

Je vais essayer d'expliquer la philosophie qui m'a amené à rechercher, puis développer et enfin proposer un tel framework (car je pense pas être le seul à penser comme ça)
1 - j'ai un site ou une application web à réaliser et je veux le faire le plus vite que possible et écrire un code facilement réutilisable
2 - je ne veux pas configurer quoi que ce soit, sauf l'accès à ma base de données
3 - je veux un framework avec une courbe d'apprentissage rapide, avec peu de nouveaux concepts et pas de nouveau langage à apprendre
4 - je veux que la partie rendu soit séparée de la logique métier, mais je ne veux pas apprendre de nouveau langage comme smarty
5 - je ne veux pas avoir à écrire la partie administration, ni la générer mais je veux que le client final puisse changer le contenu de manière rapide, intuitive, avec de l'AJAX et un bel UI.
6 - je ne veux être obligé d'écrire du SQL, mais je veux garder la possibilité de le faire
7 - je veux peu de contraintes sur ma manière de coder, mais je veux que le code reste un minimum organisé
8 - aussi vrai que l'iphone à une application pour tout, le framework doit avoir un module pour tout. Je veux insérer une video youtube en faisant <youtube video_id="<?=$video_id?>" width="300" height="200"/>, et je veux utiliser Zend quand c'est possible plutôt que d'avoir à coder des comportements qui existent déja

Et pour expliquer rapidement comment j'ai tenté de répondre aux problématiques
1 - Ce point est un peu la synthèse de tous les autres ^^
2 - Juste une web install avec une page de config à la base de données (host/root/user/db_name), tout le reste est généré à la volée
3 - Le framework n'utilise que PHP et javascript, le seul concept nouveau est celui des objets (au sens du framework)
4 - Un peu à la codeigniter, les templates s'écrivent en html brut avec quelques balises spéciales (ex <include src="mon_autre_fichier.tpl.php"> pour inclure un fichier), et support interne des short tags php <?=$ma_variable?>.
5 - Les objets permettent, juste en décrivant le type de données que tu veux dans ton objet ex bloc_contenu(text=>id=mon_champ_text, image=>id=mon_image, wysiwyg=>id=mon_paragraphe) et la table (bloc_table) ou ils vont être enregistrés de créér un objet qui va te permettre en une méthode un formulaire jQueryUI/ajax qui va sauvegarder les données dans la base au bon endroit, et même de faire de l'edit in place (popup ajax avec formulaire jqueryui qui s'ouvre lorsque tu cliques sur la zone de rendu de ton objet).
6 - via les objets, le CRUD général est automatisé mais on peut quand même accéder facilement aux données mais je vais pas rentrer dans détail, car mon post sent déja le paté
7 - Juste 4 dossiers 'obligatoires' avec application/objects, application/controllers, application/views et application/templates, pour le reste c'est plus ou moins freestyle.
8 - C'est en cours, le framework Zend peut s’intégrer, et l’interpréteur de template permet déjà d'analyser les balises, reste à trouver un nice way pour créer des modules.

La vrai valeur ajoutée je pense que ce sont les objets. Tu décris ta structure de données et aussitôt tu peux générer un formulaire wysiwyg/ajax/jqueryui/multilang listé ou non, faire du CRUD, tout en gardant la possibilité d'accès avec $mon_objet->mon_id->value;

J'accroche sur les points 1, 5, 6 et 8.

Sur le point 1, il me semble qu'il y a mélange des genres : le code réutilisable, c'est le code générique du framework, ce qui est logique. Le code de l'application, c'est le code métier qui est spécifique à cette application, donc beaucoup moins réutilisable ce qui est tout aussi logique.

Sur le point 5, vouloir s'affranchir de la partie back-office d'une application web, c'est pour moi une curiosité, ou alors un problème de terminologie et nous n'avons peut-être pas la même définition de ce qu'est la partie administrative, mais pour ma part, je considère qu'elle est indépendante du front-office et a un accès strictement restreint. Par ailleurs, je ne vois pas où est le problème qu'il y a à créer un back-office, en fin de compte, ce sont des pages comme celle du front-office, avec simplement moins d'accès. Quant à l'AJAX, pourquoi pas, tant qu'on peut le débarquer si nécessaire sans que ça désactive les fonctionnalités, question d'accessibilité.

Sur le point 6, j'ai toujours la même question : est-ce que ton système s'appuie sur un ORM ? Si oui, lequel, Doctrine, Propel ou une solution maison ? Par comparaison, la solution que j'ai développé pour mon propre usage me permet de n'écrire aucune requête en écriture (CUD) mais je dois écrire la plupart de mes requêtes en lecture (R), j'ai donc une moitié du système que tu sembles présenter, mais largement moins lourd qu'un ORM.

Enfin, le point 8, ça me laisse perplexe. Un module pour tout, ça me fait bien davantage penser à un CMS qu'à un framework : donc là encore, peut-être un problème de terminologie sur la signification du terme « framework » ? Et dans ce cas, à quelle définition répond UFM, ça éclairerait sans doute l'interprétation qu'on peut faire du point 1 ?

Par réusabilité du code, j'entends l'exemple suivant. Par exemple sur un site, tu dois développer un blog. Tu créé la gestion des posts, la pagination par URL, la gestion des commentaires. Deux mois plus tard, un nouveau client te demande un blog. Avec UFM, tu peux copier/coller la classe objet et les contrôleurs de ton premier blog et les adapter à ta nouvelle demande. En gros, j'ai essayé de trouver une structure de développement qui te permet de scinder ton code métier dans des compartiments (objets) pour faciliter leur réutilisation. Bien sur si t'as trop d'interdépendances dans ton code çà marchera pas, mais dans certains cas ça peut faire économiser quelques heures

Sur le point 5 je suis peut-être allé vite en besogne. Je n'ai rien contre les back-offices (il y en a un nativement dans le framework), ce que j'aime pas en revanche, dans le cadre de la création de sites webs, c'est créer un back-office pour faire du CRUD sur le contenu. Je veux juste avoir à dire quelle structure à le contenu et comment il doit s'afficher, son édition doit être automatique, c'est dans ce sens que je dis que je veux pas écrire la partie administration. Dans nombre d'autres cas un back-office est obligatoire.

Oui il s'appuie sur un ORM fait maison et qui permet de n'écrire aucune requête en CRUD. Tout se fait de manière complétement transparente à partir du nom des classes et des id des objets pour le nom des colonnes, avec des structures réflexives et récurrentes le tout saupoudré avec un peu d'automagic pour rendre l'ensemble developer-friendly (ça se dit ? ^=^). Le principe c'est de considérer que toute structure de données dans une application peut-être représenté par un objet ou une liste, pouvant eux même contenir des objets (récursion) ou des listes pouvant êtres composés de certains types de base (les fields : champ texte, textarea, wysiwyg, image, combobox, etc...). Un couplage très fort est fait entre les fields, les formulaires et certaines classes d'accès à la BDD, ce qui permet de rendre tout le CRUD transparent. Le plus dur à été de générer automatiquement des formulaires jqueryui cohérents à partir d'objets en entrée qui peuvent avoir n'importe quelle structure avec plusieurs niveaux de complexité

CMS oui, mais dans l'esprit de pouvoir apporter des briques supplémentaires pour effectuer certaines tâches (ex: tu veux une vidéo youtube ? hop <youtube>), mais pas CMS dans le sens ou je me vois pas créer une interface admin à la drupal pour tout gérer. Après sur la définition, moi même j'en sais rien, je pensais que je faisais un framework php mais apparemment non. C'est une sorte de bâtard entre un framework web et un content management framework.

Il y a un problème sur les pages ufm.erraprod.com, j'obtiens ceci :

La page n'est pas redirigée correctement
Firefox a détecté que le serveur redirige la demande pour cette adresse d'une manière qui n'aboutira pas.

Donc malheureusement pas moyen d'accéder au download.

Sinon, à ta réponse, il s'avère que c'est effectivement un problème de définition et on a donc pas affaire à un framework de la même manière qu'on l'entend pour le ZF, Symfony ou Hoa par exemple puisque, si je comprend bien, tu y as ajouté les éléments de base d'un site complet, et on a juste à utiliser tel ou tel module déjà prêt à l'emploi pour construire le site qu'on veut, mais au fond c'est comme pour n'importe quel CMS à cette différence près que tu as une approche différente sur la manière de gérer le contenu. mais ce qui me semble clair, c'est que l'absence de Back-Office pour gérer le contenu limite donc l'ensemble à certaines catégories de sites. On est donc pas face à un framework au sens premier parce que ces derniers sont suffisamment génériques pour la construction de n'importe quel type d'application web.

Enfin bon, je me trompe peut-être, je vais attendre que tu répares les liens, je récupèrerai l'archive histoire d'y jeter un coup d’œil, certains éléments m'intriguent...

C'est résolu pour le download, un mauvais upload d'htaccess.

tu y as ajouté les éléments de base d'un site complet, et on a juste à utiliser tel ou tel module déjà prêt à l'emploi pour construire le site qu'on veut

En gros c'est l'approche que je vise, même j'en suis très loin. Avec le framework tel quel, tu peux prendre n'importe quel template pour en faire un site vitrine, l'édition du contenu se fera evec l'edit-in-place. Pour faire une application, les objets du framework t'aideront dans le CRUD, à toi de gérer ta logique métier.
Maintenant pour les modules je cherche une méthodologie (la plus simple) qui permettrait de créer un module utilisateur, un module blog, un module googlemaps ou un module forum avec le même flow. Bref c'est pas pour tout suite.
J'ai dans l'idée qu'on peut utiliser un CMS sans savoir programmer. Le truc c'est qu'avec UFM il faut savoir développer. Il y a un back-office qui facilite la vie (notamment pour l'assignation des vues, zones, url et les traductions), mais si en amont tu sais pas créer des vues et écrire ben t'es cuit.

Si tu as le temps de parcourir rapidement les pages http://ufm.erraprod.com/fr/tutorials/framework_objects/ et http://ufm.erraprod.com/fr/tutorials/simple_objects/. J'ai essayé de décrire au mieux les objets, même si le tout manque encore de consistance

...
5 - je ne veux pas avoir à écrire la partie administration, ni la générer mais je veux que le client final puisse changer le contenu de manière rapide, intuitive, avec de l'AJAX et un bel UI.
6 - je ne veux être obligé d'écrire du SQL, mais je veux garder la possibilité de le faire
...
3 - Le framework n'utilise que PHP et javascript,
...

et c'est un peu la critique que je ferais de tout ce qui sort en ce moment !...

les mecs veulent tout, mais ne ce donne pas les moyens pour l'obtenir !... résultat : Facebook (immonde, mais relativement rapide) / Microsoft (Gargantuesque !.. )
Et c'est deux exemples ont tout de même évolués !.. comme quoi, je ne penses pas que les imiter soit une bonne voie...

je penses que notre métiers doite etre fier de ses spécialisations !.. un Bon codeur HTML mais mauvais en php peux facilement mettre au tapis un Bon codeur php (mais nul en HTML) !... vu la puissance du css, ou de lib simple et light comme zepto et autres, je ne comprends toujours pas pourquoi certains s’obstinent à utiliser jQuery ... mis à par le drag/trash, j'en vois pas l'utilité ^^ (mais c'est personnel)


Bref, je me méfierais toujours des truc qui font tout, c'est comme les bonnes femmes, c'est louche ... ou en s'en mort les doigts après coup(s)