This project has moved and is read-only. For the latest updates, please go here.

What should be a patch and what shouldn't?

Feb 7, 2010 at 7:29 PM

I just saw a new patch (#5200) to the core code ( that adds a new widget to the core widgets.  The functionality is that it adds a widget for displaying a map of users.  To me, this doesn't seem like core functionality and should be kept as an add-in.  My question is - where is the line drawn on what is core functionality and what isn't?  And how do we decide what is on either side of the line?  Like I said, this doesn't seem like core functionality to me, but I'm guessing that Al believes it is, since he's the one that submitted it as a patch.

Feb 9, 2010 at 3:53 AM

Is my modest opinion to be able to have the same functionality in widgets that wordpress, I believe that also adding a twitter widget will be very helpful, that way users will just need to select what to display in the presentation of their blog. More selection better in my really modest opinion still.



Feb 9, 2010 at 4:54 AM

I'm not too familiar with Wordpress, but not all of those widgets are part of the base install, are they?  I can't believe that they would have every widget part of it, there's absolutely no way.  They may take some non-core widgets and make them part of the base if they are the most popular widgets out there, but something with very limited appeal, that just isn't going to happen.  There's nothing preventing this or other widgets from being created as part of a plugin, putting it up on Codeplex (or any other open source repository) as a separate project, and then linking to it from here.  The plugin functionality is pretty simple to use, and once the DLL is there, you can use its widgets just like anything else, so I don't understand where the issue is with this methodology.

For this specific example, this is a very limited widget, I don't think very many people would make use of it, and I know I'd never use it, so I personally don't want it adding to the size of my core Graffiti DLLs, especially since it doesn't provide any even remotely basic functionality.  This is why I believe that we need to have a process to decide if a new piece of functionality, especially widgets, should be part of the main project or kept separated into its own project as a plugin.  If you keep adding every potential widget to the main code base, you are going to end up with a bloated piece of garbage that runs so slowly that no one will want to make use of it.

Feb 10, 2010 at 5:29 AM

I'd like to keep the core Graffiti CMS assemblies lean, and make it a great platform for plugins.

Al, that looks like an interesting widget but I also don't think it should be in the Graffiti.Core. However we could still include it in the repository in the plugins folder. I put the Graffiti Blog Extensions plugin there, and was hoping to add some other plugins & widgets that we could make available for download alongside the core Graffiti package. These would also serve as references for how to build a plugin/widget.

If you don't mind, I'll create a Widgets project inside /branches/v1.3/plugins/ and add your widget there.

Thanks guys!

Feb 10, 2010 at 11:01 PM

Kevin, where do we want to go moving forward with plugins?  I would assume that we wouldn't want every single plugin to be part of that single project, would we?  We'd run into the same problems that I mentioned above, where the DLL is going to get bloated with extra stuff that most people won't want.  This does slow down sites over time, as DLLs get more numerous and larger.  I'd much rather see a plugin repository, where you can download and install the plugins that you want either like DNN does it (where you upload the zip) or like Graffiti Marketplace (available on the Plugins admin page) was before it died. Having a core set of plugins available as part of the main solution is fine, but I still think it would be better to provide some separation.

Of course, we would need to have some sort of decision-making body to decide which plugins get included in the main solution, but that shouldn't be too hard to come up with.

Feb 11, 2010 at 1:07 AM

I would LOVE to bring the Marketplace online I am just not quite sure how to. I think having a viable Marketplace\App Store connected into Graffiti can make it an amazing platform to develop on and grow over time.

If any one has an idea how to do this and is interested in working on it let me know.

Feb 11, 2010 at 4:30 AM

I agree, we definitely need a marketplace (plugin/widget/theme library). One of the final tasks that must be completed before a 1.3 binary release is to get this up & running so the integrated marketplace functionality in Graffiti can point to the new location and actually work again. :)

I'm going to get a very basic marketplace setup by this weekend that will be usable by 1.3. It will just be for free plugins (& widgets/themes) and be on the light side initially until we have time to build it out. Help from everyone will definitely be appreciated and finding/testing/cataloging the various add ons that are available and compatible with 1.3, and I can setup you guys as admins on the site.

Charles, I was thinking we could have a set of "core" plugins that would exist in the main Graffiti CMS CodePlex repository but not included in the main binary download. We could have a second download link to them (or possibly multiple links if we split them up, not sure how to arrange it yet).  Stuff like the Blog Extensions plugin would be a great fit for this - plugins that are supported by the main Graffiti contributors and we think will be useful to many people... Of course they would be in the market place as well, listed individually.

I'm hoping to use the domain (which is currently owned by Telligent and redirects to but have to wait for executive approval which might take awhile. So in the meantime will use an alternate domain for the marketplace.

Feb 11, 2010 at 12:59 PM

Kevin, let me know if you need hosting for the marketplace site. I can get an account setup pro bono for this project.