iamb-dev — Development mailing list. Discussion of implementation.

[Iamb-dev] Web page sucks less

[Rich B. <rb...@rc...>]

I worked on the IAMB web page (iamb.rcbowen.com) and it sucks a little
less. It is still pretty bad, but at least it's a little better. I'll
put it up on SourceForge some time, I suppose, if it starts actually
getting any traffic.

-- 
Rich Bowen
Author: Apache Server Unleashed - www.apacheunleashed.com
Director of Web Application Development - http://www.cre8tivegroup.com/

Re: [Iamb-dev] marktypes

[Matt C. <su...@qx...>]

On Sun, 24 Dec 2000, Rich Bowen wrote:

> Strange. Perhaps your MySQL is pickier than mine.

tis entirely possible. i'm using the very latest gamma release of mysql
and they seem to be locking down things a bit. *shrug* will try the patch
sometime in the next few days. 

m.

Re: [Iamb-dev] marktypes

[Rich B. <rb...@rc...>]

Matt Cashner wrote:
> 
> here is the code related error i get with marktypes:
> 
> [Sat Dec 23 19:20:11 2000] index.cgi: DBD::mysql::st execute
> failed: Column: 'ID' in field list is ambiguous at
> /usr/local/apache/vhosts/iamb/index.cgi line 631.
> 
> [Sat Dec 23 19:20:11 2000] index.cgi: DBD::mysql::st fetchrow_array
> failed: fetch() without execute() at
> /usr/local/apache/vhosts/iamb/index.cgi line 632.

Try this

Index: index.cgi
===================================================================
RCS file: /cvsroot/iamb/iamb/index.cgi,v
retrieving revision 1.26
diff -u -r1.26 index.cgi
--- index.cgi   2000/12/20 03:41:39     1.26
+++ index.cgi   2000/12/25 03:04:20
@@ -622,7 +622,8 @@

        $user = $iamb->WhoAmI($iamb->dbh);
      my $form = $iamb->form;
