I guess this thread is drifting away from 'code quality' and into
'plugin sizes'.  :-)

I understand that the original intention for plugins was to provide
more complex functionality.  However, I personally think that there is
room for these smaller, 'trivial' plugins.  Yes, in many cases the
functionality could be distributed in a tarball and just unzipped into
the appropriate location... but I don't really consider this an
argument against packaging the code as a plugin, because the same
holds true for non-trivial plugins.

In my opinion it may make sense to package functionality in a plugin if:
 * you want the share the functionality throughout multiple projects
 * you want to be able to configure the functionality using symfony's
own config system
 * you anticipate needing to update the functionality contained in the
plugin and want a more manageable way of handling that across multiple
projects
 * you want to maintain a clear separation between the code specific
to your project and the code belonging to the plugin.
 * you want to create a place for what may start as a trivial plugin
to grow into something more significant.

Let's use Google Analytics as an example.  Yes, it's trivial to place
the code in your layout and be done with it.  However, I think there
is value in packaging this functionality in such a way that it becomes
a seamless package and follows the same installation interface as
other symfony plugins:
 * if you are managing multiple projects that all use Analytics, you
don't have to manually add the code to each layout.  You just install
the plugin.
 * bugfixes made to the plugin will propagate to all projects using
the plugin, rather than having to be manually made in each project.
 * the Analytics code is kept distinct from your own project code and
can easily be enabled/disabled.
 * the very fact that the plugin exists provides a place for more
powerful functionality and configurability to be added in the future.

To sum up, I think the ability to package and distribute small pieces
of functionality which can then be mixed together as needed is a
fantastic feature of symfony.  I agree some kind of quality control
system would be useful -- enforcing code standards, or even just a
simple rating system -- but I don't think that just because a plugin
is small and simple it is useless.  We shouldn't underestimate the
value of a consistent system for managing code external to our
projects, no matter whether it is large or small.

David Brewer

On Dec 11, 2007 9:38 AM, Ian P. Christian <[EMAIL PROTECTED]> wrote:
>
> Alexander Deruwe wrote:
> > I simply wish to respectfully disagree with the statement that these
> > plugins are not needed.
>
> I honestly doubt that the original poster meant to insult you - which
> appears to be how you took it...
>
> I don't think it's that they are not needed as such , but mealy that
> they are not a plugin in the sense that plugins were meant to be...
> which contains logic required by multiple applications.
>
> Your code could be distributed as a simple .tar.gz which is unzipped
> into the web folder.  I'm sure there are people out there that might be
> using your code, and they probably appreciated the work you did.
>
> As for the google analytic code, I've also pondered over the use of this
> as a plugin before - as I always just put code at the bottom of my
> layout.php.  But I've not looked at this plugin, maybe it does more then
> just that.
>
>
>
> --
>
> Ian P. Christian ~ http://pookey.co.uk
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to