Snippets mods : shouldn't those be integrated into the original snippet ?

Sheesh David, AjaxSearch hasn’t even shipped yet!

Okay guys, I am bumping this again.

I have already said this but I am becoming quite concerned that some nice improvement could lay under the radar, like this one on DropMenu.

I really do think it’s a shame having 10 hacks of every significant snippet lying around with no real scheme to integrate them into the main snippet distro. As I have suggested, we could define criterias to decide wether or not a particular improvement should be integrated :
- is it useful to most ?
- is it stable ?
- does it negatively impact the snippet performance or not ?

I am sorry to bring this up again, but I feel with time we will regret this... couldn’t we set up a little coordination ? Some way for snippet improvements to be submitted to the original author or something ?

Thanks !

DropMenu is being totally rewritten to use templates for the various parts. It also going to use a few new API calls when it’s released, so it’ll be much nicer on the overhead quotient. It’ll make it a much simpler and much more powerful snippet all at once.

I’m also starting to noodle on a "proximity detector" snippet that’s useful for auto-creating startIDs just like in the snippet you mention, as well as including the UltimateParent capability as well. Combine those two and you’ve pretty much got infinite flexibility a heck of a lot more easily.

BTW, DropMenu has a specific project for it on the bugtracker already which I assume would mitigate your concerns.

:)

Thanks Ryan for the input (great changes BTW !!!), true I had forgotten about the Bugtracker for DropMenu.

But DropMenu is not the only one, and my concern is that some snippet improvement get lost. What I meant was, Zi’s idea of a "How to contribute" page with nice & obvious pointers could help people submit their improvement.

I guess everything will be easier when we have a repository and code contributors have a single, more structured place to put their snippet/plugin/module.

Indeed I agree 110%. Garryn and Kylej are working away on the Repository solution as I write this. I hope it’ll be somewhat ready in the very near future.

Yeah I remembered they are working on it, and it’s great I trust them to offer us a cool and efficient repository ! Also, I know they’re working as fast as humanly possible

I’m still opposed to the general idea of integrating the great variety of snippet mods available; I’d rather have 20 choices of search snippets to choose from than one snippet that does it all. To me, this is not the way to approach problems with MODx. IMO, the most efficient sites and web application implementations with MODx will be achieved with small, simple components that do nothing more than exactly what you need them to. Trying to make snippets work in a one-size fits all way is not the approach I take with my sites at all. In fact, the larger and slower and less efficient a snippet gets trying to expand to fit everyone’s need, the less likely I am to use it. At that point I’d end up just borrowing the code I want out of it and stripping it of every unnecessary line of code and comment so it would do it’s job most efficiently.

Now, I can surely understand the value of things like NewsListing/Ditto as a generic summarization tool in terms of marketing to end-users and making things easy to use for the the newbies. And when the problems being solved are the same, consolidating variations of the solution or combining multiple solutions in different ways will surely be beneficial. But the fact is, for truly professional grade sites and development, the most important goal is typically scalability. And that demands concise components that do very specialized jobs with as little overhead as possible.

I guess my point is, we shouldn’t force all the variations into a single offering, just help organize them in a way that people can understand which variation might be right for the job at hand. Not to mention, I really think the variations help those trying to learn development on the MODx platform, instantly see the code differences that make those variations possible.

I totally agree too Jason. I like things like Membercheck, Personalize, and my to-be-noodled-on-some-more Starting Point Finder thingy that can be configured to feed different startIDs to the different snippets that need it... Little functional specific bits of code that can be strung together like Legos(tm).

Heck, it wouldn’t even bother me to see the RSS feed generation stuff pulled out of NewsListing/Ditto, even if it’s only 10 lines or less, but I could be wrong on that one.

With the DropMenu replacement, I think you’ll agree we’re ripping a lot of stuff out that used to be parameters, and replacing those numerous configuration options with a simple chunk-template system. It’s simpler, faster, and actually a lot more flexible. It won’t handle all the corner cases, but it’s so simple that modifying it to fit those needs should be relatively straightforward ... and then you could strip even more stuff out and have another function-specific version that is a lot easier for new users and should be less resource intensive.

I do not disagree with you at all about keeping snippets light and letting people choose what they need or integrate various "branches" if they so wish.

But some must-have features sometimes get "lost" in the forum right now and that’s too bad. I discovered recently Susan had written a Highlight search term hack for FlexSearchForm. This feature is a good example of what I had in mind : a must-have feature which misses from the main distribution snippet and does not clutter the main code.

I think in fact my main concern is features getting lost in the forum...

Quote from: davidm at May 10, 2006, 02:04 PM

I think in fact my main concern is features getting lost in the forum...

Ok, now this I completely understand, and this needs to be handled in a better way for sure. Anyone have ideas on how the repository efforts could help us manage features among the variations. I think the best solution here is again, having an official set of submission guidelines and some sort of review process that can help determine if something should be posted as a separate add-on variation and/or have it’s feature set merged into an existing one available in the repository already.