-       $sth = $iamb->dbh->prepare("select ID from " . $iamb->articles .
" a, "
+       $sth = $iamb->dbh->prepare("select " . $iamb->articles . ".ID
+                              from " . $iamb->articles . " a, "
                                                . $iamb->unread . " u
                                                where
a.forumID=$form->{forum}
                                                and a.ID = u.articleID


-- 
Rich Bowen
Author: Apache Server Unleashed - www.apacheunleashed.com
Director of Web Application Development - http://www.cre8tivegroup.com/

Re: [Iamb-dev] marktypes

[Rich B. <rb...@rc...>]

Matt Cashner wrote:
> 
> here is the code related error i get with marktypes:
> 
> [Sat Dec 23 19:20:11 2000] index.cgi: DBD::mysql::st execute
> failed: Column: 'ID' in field list is ambiguous at
> /usr/local/apache/vhosts/iamb/index.cgi line 631.
> 
> [Sat Dec 23 19:20:11 2000] index.cgi: DBD::mysql::st fetchrow_array
> failed: fetch() without execute() at
> /usr/local/apache/vhosts/iamb/index.cgi line 632.

Strange. Perhaps your MySQL is pickier than mine.

-- 
Rich Bowen
Author: Apache Server Unleashed - www.apacheunleashed.com
Director of Web Application Development - http://www.cre8tivegroup.com/

[Iamb-dev] marktypes

[Matt C. <su...@qx...>]

here is the code related error i get with marktypes:

[Sat Dec 23 19:20:11 2000] index.cgi: DBD::mysql::st execute
failed: Column: 'ID' in field list is ambiguous at
/usr/local/apache/vhosts/iamb/index.cgi line 631.

[Sat Dec 23 19:20:11 2000] index.cgi: DBD::mysql::st fetchrow_array
failed: fetch() without execute() at
/usr/local/apache/vhosts/iamb/index.cgi line 632.


--------
Matt Cashner
Web Applications Developer
The Creative Group (http://www.cre8tivegroup.com)
su...@ea... | Codito, ergo sum

Re: [Iamb-dev] marktypes

[Rich B. <rb...@rc...>]

Just FTR, I'm finding several changes, which I made the last night
before the big SourceForge server move, to be missing. I think that they
restored to the new server from a backup that was a day or two old. I
encountered another database difference when I did the last commit. I
know for sure that I made the change last week. It's very irritating.
Hopefully there are not other bug fixes that I've made that I don't
remember about any more.

-- 
Rich Bowen
Author: Apache Server Unleashed - www.apacheunleashed.com
Director of Web Application Development - http://www.cre8tivegroup.com/

Re: [Iamb-dev] marktypes

[Rich B. <rb...@rc...>]

Matt Cashner wrote:
> 
> (yes, for the record, i'm back home again in indiana)
> 
> i sat down with the current (as of two days ago) iamb cvs tree. um, am i
> the only one who thinks this is broken?  i installed from scratch and
> noted a few problems.  the mark table is not present in the sql
> builder. 

OK, diff attached, and it's in CVS now.

> the mark type code doesnt seem to work so i cant mark anything
> read. 

Is that due to the missing table, or is that code just broken in
general?

> those are my two big complaints right now.  well that and the
> Makefile needs to be removed.

> it does bad things and until i get around to
> creating a decent install process, its better to not have it in the tree.

Go ahead and remove it. That's fine.

--
Rich Bowen
Author: Apache Server Unleashed - www.apacheunleashed.com
Director of Web Application Development - http://www.cre8tivegroup.com/

[Iamb-dev] marktypes

[Matt C. <su...@qx...>]

(yes, for the record, i'm back home again in indiana)

i sat down with the current (as of two days ago) iamb cvs tree. um, am i
the only one who thinks this is broken?  i installed from scratch and
noted a few problems.  the mark table is not present in the sql
builder. the mark type code doesnt seem to work so i cant mark anything
read. those are my two big complaints right now.  well that and the
Makefile needs to be removed. it does bad things and until i get around to
creating a decent install process, its better to not have it in the tree. 

there's my complaint session for the day. :)

from the looks of things, my internet connection will be bout the same as
home and i might even come online occasionally :)  so fire those flames
away. :)

--------
Matt Cashner
Web Applications Developer
The Creative Group (http://www.cre8tivegroup.com)
su...@ea... | Codito, ergo sum

Re: [Iamb-dev] Logins, users, etc

[Rich B. <rb...@rc...>]

Ken Rietz wrote:
> 
> What is the mechanism here? Once a user logs in (against some user
> database, I assume), a cookie is set. Will the user have the
> option of making it permanent (every user of this computer will
> always log in as this person) 

"Remember me." Yes. Put a 2038 expiration date on the cookie.

> or temporary (login required next
> time as well)? 

Yes, session cookie rather than persistent one.

> For example, you and Carol share a computer, but
> you want to be known as different people when posting. I see no
> simple way around that. Multiple cookies, and you get to choose?

Well, we don't share a computer, but I understand the scenario. My
solution is to have a logout link. And a "You are currently logged in as
Waldo. If this is not accurate, please log out." sort of thing, maybe.

> I don't get "real logging in" in your sense. Logging in, to me,
> means verifying to the computer that you are someone with legal
> access (and setting permissions, etc.). Isn't that what you are
> doing here, with cookies?

Well, yeah, sort of. But since HTTP is session-less, you still have to
reauth every single GET. There's no established connection. But those
are general HTTP comments, not effects of anything I may or may not do
in the code.

> I assume the standard: 0 = false; 1 = true.

Indeed

> I would suggest the option of public versus private forums:
> user 0 is allowed to see public forums only; private forums
> require user > 0 (or user in some database entry). I don't
> want to open the entire TM3 site to everyone.

Yes, public vs private forums is in the task list already, under the
guise of access control lists. The idea is that public forums don't get
access control lists (unless it is ban lists) and private forums have to
have one.
 
> Do you want user 0 to be able to create accounts? Shouldn't
> account creation be a bit more restricted? I am thinking again
> of the TM3 board.

Yes, in general, you want user 0 to be able to create accounts. This a
forum like Slashdot, or Kuro5hin, or my Kenya board. Random strange
signs up so they can participate. It's how these things usually work.
But you can make them closed invitation-only affairs, if you like. Of
course, even in the TM3 thing, user 0 can create an account. Remember,
we all used to log in with the generic "tm3" login, and once you were
insite the front door you could then create a personalized account. That
was a 'user 0' sort of situation. Sort of.
 
-- 
Rich Bowen
Author: Apache Server Unleashed - www.apacheunleashed.com
Director of Web Application Development - http://www.cre8tivegroup.com/

Re: [Iamb-dev] forums and niftiness

[Matt C. <su...@ea...>]

On Thu, 21 Dec 2000, Rich Bowen wrote:

> There are a number of places where code assumes that theres only one forum.
> Notably, the admin interface. But it's also elsewhere. This needs to be
> corrected, as it can cause some damage in places. The update unread 
> function is another place where it could cause problems.

so what i'm hearing is that the whole forum dohicky needs to be brought to
completion before i even think about this?  ok. that's doable. as soon as
i finish upgrading mysql and apache on my workstation, i'll get to work :)

> This has been something that someone (Bill) has requested thousands of times,
> and I've always brushed him off about. It would be nice. 

well bill, your day has come. Rich may brush you off but i have felt your
pain and will endeavor to bring you great joy and ease of use. :)

> There are issues that
> I always had problems with. How do you know that a particular email is a 
> follow up to a particular thread? 

subject. maybe a thread id embedded in the subject by iamb?

subject: [IAMB 2-47] More Unicode Nonsense

as a postprocessed example.  futz with the subject and it becomes a new
thread. in terms of the mailings lists, i'll use mhonarc's logic of using
message ids and followup headers where i can and subject matching when i
cant.

> What if they change the subject?

as long as the [] part stays the ssame we can recognize it. futz with that
and you get what you deserve.
 
> What if two (unrelated) emails have the same subject? 

the [] id will help with that. untagged emails that are not being
processed from a mailing list will automatically start a new thread. (tho
in what forum? hmmm...)

> Not insurmountable, but problems nevertheless.

bah :)

------
Matt Cashner
Web Applications Developer
Creative Group (http://www.cre8tivegroup.com)
su...@ea... | Codito, ergo sum

Re: [Iamb-dev] forums and niftiness

[Rich B. <rb...@bu...>]

> 
> ok. i'm taking a step away from my usual position as head of the
> "currently waiting on ken" :) development branch and i'm going to do some
> work on the "stable" branch (the _rich_ branch :).  

Woowoooooo.

> my thoughts:  what i want to do is to inject a mailing list into
> iamb. lets say i want to make p5p (perl5-porters) available for a largish
> company. i create an email alias, sign it up for p5p, and make that alias
> dump email to an iamb script. that script injects p5p posts to a read-only
> forum set aside specifically for p5p. now everyone in the company has
> access to p5p with the fun and neatness of the iamb interface (thread
> ignoring, bookmarks, etc).

As I mentioned earlier today, there's a script in CVS that accepts incoming
email and puts it into IAMB. It's not much to go on, but it's a start. If it's
not in the SourceForge email, it's in the Attic on my CVS repository. Not that
it's particualarly hard. It was kinda fun to play with.

> what this will take: getting forums working (including ui work). creating
> forum properties (read-only, public/private, etc). the script to munge
> email into the database.  ability for users to sign up for forums. 

It would be nice if the unread SSI was aware of forum signups, and did unread
counts for just those fora.

> the current code already supports forums but forums are not available on
> the ui. 

There are a number of places where code assumes that theres only one forum.
Notably, the admin interface. But it's also elsewhere. This needs to be
corrected, as it can cause some damage in places. The update unread function is
another place where it could cause problems.
 
> where i think this could go: i think this could easily lend itself to an
> email-based interface for iamb. sort of like RT but not :)  but that's a
> bit down the road and i wanted to run the concept by everyone and see what
> everyone thought.

This has been something that someone (Bill) has requested thousands of times,
and I've always brushed him off about. It would be nice. There are issues that
I always had problems with. How do you know that a particular email is a follow
up to a particular thread? What if they change the subject? What if two
(unrelated) emails have the same subject? You can do stuff with message ID and
follow-up headers, but not all mailers support that. Not insurmountable, but
problems nevertheless.

This could be pretty cool stuff.

I'm definately +1 on this idea.

[Iamb-dev] forums and niftiness

[Matt C. <su...@ea...>]

ok. i'm taking a step away from my usual position as head of the
"currently waiting on ken" :) development branch and i'm going to do some
work on the "stable" branch (the _rich_ branch :).  

