On Sat, Sep 26, 2009 at 4:55 AM, DrunkenMonk <[email protected]> wrote: > >> I appreciate the ideas here, but I am not sure I want to go this >> direction. You have some good ideas here but >> >> 1) I'm afraid we'll lose track of things by not doing the writing >> immediately, and trying to cache it temporarily. I foresee lot's of >> bugs. > > After reviewing the BOLTloadpage function for the mysql_backend > plugin, I really don't see where the problems would arise.
I am very used to thinking of my forms as commands, processed in the order they appear in the form. I'm hesitant to make one exception for writing to pages. We could try and keep the page store cache always updated (I tried that change in 3.16) but not sure if it will affect vars and other things at all. I just feel it's a bit hobbled together to do all this artificially and then make it reality after the fact. >> 2) I don't think most people are going to be editing a single page >> multiple times, often. And if there was a need to do that probably... > > I don't know. Given that many of my Boltwire-written solutions using > forms often have to update several pages, and many session commands > are generated in templates making it difficult keeping track of order > of excecution, I'm often faced with sessions that abort halfway > through, leaving half-finished pages that need to be reverted or > deleted. With delayed disk writes, not only would the logic that leads > to the error go faster, we would also never have half completed tasks. > I like the all or nothing principle, it's more of a bonus than a > problem to me. Especially if we include a simple [session commit] > command for when you want to divide tasks. You make good points here, though in all my forms I don't know this has ever happened to me once. I do know I've had problems with order of operations of a form. And I do know bugs are a constant battle. So I tend to put more weight on keeping the code simpler and more--what's the word--natural in its operation. I'm not saying we can't, just I'm very skittish here. > Tell you what, assuming theres a Boltwire hook that gets executed > after the connection to the user is closed (useful for logging > purposes anyway), I can always make an extension for this myself. Show > you the awesomeness of my awesome suggestion of pure awesome. I love > that firefox accepts "awesomeness" as a word, but not "firefox". BoltWire already has pre, post, and background processing hooks. Though I've not used much the idea is you set (in your case): $BOLTpostProcess[] = 'functionname'; (or pre/background for post) And that function will get called. If this isn't adequate for you let me know. > have a Boltwire-configurable mysql_backend ... Lacking a BOLT > $plugin_onInstall() hook, called before the plugin is commit to > site.config or wherever, allowing the plugin to block the installation > if it isn't installed properly...) on the format: Not sure what you mean here, but I'm much more inclined to provide hooks when possible. If you could specify exactly what you want I'll try to help. > I like this brainstorming thread. I'm going to let it go for a few > days, then summarize what suggestions are good for plugins, and what I > hope will be put into Boltwire. See what happens. :) Good! Looking forward to more ideas. You've given me some great ones the last few weeks. Enough to keep me busy. But worth it. No one may notice the changes on the outside--but I like the feeling that cool stuff is happening on the inside! Cheers, Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" 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/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
