I will comment on my past experience regarding a specific plugin. I've started working with Flex a while back ago. At the time, I looked for a plugin that would allow me to connect Flex and symfony through the AMF protocol. I found one but did not work the way I needed it and I wanted to be able to use Zend Amf since Adobe started contributing to the component, it made sense to go this route.
I then started to write a plugin, because I was sure I would be using it in different projects. My goal was to release the plugin when it reached a certain level of quality, documentation, etc. I have not been able to release the plugin for different reasons, and in the mean time, a few other plugins have popped up with similar functionality, so eventually if I release my plugin, there will be more than one option. I am sure this has happened in other cases and that's why you see different plugins doing similar things, although not always are exactly the same or accomplish the same goals. Pablo On Mon, Jun 29, 2009 at 11:23 PM, Sid Bachtiar<sid.bacht...@gmail.com> wrote: > >> Although it doesn't quite make sense to me. Either it's badly >> outdated, nobody cares, or I am missing something. > > Exactly. > > I think for most people the usual flow is ... I need a plugin, I > search in plugin page, I found few, I look at their readme to > determine which one suits my requirements. > > I think most developers would search first for a suitable plugin > before starting their own. We just need a medium to make it easier to > share our experience and knowledge so that other have better mean to > decide which plugin most suitable for their need. > > On Tue, Jun 30, 2009 at 3:13 PM, Richtermeister<nex...@gmail.com> wrote: >> >> Hey Sid, >> >> that's true, as far as sharing experience is concerned. With regard to >> avoiding overlap, supposedly this page is there to help: >> http://trac.symfony-project.org/wiki/OfficialProposedPlugins >> >> Although it doesn't quite make sense to me. Either it's badly >> outdated, nobody cares, or I am missing something. >> >> Daniel >> >> >> >> >> >> On Jun 29, 6:17 pm, Sid Bachtiar <sid.bacht...@gmail.com> wrote: >>> I think there is a lack of collaboration in the plugin section. >>> >>> Would be good to have each plugin to link to a wiki page so people can >>> share their knowledge and experience of particular plugin, which in >>> turns increase the chance that someone reuse rather than develop their >>> own. >>> >>> >>> >>> On Tue, Jun 30, 2009 at 1:09 PM, Richtermeister<nex...@gmail.com> wrote: >>> >>> > Hey Alecs, >>> >>> > I think everybody agrees that the list of plugins is getting a little >>> > cluttered and that there's some overlap and contributions of >>> > questionable usefulness. While I think that your point about having >>> > only 1 plugin for each purpose is a little extreme (variation drives >>> > exploration), I agree that there should be more "meta documentation" >>> > about plugins that helps separate the good from the bad and the ugly. >>> >>> > The issue seems to be with how to improve the situation. Amongst the >>> > common suggestions are ratings, comments, and other feedback >>> > mechanisms, but as you can tell the Symfony team is careful with the >>> > implementation thereof, because there's drawbacks to each. For now we >>> > recently got the "I use it feature", which I find a very clear way to >>> > tell the winners. If there's 10 people using one plugin vs. 1 person >>> > using the other, that speaks clearly, unless one has just been >>> > released, in which case it may even be counter-productive to go by >>> > that number. >>> >>> > I also agree that it would be nice to be able to "hide" plugins that >>> > really don't exist yet. I realize you need to be able to create an >>> > empty plugin in order to invite other developers to join you in its >>> > creation, but when I'm just browsing the list, I may not want to see >>> > those. >>> > Maybe a more realistic enforcement of version numbers would help, >>> > where empty projects start with 0.1 or something. Speaking of which, >>> > what I find frustrating and potentially harmful is "modest" >>> > versioning, where some fully functional plugins carries a version >>> > number of 0.x. Call it version 1 already! Think of us developers who >>> > have to justify to their bosses and clients why we use "alpha" code >>> > that we know to be perfectly fine.. ;) >>> >>> > Lastly, I would call for some standardization of the way plugins use >>> > existing symfony features. I'm getting a little sick of having to >>> > style the flash messages of every single plugin to look like the built- >>> > in symfony feedback. Maybe agreeing to use an include (which can be >>> > overwritten) for all flash communication would be a start. >>> >>> > That's my 2 cents, >>> > have a great day :) >>> > Daniel >>> >>> > On Jun 29, 9:41 am, Alexandru-Emil Lupu <gang.al...@gmail.com> wrote: >>> >> Hey there! >>> >> I would like to ask some stupid questions... >>> >>> >> There is any chances to clean up the mess that is in the "symfony >>> >> plugins" >>> >> section? >>> >>> >> By mess i mean: >>> >> - there are 2 twitter plugins (i suppose that they do the same thing, in >>> >> 2 >>> >> different ways) >>> >> - at least 3 chart plugins >>> >> - 23 plugins that handles forms ( validation, improvement, security or >>> >> User >>> >> interface ) >>> >> - 3 pdf plugins >>> >> - 3 feed plugins (2 that creates feeds ) >>> >> - 3 image manipulation plugins >>> >> - 8 plugins that handles mail >>> >> - 5 jquery plugins >>> >> - 7 CMS applications >>> >> - 3 blog plugins >>> >>> >> Ofcourse, there are many, but i just took some examples. >>> >> If we could structure the plugins better: >>> >>> >> 1 blog plugin that is able to have many more features >>> >> 1 image manipulation plugin with a maybe more complex Yml that would >>> >> handle >>> >> all the stuff, >>> >> 1 Pdf plugin that can easy interfaced with HTML, Latex or other things >>> >> 1 Jquery plugin that would have all jquery / JqUI files and functionality >>> >> 1 chart plugin >>> >> 1 twitter plugin >>> >> 1 CMS application >>> >>> >> I do not want to be missunderstand, but i think too many people >>> >> reinventing >>> >> the weel or the warm water. Instead of having 10 unmaintained plugins for >>> >> the same thing, we could have just one that would be maintained by all 10 >>> >> developers, instead of spending the time by rewriting the same thing in >>> >> other way. In the end, i think we all would have something to gain. Some >>> >> of >>> >> us a nice portofolio (being involved in sf project), others would spend >>> >> less >>> >> time improving x plugin and testing y,z plugins as well (even debug >>> >> them). >>> >>> >> I think this collaborations between developers would diminish the >>> >> chances of >>> >> bug occurences, would create some mature software, and improve the >>> >> quality >>> >> of the plugins. >>> >>> >> P.S. I do not want to offend developers for their work. Is just i think >>> >> it >>> >> would be better to have less plugings with more features. >>> >> I think that sf personell could provide us a list with most maintained >>> >> plugins. Then, we will see that from those 283 plugins, (maybe) more >>> >> than a >>> >> half are not maintained, and still have some items left to be done in >>> >> TODO >>> >> list. >>> >>> >> Ex: >>> >> DbFinderPlugin - 6 todo items >>> >> sfWebBrowserPlugin - 0 todo Items >>> >> sfLucenePlugin - 0 todo items / no Propel implementation >>> >> sfPropelActAsNestedSetBehaviorPlugin - 0 todo / no doctrine >>> >> implementation >>> >> required >>> >> *sfJqueryReloadedPlugin* - 8 items todo >>> >> sfPropelActAsTaggableBehaviorPlugin - 0 todo >>> >> sfAdminDashPlugin - 3 todo items >>> >> sfImageTransformPlugin - 0 todo >>> >> sfGoogleAnalyticsPlugin - 0 todo >>> >> sfAssetsLibraryPlugin - 6 items todo >>> >> sfLightboxPlugin - 0 todo >>> >> sfTCPDFPlugin - 0 todo >>> >> sfEasyGMapPlugin - 4 items todo >>> >> sfTaskExtraPlugin - NO README PRESENT >>> >> sfPropelActAsSluggableBehaviorPlugin - 0 todo >>> >> sfPropelActAsCommentableBehaviorPlugin - (2 items on wish list ) >>> >> sfPropelSqlDiffPlugin - 0 todo items >>> >> nahoMailPlugin - 1 todo >>> >> sfDateTime2Plugin - 0 todo >>> >> sfDoctrineActAsTaggablePlugin - 0 todo >>> >> sfPropelParanoidBehaviorPlugin - 0 todo >>> >> sfPropelVersionableBehaviorPlugin - 0 todo >>> >> sfDoctrineApplyPlugin - 0 todo >>> >> stOfcPlugin - 0 todo >>> >> sfSympalPlugin - 0 todo (?) no Propel implementation >>> >> sfGuardPlugin - 2 todo >>> >> sfFormExtraPlugin - 0 todo >>> >> sfDoctrineGuardPlugin - 0 todo >>> >> sfThumbnailPlugin - 0 todo >>> >> sfFeed2Plugin - 2 todo items >>> >>> >> Of course some of the plugins allready reach a maturity level, but, many >>> >> of >>> >> them are just in a premature state (check next pages :) ) . >>> >>> >> Alecs >>> >>> >> -- >>> >> As programmers create bigger & better idiot proof programs, so the >>> >> universe >>> >> creates bigger & better idiots! >>> >> I am on twitter:http://twitter.com/alecslupu >>> >> I am on linkedIn:http://www.linkedin.com/in/alecslupu >>> >> Tel: (+4)0748.543.798 >>> >>> -- >>> Blue Horn Ltd - System Developmenthttp://bluehorn.co.nz >> > >> > > > > -- > Blue Horn Ltd - System Development > http://bluehorn.co.nz > > > > -- Pablo Godel ServerGrove Networks http://servergrove.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