my thoughts:  what i want to do is to inject a mailing list into
iamb. lets say i want to make p5p (perl5-porters) available for a largish
company. i create an email alias, sign it up for p5p, and make that alias
dump email to an iamb script. that script injects p5p posts to a read-only
forum set aside specifically for p5p. now everyone in the company has
access to p5p with the fun and neatness of the iamb interface (thread
ignoring, bookmarks, etc).

what this will take: getting forums working (including ui work). creating
forum properties (read-only, public/private, etc). the script to munge
email into the database.  ability for users to sign up for forums. 

the current code already supports forums but forums are not available on
the ui. 

i'd like to make this all my pet project for the next month and work
through all this on my own. ideas and thwapings are always welcome :) i
leave on vacation on saturday morning and probably wont have much net
access until jan 4. in between there this will most likely be my main
coding project.

where i think this could go: i think this could easily lend itself to an
email-based interface for iamb. sort of like RT but not :)  but that's a
bit down the road and i wanted to run the concept by everyone and see what
everyone thought.

thanks all.

------
Matt Cashner
Web Applications Developer
Creative Group (http://www.cre8tivegroup.com)
su...@ea... | Codito, ergo sum

Re: [Iamb-dev] Logins, users, etc

[Ken R. <kr...@qx...>]

> OK, one last time through this, mostly so that I can make sure that I've
> thought it out. Tell me if it seems that I have things completely wrong.
> 
> Every user of IAMB will be "logged in" by virtue of whatever username
> and password I find in their cookies. In the event that their cookies
> are empty, or not valid users, they are still "logged in", just as some
> anonymous user, ID 0.

What is the mechanism here? Once a user logs in (against some user
database, I assume), a cookie is set. Will the user have the
option of making it permanent (every user of this computer will
always log in as this person) or temporary (login required next
time as well)? For example, you and Carol share a computer, but
you want to be known as different people when posting. I see no
simple way around that. Multiple cookies, and you get to choose?

> There will be a login form whose purpose is nothing more than to set
> cookies. Well, it will politely refuse to do so if the proffered
> information does not correspond to a valid user account, but apart from
> that, it's just setting cookies. No real "logging in" takes place.

I don't get "real logging in" in your sense. Logging in, to me,
means verifying to the computer that you are someone with legal
access (and setting permissions, etc.). Isn't that what you are
doing here, with cookies?

> So, configurable things will be stuff like - is user 0 permitted to post
> articles? Is user 0 permitted to view articles? Is user 0 permitted to
> edit articles posted by user 0? Default values would be 1, 1, and 0,
> respectively. Oh, yeah, and will user 0 be permitted to create new user
> accounts? (default 1).

I assume the standard: 0 = false; 1 = true.

I would suggest the option of public versus private forums:
user 0 is allowed to see public forums only; private forums
require user > 0 (or user in some database entry). I don't
want to open the entire TM3 site to everyone.

Do you want user 0 to be able to create accounts? Shouldn't
account creation be a bit more restricted? I am thinking again
of the TM3 board.

> That sounds pretty reasonable to me, and I'd really like to implement
> most of it tonight. I'm just getting very sleepy, and spent most of the
> evening reading Tolkein, and playing with AvantGo.

I envy you having the time to read Tolkien.

I have been working more on IAMB internals APIs. Expect something
soon, probably a massive entry. The dribble-it-out-for-comments
approach hasn't happened.

-- Ken

[Iamb-dev] Logins, users, etc

[Rich B. <rb...@rc...>]

OK, one last time through this, mostly so that I can make sure that I've
thought it out. Tell me if it seems that I have things completely wrong.

Every user of IAMB will be "logged in" by virtue of whatever username
and password I find in their cookies. In the event that their cookies
are empty, or not valid users, they are still "logged in", just as some
anonymous user, ID 0.

There will be a login form whose purpose is nothing more than to set
cookies. Well, it will politely refuse to do so if the proffered
information does not correspond to a valid user account, but apart from
that, it's just setting cookies. No real "logging in" takes place.

So, configurable things will be stuff like - is user 0 permitted to post
articles? Is user 0 permitted to view articles? Is user 0 permitted to
edit articles posted by user 0? Default values would be 1, 1, and 0,
respectively. Oh, yeah, and will user 0 be permitted to create new user
accounts? (default 1).

That sounds pretty reasonable to me, and I'd really like to implement
most of it tonight. I'm just getting very sleepy, and spent most of the
evening reading Tolkein, and playing with AvantGo.

-- 
Rich Bowen
Author: Apache Server Unleashed - www.apacheunleashed.com
Director of Web Application Development - http://www.cre8tivegroup.com/

Re: [Iamb-dev] Community::User

[Rich B. <rb...@rc...>]

Ken Rietz wrote:
> 
> > =item register
> >
> >      $luser = Community::User->register( login => 'drbacchus',
> >                password => 'cabernet', screenname => 'God Of Wine',
> >                email => 'spa...@dr...' );
> >
> > Registers a new user, returning a user object. Note that the user
> > is not actually stored in the database until you call the C<save>
> > method. This is so that we have as little database access as
> > possible. Note also that C<save> is I<not> called on C<DESTROY>.
> 
> I guess I don't understand the rationale for not calling save from
> the register routine. Why would there be any more database access
> by making the main routine call save? Shouldn't register actually
> register the new user? Besides, if there are problems in saving,
> register ought to take care of them; that strikes me as the right
> place to handle that sort of thing.

OK. Not sure yet. Either way, save ends up being a separate method,
which register may or may not call for you. The rationale is that you
might create a "new" object, and then tinker with the contents of that
object before you save it. Yes, this is unlikely in a CGI setting, but
might be possible if we were to write a TK front end, or something like
that, where a session lasts longer than one nothingth of a second, and
the user object might exist for a few hours.

-- 
Rich Bowen
Author: Apache Server Unleashed - www.apacheunleashed.com
Director of Web Application Development - http://www.cre8tivegroup.com/

Re: [Iamb-dev] IAMB OO

[Ken R. <kr...@qx...>]

Rich Bowen wrote:
> 
> The more I work on this code, and the more bugs I fix, the more I wonder
> how I ever thought about this stuff in a non-OO manner. This code could
> be so much more pleasant.

When you are trained to operate procedurally, OO is definitely not
natural. OO has suffered from too much hype. It is The Right Thing
for some projects and not for others. I'd agree that IAMB is one
of the places for it to work well, since it is nightly modular to
start with.

> It would seem that if things continue the way that they are going, the
> main branch of the IAMB code is going to become the next major version
> before the dev branch gets any changes done! :-)

