Still trying to clear my backlog of BoltWire emails. Did you still have any unresolved questions from this email Mark?
Cheers, Dan P.S. You asked some good questions in it. Some a bit complex. I'll have to look into it probably if there are still some... On Wed, Jul 29, 2009 at 6:23 AM, Mark Marijnissen<[email protected]> wrote: > > Thanks for the reply! Really helps a lot. > > Maybe it is interesting to know what I am working on: > -------------------- > The site enables users split the costs if you have bought something > together. For example, I eat with a group of friends every week, and > to keep it fair we should split the costs for the groceries. This is > always a bit of a trouble, since only one person can pay at the > supermarket. And afterwards splitting is too much effort: nobody has > the right amount of money in their wallet, and my friends are just too > lazy transfer the money via internet (often its only 3 euros or > something). > So, the site solves this problem. I can create a group with all my > friends, and we just enter the purchases we have done. The site then > displays a balance of how much everyone has paid, and how much > everyone has eaten for. If every one pays sometimes, things should > even out and should be fair. However, if someone always pays and still > has to get more than 20 euro from the others, a mail is sent to the > person with the greatest debt, asking him/her to transfer some money. > ------------------- > > I want users to use their e-mail to log in. Currently, this is already > possible, but there isn't any check for duplicate e-mail adresses. > Also, an e-mail-adress as ID would go wrong, since it converts to: > login.markmarijnissengroupgmail.com > I think I can override the login and registerfunction for this. (I'll > figure it out, but tips are welcome). > > Further, I need to figure out how to handle security and > authorization. Basically, this is what I want: > * Each group has its special pages: transactions, messages. These > should be read and written by group members. > * In these pages, there is also some data variables users only should > read. These are set by some PHP scripts (custom boltwire functions). > (For example, the balance of a person should only be altered through > functions that add/change/remove transactions, and it should not be > possible to modify it arbitrarily by a user). > * There is also some private profile information, this should be read > by members of the groups someone joined, and written by the owner. > * The site stores persons bank account numbers, with people names. I > do not know about the security risks of that, but it would be a safe > idea if the name+number were only accesible for people that are in > groups the person has joined. > > There are some things I need to keep track of during a session: > * the current group a user is in. (I will look at your suggestions for > cookies and figure it out. Currently it is done through a data var on > the member page). > * the groups a user has joined (this is possible with {memberships}, > but I dont want "admin,member, editor" in it. I think I know how to > define a custom system variable ({groups}). > --------------------------- > > That's it. I have got the core running already (one week development!) > I there is pretty much details to do: the logging in, registering and > authorization. Some forms so that people can edit their profile, some > forms so that people can create groups and edit their members. I have > to integrate mail in everything, so users can get notifications of new > messages or transactions. I think the complete website will be done in > two or three weeks... and I am not working fulltime on it so my guess > is about 100 hours. I have no clue whether thats fast of slow for a > site like this, but i am happy. > > cheers, Mark > > > > > On Jul 28, 2:34 pm, The Editor <[email protected]> wrote: >> On Sat, Jul 25, 2009 at 11:29 AM, Mark >> >> Marijnissen<[email protected]> wrote: >> >> > I am creating a site that uses forms, and needs to keep a sort of >> > "database". Since I really love boltwire, I thought I'd make a >> > jumpstart and use boltwire as engine instead of creating everything >> > from scratch. >> >> Glad you like BoltWire! And if you want to create a real database, >> I've been meaning to create a simple database plugin, just haven't had >> time. I can do that if you want. Though in many ways, doing it within >> BoltWire pages is easier and in some situations possibly faster. >> >> > The advantage: lots of functionality already, especially with users, >> > registering, layout, create pages, etc... >> > The disadvantage: sometimes I do not know how to get things done, or >> > sometimes I lose overview over what is happening. >> >> > Especially commands and functions are difficult. There are only good >> > for really simple things. For the more essential core of my site, I >> > use a plugin with some custom functions and commands I call from the >> > pages. I love the help function, it really makes life easier! However, >> > when writing my plugin, I also get a bit lost: >> >> > * What is the BOLTarray? Couldn't figure that out exactly looking at >> > the source code. >> >> The BOLTarray is the set of all field/value pairs sent to the forms >> processor from a form. It will include even the session fields. So for >> example in the mail command, you can also look for fields that are not >> true commands like subject, to, from, body, etc., and use those in >> generating your email. Some commands use it, some don't need it. >> >> > * What is the ZONE argument in the functions for? >> >> Almost invariably it is not used. But in a custom plugin you could >> write a function that works different ways depending on which zone it >> was in: main, side, header/footer, etc. Basically it just tells which >> zone the function is being called from. >> >> > * Why are all commands preceded by [session ...]? It this necessary? >> >> Sessions are similar to hidden fields, except if you look in the html >> code, the session fields are not visible even there. So for example, >> in a mail form, it's better to use session than hidden for the to or >> from field, to keep the email addresses secure, but you can do it >> either way. Most commands that write to a page require you to use the >> session input type for security reasons, to prevent someone from >> submitting a falsified form and wreaking havoc on your site. Currently >> this list includes: >> >> authkey >> backup >> copy >> create >> delete >> edit >> enable >> if >> info >> join >> log >> login >> mail >> register >> rename >> reset >> restore >> savedata >> unstamp >> validate >> upload >> >> (see engine.php line 141). It is configurable of course. And it may be >> there are things that should be added/dropped to this list. I haven't >> evaluated it in a while. So these commands will always be ignored if >> not submitted as a session input type. >> >> > What does it do? Is is possible to store session variables? >> >> As for storing session variables, it should be easy enough to setup a >> simple command for that. But nothing by default for writing them in >> the core. The {?var} format will read session values I believe. On the >> other hand, there is a cookies plugin which works very nicely if you >> need that kind of functionality. I think you might find that useful. >> >> > * What is the difference between {id} and {member}? >> >> Generally the id is the actual page name (lower case), and member can >> be any case. It seems I set up a way where optionally the id and >> member could be completely different, but I don't see that now in the >> code, looking quickly. Generally, member is used in markups like this, >> rather than id, so: [[~bob]] => Bob (link). It is possible to use a >> different field for the display in this case. I use "RealName" on my >> FAST site, so it can be anything. >> >> Thanks for the good questions. Let me know if you have more! >> >> 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 -~----------~----~----~----~------~----~------~--~---
