Ok, I'm pretty decided about the following: The data, getline, and thread markups get shunted over to plugins and out of the core. I will first do a more careful scan of the core templates and actions just to make sure I'm not over looking something.
I'm planning to remove support for wikiwords (case sensitive page names). We can still have markup patterns for wikiwords anyway you wish, but no longer support for optional case sensitive page names. I'm thinking we probably need a configurable option for login emails. It seems by default we should do a little extra checking like Mark's code--to make sure all accounts have unique email addresses. But can be turned off by default. We might also want to add a line to automatically index login pages when they are created to make sure these emails get indexed immediately. These two things can be turned off by in site.config by some kind of variable. As for the counter / math issue, I am pretty sure it would be best to split the functionality, though 1) I appreciate the point you might want to use a math expression to initialize the counter. And 2) I had forgotten how easy it is to crash the math function by bad input. But I can't use the try command in php5 because we have users still doing php4 and I'm trying hard to maintain php4 support. My thought is we could do an advanced math plugin which remaps the math function to something more sophisticated, perhaps allowing trig functions and other kinds of advanced stuff. This point is still a bit undecided--just sharing my current thinking. I do hope to also do a little bit of cleaning up of several markup rules. And perhaps simplifying the zones processing if I can get around the need for a leading line return on some of the rules. Similarly I want to get the html for line spacing work for the last paragraph on a page properly. Some of these will be minor improvements but a lot of work. And progress will depend largely on what we can accomplish. We'll have to see... Ok, that's all on my to do list right now. Have I forgotten anything? Cheers, Dan On Sun, Aug 2, 2009 at 8:26 PM, The Editor<[email protected]> wrote: > On Sun, Aug 2, 2009 at 7:30 PM, Mark > Marijnissen<[email protected]> wrote: >> >>> You can always override any function in BoltWire very easily. First, >>> you can create your own custom login2 command (based off the core >>> function) and then just use that in your actions instead of login. But >>> to be more clever about it, you can use toolmapping to connect login >>> to login2 so your function is used instead of mine. Just put this in >>> the config.php just before your custom login2 command: >>> >>> $BOLTtoolmap['f']['login'] = 'login2'; >>> >>> This means whenever BoltWire sees a login command it will map that >>> over to your custom login2 function. >> >> There is a bit of a redundancy here- that why i missed it. I saw that >> the BOLTsavepage checks if there is a "myBOLTsavepage". So, i assumed >> that in order to overwrite a function you should use myXXXX, if it's >> supported. I suspect the redundancy exists for historical reasons, and >> removing the myXXX lines would mess up peoples sites and plugins. > > The myBOLT functions are generally for system functions. You can only > use toolmapping for the more modular functions, commands, and > conditions. > > The myBOLTsavepage function is used for specific purposes. In this > case, you might want to save your pages to a database rather than flat > files, or to some other kind of file format. As long as you have a > corresponding myBOLTloadpage you can potentially dispense with the > flat files completely. > > I'm sure there are other possibilities, but I've never used them. Just > tried to give options for the most important system functions. For the > other stuff tool maps work great. > >>> Second it seems you could easily enough setup a line or two in your >>> login form to check and see if an account with the given email exists. >>> It would look something like: >>> >>> [session search "group=login data="email={=email} fmt=count"] >>> [session if "equal {search} 1 ? warn=Account with this email account >>> exists..."] >> >> I use a custom boltwire application, which I was planning to do >> anyway. I modified the core Login and Register functions such way that >> they check if the email exists. >> >> if(BOLTXsearch("data='email=$BOLTarray[email]' group=$BOLTloginPages >> count=1 join='' fmt={+p}", 'search', false) != '') >> BOLTabort('register_member_exists'); > > Yes, that looks good. Basically the same thing. I suppose I should add > it to the core, but I wonder if there might be times when a person > might want to have more than one account with the same email address? > I know I sometimes create test accounts for stuff. Anyone have any > thoughts on this? > > 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 -~----------~----~----~----~------~----~------~--~---