Sorry. My fault. Now that the semester's over, I'll get back to
working on it.

> I'll be posting a synopsis of how I expect the user/login stuff to work
> RSN. Perhaps tomrrow.

The problem is that you work so fast, it is hard to get feedback
to you before you've finished coding. But then, I tend to work in
that same mode at times myself, so I can't complain too much :-(.

-- Ken

Re: [Iamb-dev] Community::User

[Ken R. <kr...@qx...>]

> One change that just occurred to me ...
> 
> > =item login
> >
> >      $luser = Community::User->login( $username );
> >      $luser = Community::User->login( $userID );
>         $luser = Community::User->login();
> >
> > Loads a user object from the database (um ... sort of). You will be
> > able to specify either the usernamd or the userID. Consequently,
> > I suppose we should mandate that usernames cannot be composed
> > of only numbers. Seems like a good idea, anyway. Or, perhaps, we
> > should require named parameters here. Perhaps that's a better idea.
> 
> Calling login() with no params causes it to look in the environment
> for cookies, and use them for login information. This will be the way
> that it is most frequently used, I expect, as a quasi-authentication.

Clever. I'd assume that the code would go something like

    [regular login] unless ($luser = Community:User->login());

(that is, if there is no cookie, then the call returns void).

-- Ken

Re: [Iamb-dev] Community::User

