On Tue, Oct 6, 2009 at 12:24 PM, DrunkenMonk <[email protected]> wrote: > > >> A simple example. And manageable probably. But the question is do we >> want to go this direction? > > I don't speak for all of us, but I definitly do. > Firstly, this is a tried and true source of hidden errors, where you > write something that should work, but because of some unknown way that > boltwire works, it doesnt. It's a barrier to entry, it's annoying, > it's hard to debug.
You may be right. I don't think this has ever happened to me, but then again, I know the commands rather intimately. :) > Secondly, we gain a distinction between commands and variables. The > fact that we don't have this is, to me, mind boggling. Creating any > structured logic with boltwire currently requires in depth knowledge > of form and session peculiarities. Actually, I have no problems with structured logic, and don't know what you are talking about regarding session peculiarities. The only thing you need to know (admittedly, no trivial task) is the reserved commands. >> I don't mind rewriting the core actions but >> there are surely many custom forms that would be affected and lot's of >> plugins. > > I believe there are less than youd think. I usually treat my inputs as > variables and send them through a session command seperatly anyway, > because it feels more logical. The way the docs are written tend to > promote this way of thinking anyway, since session commands are always > used as [session <command>] in the examples. I think you are right about this. My general tendency is to do this automatically, and all commands that write to a page, for security reasons are required to be session vars already. But there would be enough to give us bug reports for a month. > Given a list commands, you could throw together a regexp to search for > \[(word) (one of reserved word list), filter by word=session, and > count the affected plugins and pages. This would give us a clear idea > of the problems involved. I'm doubtful I could effectively scout out all the plugins this way. The core actions I would check by hand anyway. > Although, now that i think about it, I suppose I have some if > statements that would be affected. Still worth it. > > Make this change, and a further change to automatically add a postfix > to repeated commands (which would now make sense where it didn't > before), and the level of understanding required to use forms in > boltwire is *drastically* reduced. Put together, these 2 issues make > up for maybe 90% of the debugging time i've spent on my forms. I am quite drawn to both of these ideas. I'll add this to my to do list. Well, my to think about list. This might be something to work towards for a 4.0 release along with some of the other ideas floating around. I don't know--I was hoping 3.xx would not be too disruptive a ride, but we've had one or two good bumps already and I see a couple more in the works... 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 -~----------~----~----~----~------~----~------~--~---
