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
-~----------~----~----~----~------~----~------~--~---