[Ken R. <kr...@qx...>]

> =item register
> 
>      $luser = Community::User->register( login => 'drbacchus',
>                password => 'cabernet', screenname => 'God Of Wine',
>                email => 'spa...@dr...' );
> 
> Registers a new user, returning a user object. Note that the user
> is not actually stored in the database until you call the C<save>
> method. This is so that we have as little database access as
> possible. Note also that C<save> is I<not> called on C<DESTROY>.

I guess I don't understand the rationale for not calling save from
the register routine. Why would there be any more database access
by making the main routine call save? Shouldn't register actually
register the new user? Besides, if there are problems in saving,
register ought to take care of them; that strikes me as the right
place to handle that sort of thing.

> 
> =item login
> 
>      $luser = Community::User->login( $username );
>      $luser = Community::User->login( $userID );
> 
> Loads a user object from the database (um ... sort of). You will be
> able to specify either the usernamd or the userID. Consequently,
> I suppose we should mandate that usernames cannot be composed
> of only numbers. Seems like a good idea, anyway. Or, perhaps, we
> should require named parameters here. Perhaps that's a better idea.

Named parameters are The Right Thing. I strongly vote for them here.
It would allow a cleaner separation between $username and $userID
database calls. Besides, they are used in the register function.

-- Ken

Re: [Iamb-dev] Community::User

