I don't know whether John has gone out of town yet or not, so I'll do my best to reply in his stead.
In general, the mailing list is faster because it's more in-your-face. Too, I think it's a good principle to discuss something thoroughly on the mailing list, then create a patch or ticket on Trac that addresses the issue. That said, I don't often apply patches submitted via Trac; I let John make the decision. However, as a general rule, patches that provide small, incremental, well-tested changes that don't break or fundamentally alter the functionality of Radiant are more likely to be accepted. Regarding #502, I think it's a great idea, one I've been thinking about myself, but I have not tested it yet (for various reasons), and it changes a lot of core functionality. For #504, the <r:navigation> tag has been a sore spot for a long time and is unlikely to change in an incremental fashion. Also, just like the Rails core, if we don't it useful that way, it's just not likely to make it in. #504 would be ripe for an extension, though -- one of the reasons extensions exist, in fact. If you look at the roadmap, there are also tickets on there that have existed for nearly a year -- things that are important but have not found a solution that is satisfactory to the core team. We're only human, and have a limited attention span and limited time to work on Radiant. We appreciate contributions partly because they save us time, and partly because they come from people who are passionate about the feature they want to implement or bug they want to fix. Sometimes the end result is not always exactly what was submitted, but open source is about the communication and participation. Moral of the story -- don't be discouraged if your patch or ticket gets ignored. Discuss it on the mailing list and we'll work it out together. Cheers, Sean Jacob Burkhart wrote: > Thanks Sean. > > Looks like posting on the mailing list gets a much faster reply that > posting on Trac. > > So then a follow-up question would be, what's wrong with these > patches, why havn't they been replied-to? > http://dev.radiantcms.org/radiant/ticket/504 > http://dev.radiantcms.org/radiant/ticket/502 > > Jacob > > On 6/1/07, Sean Cribbs <[EMAIL PROTECTED]> wrote: > >> We would love a patch, of course! This will also help in a future >> refactoring toward REST which is on the horizon. >> >> Sean >> >> Jacob Burkhart wrote: >> >>> Hey, >>> >>> I just read this post: >>> http://www.therailsway.com/2007/6/1/railsconf-recap-skinny-controllers >>> >>> And it made me think immediately of the old handle_new_or_edit_post in >>> page_controller >>> http://dev.radiantcms.org/radiant/browser/trunk/radiant/app/controllers/admin/page_controller.rb?rev=57 >>> >>> >>> But now I go and look at the latest version, and I see it's been >>> cleaned up a bit, and there a new AbstractModelController seperating >>> the logic a bit. >>> >>> http://dev.radiantcms.org/radiant/browser/trunk/radiant/app/controllers/admin/page_controller.rb >>> and >>> http://dev.radiantcms.org/radiant/browser/trunk/radiant/app/controllers/admin/abstract_model_controller.rb >>> >>> >>> But still... you have a lot of logic in the controllers. And a lot of >>> that logic, if moved to the model, would be a lot easier to override >>> and modify in extensions. >>> >>> For instance, I'd like to see all the part-creating/arranging logic >>> moved into the Page model. >>> >>> 96 parts_to_update = {} >>> 97 (params[:part]||{}).each {|k,v| parts_to_update[v[:name]] = v } >>> 98 >>> 99 parts_to_remove = [] >>> 100 @page.parts.each do |part| >>> 101 if(attrs = parts_to_update.delete(part.name)) >>> 102 part.attributes = part.attributes.merge(attrs) >>> 103 else >>> 104 parts_to_remove << part >>> 105 end >>> 106 end >>> 107 parts_to_update.values.each do |attrs| >>> 108 @page.parts.build(attrs) >>> 109 end >>> 110 if result = @page.save >>> 111 new_parts = @page.parts - parts_to_remove >>> 112 new_parts.each { |part| part.save } >>> 113 @page.parts = new_parts >>> 114 end >>> >>> So, my question to the core devs is... how open would you be to patch >>> coming from me, that addresses some of these things. >>> >>> I must admit, my agenda is based on making my own extensions more >>> elegantly integrated with Radiant. But I'm hoping to appeal to any >>> skinny-controller philosophy-followers as well. >>> >>> thoughts? >>> >>> Jacob >>> _______________________________________________ >>> Radiant mailing list >>> Post: Radiant@lists.radiantcms.org >>> Search: http://radiantcms.org/mailing-list/search/ >>> Site: http://lists.radiantcms.org/mailman/listinfo/radiant >>> >>> >>> >> _______________________________________________ >> Radiant mailing list >> Post: Radiant@lists.radiantcms.org >> Search: http://radiantcms.org/mailing-list/search/ >> Site: http://lists.radiantcms.org/mailman/listinfo/radiant >> >> > _______________________________________________ > Radiant mailing list > Post: Radiant@lists.radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > > _______________________________________________ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