[Rich B. <rb...@rc...>]

Rich Bowen wrote:
> 
> Since diffs are temporarily borked, I thought I'd run this API by you on
> the list. See attatched POD.

One change that just occurred to me ...

> =item login
> 
>      $luser = Community::User->login( $username );
>      $luser = Community::User->login( $userID );
	$luser = Community::User->login();
> 
> Loads a user object from the database (um ... sort of). You will be
> able to specify either the usernamd or the userID. Consequently,
> I suppose we should mandate that usernames cannot be composed
> of only numbers. Seems like a good idea, anyway. Or, perhaps, we
> should require named parameters here. Perhaps that's a better idea.

Calling login() with no params causes it to look in the environment
for cookies, and use them for login information. This will be the way
that it is most frequently used, I expect, as a quasi-authentication.

-- 
Rich Bowen
Author: Apache Server Unleashed - www.apacheunleashed.com
Director of Web Application Development - http://www.cre8tivegroup.com/

[Iamb-dev] IAMB OO

[Rich B. <rb...@rc...>]

The more I work on this code, and the more bugs I fix, the more I wonder
how I ever thought about this stuff in a non-OO manner. This code could
be so much more pleasant.

It would seem that if things continue the way that they are going, the
main branch of the IAMB code is going to become the next major version
before the dev branch gets any changes done! :-)

Anyways, I should have a User object, and an article object, pretty
soon. I might be going about things a little hackish, just because I'm
trying to keep some code functional while I change the undergirdings.
I'm hoping for minimal database changes while I go, but I've already
made one. Hope everyone caught that last week.

Just thought you should know where I'm going with this. It's the obvious
direction, but it's coming a little sooner than I had anticipated. If I
want to make any progress without going completely nuts, I have to go OO
with things.

I'll be posting a synopsis of how I expect the user/login stuff to work
RSN. Perhaps tomrrow.

-- 
Rich Bowen
Author: Apache Server Unleashed - www.apacheunleashed.com
Director of Web Application Development - http://www.cre8tivegroup.com/

[Iamb-dev] [Bug #126266] Editing my article makes it unread for me

[<no...@so...>]

Bug #126266, was updated on 2000-Dec-18 19:35
Here is a current snapshot of the bug.

Project: IAMB -Iamb A Message Board
Category: None
Status: Closed
Resolution: None
Bug Group: None
Priority: 7
Submitted by: rbowen
Assigned to : rbowen
Summary: Editing my article makes it unread for me

Details: When I edit an article, it should not show up as unread in my listings, but alas it does. Presumably if I wrote it, I also read it. Although, with some people ...

Follow-Ups:

Date: 2000-Dec-18 20:15
By: rbowen

Comment:
Index: index.cgi
===================================================================
RCS file: /cvsroot/iamb/iamb/index.cgi,v
retrieving revision 1.25
diff -u -r1.25 index.cgi
--- index.cgi   2000/12/12 03:25:38     1.25
+++ index.cgi   2000/12/19 04:13:27
@@ -532,6 +532,16 @@
                                ");
        $sth->execute;
        }
+
+     # Get the unread marks right
+     $iamb->UpdateUnread($form->{forum}, $user->{ID});
+     $sth = $iamb->dbh->prepare("delete from ". $iamb->unread . "
+          where userID = $user->{ID}
+          and articleID = $form->{ID}
+          and marktype = 1
+          ");
+     $sth->execute;
+     $sth->finish;

        $form->{article} = $form->{ID};
        ($template, $details) = Article($iamb);


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=126266&group_id=14613

[Iamb-dev] Community::User

[Rich B. <rb...@rc...>]

Since diffs are temporarily borked, I thought I'd run this API by you on
the list. See attatched POD.

-- 
Rich Bowen
Author: Apache Server Unleashed - www.apacheunleashed.com
Director of Web Application Development - http://www.cre8tivegroup.com/

[Iamb-dev] [Bug #126266] Editing my article makes it unread for me

[<no...@so...>]

Bug #126266, was updated on 2000-Dec-18 19:35
Here is a current snapshot of the bug.

Project: IAMB -Iamb A Message Board
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: rbowen
Assigned to : rbowen
Summary: Editing my article makes it unread for me

Details: When I edit an article, it should not show up as unread in my listings, but alas it does. Presumably if I wrote it, I also read it. Although, with some people ...

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=126266&group_id=14613

Re: [Iamb-dev] Community::User

[Rich B. <rb...@rc...>]

> I'd change the syntax from
> 
> $user_object = Community::User->login('username', 'password');
> 
> to
> 
> $user_object = Community::User->login(USER=>'username',
>                                     PASSWORD=>'password');
> 
> so that we aren't stuck with defining parameters by their order
> in the calling routine. I'd be sufficiently outrageously happy
> with that.

Yes. I'm sorry. That's what I meant. I'm very very pro named parameters.

-- 
Rich Bowen
Author: Apache Server Unleashed - www.apacheunleashed.com
Director of Web Application Development - http://www.cre8tivegroup.com/

Re: [Iamb-dev] Community::User

[Ken R. <kr...@qx...>]

Rich Bowen wrote:
> 
> > My only quibble would then be with the word "load". To me,
> > that would be loading an existing variable. On the other
> > hand, the method could be written in such a way that it would
> > (in this order):
> >
> > #1) Use parameters passed in, if there are any;
> > #2) Use existing values, if there are any;
> > #3) Use defaults for any required values that still are not
> > defined.
> >
> > That would make me happy, but somewhat less than outrageously so.
> 
> Perhaps I missed something along the way. I'll go back and look. But
> what is it that would make you outrageously happy? Is there a word that
> works better for you than load()? I'm not at all tied to that, although
> I would like to have a word that makes sense in the context. Which is
> that I am loading from the database details about an existing user,
> which I know only by login and (possibly) password. So I want something
> like:
> 
> $user_object = methodname Community::User ('username', 'password');
> 
> Now, if all of the above get rolled into one method which just knows
> what to do, that's even better. If calling it 'new' makes you
> outrageously happy, I can't say that I feel strongly about it one way or
> the other. It is, after all, returning a new object. I do, however, tend
> to have a nagging desire to want to distinguish between creating a new
> user accound ("register") and getting details about an existing user
> account out of the database ("login", perhaps).

login() would make more sense to me, or maybe verify_user().

I agree that register() would be good for creating a new account, and
new() there would be very confusing.

I'd change the syntax from

$user_object = Community::User->login('username', 'password');

to

$user_object = Community::User->login(USER=>'username',
				    PASSWORD=>'password');

so that we aren't stuck with defining parameters by their order
in the calling routine. I'd be sufficiently outrageously happy
with that.

-- Ken