Why is it erasing 'border:', but leaving everything else?
thanks;
-rob.
From dirk at haun-online.de Wed Jan 26 13:58:26 2005
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 26 Jan 2005 19:58:26 +0100
Subject: [geeklog-devel] Allowable HTML and 'style'
In-Reply-To: <376413180ac40990e686b861607c9cb4@macosxhints.com>
References: <376413180ac40990e686b861607c9cb4@macosxhints.com>
Message-ID: <20050126185826.26227@smtp.haun-online.de>
Rob,
>Why is it erasing 'border:', but leaving everything else?
That's a known bug /misbehaving feature in the kses filter: It thinks
it's a protocol and since it's not one of those that are allowed, it
removes it. You can, apparently, play tricks with javascript: in CSS and
it's trying to protect you from that ...
Workaround: Put your definitions in a class and use that.
bye, Dirk
--
http://www.haun-online.de/
http://www.tinyweb.de/
From dirk at haun-online.de Wed Jan 26 14:23:02 2005
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 26 Jan 2005 20:23:02 +0100
Subject: [geeklog-devel] SpamX documentation
Message-ID: <20050126192303.14076@smtp.haun-online.de>
I did some house cleaning on the SpamX documentation. There was a second
spamx.html in the plugin's directory, in addition to the one in docs. I
somehow synced the two and then only kept the one in docs. I've also
updated the Developer.txt file in the plugin's directory.
Tom, could you have a look at those two files (in CVS), please, to see if
they're up to date now?
And, to answer that question from lib-comment.php:
// FIXME: is 'plugin=spamx' needed here?
echo COM_refresh($_CONF['site_url'] . '/index.php?
msg='.$result.'&plugin=spamx');
Yes, Vinny, that parameter is needed ;-) That's something Blaine
introduced in 1.3.10 (I think) so that plugins can display their own messages.
Btw, I've also added Tom's two IP-based filtering modules to CVS.
bye, Dirk
--
http://www.haun-online.de/
http://www.handful-of-sparks.de/
From vfuria at gmail.com Wed Jan 26 14:37:15 2005
From: vfuria at gmail.com (Vincent Furia)
Date: Wed, 26 Jan 2005 14:37:15 -0500
Subject: [geeklog-devel] SpamX documentation
In-Reply-To: <20050126192303.14076@smtp.haun-online.de>
References: <20050126192303.14076@smtp.haun-online.de>
Message-ID: <8319e2d605012611377dfc39f4@mail.gmail.com>
On Wed, 26 Jan 2005 20:23:02 +0100, Dirk Haun
wrote:
>
> And, to answer that question from lib-comment.php:
>
> // FIXME: is 'plugin=spamx' needed here?
> echo COM_refresh($_CONF['site_url'] . '/index.php?
> msg='.$result.'&plugin=spamx');
>
> Yes, Vinny, that parameter is needed ;-) That's something Blaine
> introduced in 1.3.10 (I think) so that plugins can display their own messages.
But what happens if another plugin uses the PLG_checkforSpam API to
remove a post? With spamx hardcoded in the refresh link, the error
message may be problematic... Perhaps having the plugin API return a
HTML string (i.e. a redirect) instead of having Geeklog decide where
to refresh to would be a better solution?
Actually there is another problem with the entire block of code:
// Let plugins have a chance to check for SPAM
$result = PLG_checkforSpam($comment, $_CONF['spamx']); // <-- SPAMX
// Now check the result and redirect to index.php if spam action was taken
if ($result > 0) {
// notice no return value here to prevent spam based denail of
service attack
// FIXME: is 'plugin=spamx' needed here?
echo COM_refresh($_CONF['site_url'] .
'/index.php?msg='.$result.'&plugin=spamx'); // <-- SPAMX
exit;
}
Notice the two references to spamx (the refresh and $_CONF['spamx']),
another plugin would have a lot of trouble using this. I think we
should generalize this so other plugin could (conceivably) use it.
-Vinny
From dirk at haun-online.de Wed Jan 26 14:55:48 2005
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 26 Jan 2005 20:55:48 +0100
Subject: [geeklog-devel] SpamX documentation
In-Reply-To: <8319e2d605012611377dfc39f4@mail.gmail.com>
References: <8319e2d605012611377dfc39f4@mail.gmail.com>
Message-ID: <20050126195548.24738@smtp.haun-online.de>
Vinny,
>Notice the two references to spamx (the refresh and $_CONF['spamx']),
>another plugin would have a lot of trouble using this.
You mean another plugin that would like to filter spam?
>I think we
>should generalize this so other plugin could (conceivably) use it.
The problem here is that you may have one plugin calling another. I know
Blaine and Tom struggled with this for a while and this is what they came
up with.
If you have a better solution, let's hear it ...
bye, Dirk
--
http://www.haun-online.de/
http://geeklog.info/
From tomw at pigstye.net Wed Jan 26 15:25:23 2005
From: tomw at pigstye.net (Tom Willett)
Date: Wed, 26 Jan 2005 15:25:23 -0500
Subject: [geeklog-devel] SpamX documentation
In-Reply-To: <20050126192303.14076@smtp.haun-online.de>
References: <20050126192303.14076@smtp.haun-online.de>
Message-ID: <41F7FCB3.6070802@pigstye.net>
On 1/26/2005 2:23 PM, Dirk Haun wrote:
>I did some house cleaning on the SpamX documentation. There was a second
>spamx.html in the plugin's directory, in addition to the one in docs. I
>somehow synced the two and then only kept the one in docs. I've also
>updated the Developer.txt file in the plugin's directory.
>
>Tom, could you have a look at those two files (in CVS), please, to see if
>they're up to date now?
>
>And, to answer that question from lib-comment.php:
>
> // FIXME: is 'plugin=spamx' needed here?
> echo COM_refresh($_CONF['site_url'] . '/index.php?
>msg='.$result.'&plugin=spamx');
>
>Yes, Vinny, that parameter is needed ;-) That's something Blaine
>introduced in 1.3.10 (I think) so that plugins can display their own messages.
>
>Btw, I've also added Tom's two IP-based filtering modules to CVS.
>
>bye, Dirk
>
>
>
>
You caught me at a good time.
Here is an updated spamx.html.
--
Tom Willett
tomw at pigstye.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dirk at haun-online.de Wed Jan 26 16:15:56 2005
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 26 Jan 2005 22:15:56 +0100
Subject: [geeklog-devel] SpamX documentation
In-Reply-To: <41F7FCB3.6070802@pigstye.net>
References: <41F7FCB3.6070802@pigstye.net>
Message-ID: <20050126211556.5583@smtp.haun-online.de>
Tom Willett wrote:
>Here is an updated spamx.html.
... and it's in CVS now. Thanks, Tom :-)
bye, Dirk
--
http://www.haun-online.de/
http://www.haun.info/
From tony at tonybibbs.com Wed Jan 26 22:24:59 2005
From: tony at tonybibbs.com (Tony Bibbs)
Date: Wed, 26 Jan 2005 21:24:59 -0600
Subject: [geeklog-devel] HTTP_Session2
Message-ID: <41F85F0B.8070508@tonybibbs.com>
Thanks to help from Justin, I have some alpha code done of
HTTP_Session2. Right now it only supports Creole and, to be nice, I
have to get the other containers working (PEAR::DB, PEAR::MDB, etc).
Anyway, as soon as that is done, I'll be making code changes to
Geeklog-2 to start using it.
I wouldn't suppose anybody would have the hardware and ability to run
load balance Geeklog-2 on two or more web servers, would they?
--Tony
From tony at tonybibbs.com Thu Jan 27 11:04:38 2005
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 27 Jan 2005 10:04:38 -0600
Subject: [geeklog-devel] KSES and PHP5
Message-ID: <41F91116.50403@tonybibbs.com>
This is just an FYI. I'll be ripping out the current class and
replacing it with this. The current one is CVS was my attempt to port
it but I'm sure they are doing a better job of maintaining and testing
it so no need in assuming that responsibilty.
--Tony
-------- Original Message --------
Subject: {Filename?} Re: Kses for PHP5?
Date: Thu, 27 Jan 2005 10:04:16 -0600 (CST)
From: Chaos.org Webmaster
Reply-To: webfella at chaos.org
To: Tony Bibbs
Warning: This message has had one or more attachments removed
Warning: (php5.class.kses.php).
Warning: Please read the "yoursite-Attachment-Warning.txt" attachment(s) for more information.
| Sorry for the delay. Work keeps getting in myway ;-)
No problem. BTDT.
| I'll be giving your PHP5 version a whirl here pretty quick.
| I'll fire any bugs/feedback, etc to you soon.
Ulf and I are still working on a few things in the process of backcoding
some of the E_STRICT changes I made, along with me waiting for his 0.3
improvements/modifications. So there's no official package to download.
However, I'm sending the PHP5 class version as an attachment. Nothing's
been broken in terms of funtionality, but a couple of methods have been
deprecated. Also, the name of the class has changed from kses to kses5
since I'll be maintaining the PHP4 version (kses4) as well for the
forseeable future. If you're familiar with PhpDocumentor
(http://www.phpdoc.org/), you can create the docs, and see for yourself,
or you can read the comments in the source code.
Hopefully, the next release will have a stronger set of documentation.
Any feedback appreciated,
Richard
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: yoursite-Attachment-Warning.txt
URL:
From vfuria at gmail.com Thu Jan 27 11:18:31 2005
From: vfuria at gmail.com (Vincent Furia)
Date: Thu, 27 Jan 2005 11:18:31 -0500
Subject: [geeklog-devel] PLG_commentPreSave
Message-ID: <8319e2d605012708186e8a3a86@mail.gmail.com>
Trying to understand the entire comment system a bit better as I
refactor all this code...
What is the difference between PLG_commentPreSave and
PLG_checkForSpam? Are both really needed? Is PLG_commentPreSave even
used (or planned to be used) in any plugins. Can people see a need
for it not filled by PLG_checkForSpam?
Thanks,
Vinny
P.S. I'm almost done, just need to take care of this issue and then
work on plugin documentation.
From tony at tonybibbs.com Thu Jan 27 11:22:50 2005
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 27 Jan 2005 10:22:50 -0600
Subject: [geeklog-devel] PLG_commentPreSave
In-Reply-To: <8319e2d605012708186e8a3a86@mail.gmail.com>
References: <8319e2d605012708186e8a3a86@mail.gmail.com>
Message-ID: <41F9155A.8030007@tonybibbs.com>
Only point I have is on semantics. I know it's only wording so take
this feedback for what it is worth.
Seems PLG_commentPreSave make more sense in how it might be used in a
broader sense. PLG_checkForSpam, IMHO, is too specific. I can see how
people might dream up a need to do some processing before a comment is
saved that may be completely unrelated to spam.
--Tony
Vincent Furia wrote:
>Trying to understand the entire comment system a bit better as I
>refactor all this code...
>
>What is the difference between PLG_commentPreSave and
>PLG_checkForSpam? Are both really needed? Is PLG_commentPreSave even
>used (or planned to be used) in any plugins. Can people see a need
>for it not filled by PLG_checkForSpam?
>
>Thanks,
>Vinny
>
>P.S. I'm almost done, just need to take care of this issue and then
>work on plugin documentation.
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>
From geeklog at langfamily.ca Thu Jan 27 12:00:27 2005
From: geeklog at langfamily.ca (Blaine Lang)
Date: Thu, 27 Jan 2005 12:00:27 -0500
Subject: [geeklog-devel] PLG_commentPreSave
References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com>
Message-ID: <023501c50491$b3a79300$650a10ac@XPBL2>
Vincent Furia wrote:
>What is the difference between PLG_commentPreSave and
>PLG_checkForSpam? Are both really needed?
Dirk, Tom and I talked about this when implementing the new SPAMX API's and
decided that it was best to still have a Non-Spamx API to allow other
plugins to add any other comment related filtering or handling that may be
required.
Blaine
----- Original Message -----
From: "Tony Bibbs"
To:
Sent: Thursday, January 27, 2005 11:22 AM
Subject: Re: [geeklog-devel] PLG_commentPreSave
Only point I have is on semantics. I know it's only wording so take
this feedback for what it is worth.
Seems PLG_commentPreSave make more sense in how it might be used in a
broader sense. PLG_checkForSpam, IMHO, is too specific. I can see how
people might dream up a need to do some processing before a comment is
saved that may be completely unrelated to spam.
--Tony
Vincent Furia wrote:
>Trying to understand the entire comment system a bit better as I
>refactor all this code...
>
>What is the difference between PLG_commentPreSave and
>PLG_checkForSpam? Are both really needed? Is PLG_commentPreSave even
>used (or planned to be used) in any plugins. Can people see a need
>for it not filled by PLG_checkForSpam?
>
>Thanks,
>Vinny
>
>P.S. I'm almost done, just need to take care of this issue and then
>work on plugin documentation.
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel
From geeklog at langfamily.ca Thu Jan 27 12:03:39 2005
From: geeklog at langfamily.ca (Blaine Lang)
Date: Thu, 27 Jan 2005 12:03:39 -0500
Subject: [geeklog-devel] HTTP_Session2
References: <41F85F0B.8070508@tonybibbs.com>
Message-ID: <024101c50492$25f72f60$650a10ac@XPBL2>
Tony,
We had added SESSION support for GL 1.3.10 and then had to pull it out due
to issues that were appearing from testers.
I wonder if your new version once you have support for non-creole containers
will allow us to revisit the 1.3.X use of SESSIONS again.
Blaine
----- Original Message -----
From: "Tony Bibbs"
To:
Sent: Wednesday, January 26, 2005 10:24 PM
Subject: [geeklog-devel] HTTP_Session2
Thanks to help from Justin, I have some alpha code done of
HTTP_Session2. Right now it only supports Creole and, to be nice, I
have to get the other containers working (PEAR::DB, PEAR::MDB, etc).
Anyway, as soon as that is done, I'll be making code changes to
Geeklog-2 to start using it.
I wouldn't suppose anybody would have the hardware and ability to run
load balance Geeklog-2 on two or more web servers, would they?
--Tony
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel
From tony at tonybibbs.com Thu Jan 27 12:07:25 2005
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 27 Jan 2005 11:07:25 -0600
Subject: [geeklog-devel] HTTP_Session2
In-Reply-To: <024101c50492$25f72f60$650a10ac@XPBL2>
References: <41F85F0B.8070508@tonybibbs.com> <024101c50492$25f72f60$650a10ac@XPBL2>
Message-ID: <41F91FCD.7020704@tonybibbs.com>
Being I'm the 'main' maintainer of HTTP_Session2 we have the ability to
tweak, fix, improve anything.
Do you remember the specific issues? This would be the time to revisit
that.
--Tony
Blaine Lang wrote:
>Tony,
>
>We had added SESSION support for GL 1.3.10 and then had to pull it out due
>to issues that were appearing from testers.
>I wonder if your new version once you have support for non-creole containers
>will allow us to revisit the 1.3.X use of SESSIONS again.
>
>Blaine
>----- Original Message -----
>From: "Tony Bibbs"
>To:
>Sent: Wednesday, January 26, 2005 10:24 PM
>Subject: [geeklog-devel] HTTP_Session2
>
>
>Thanks to help from Justin, I have some alpha code done of
>HTTP_Session2. Right now it only supports Creole and, to be nice, I
>have to get the other containers working (PEAR::DB, PEAR::MDB, etc).
>
>Anyway, as soon as that is done, I'll be making code changes to
>Geeklog-2 to start using it.
>
>I wouldn't suppose anybody would have the hardware and ability to run
>load balance Geeklog-2 on two or more web servers, would they?
>
>--Tony
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>
From vfuria at gmail.com Thu Jan 27 12:26:52 2005
From: vfuria at gmail.com (Vincent Furia)
Date: Thu, 27 Jan 2005 12:26:52 -0500
Subject: [geeklog-devel] PLG_commentPreSave
In-Reply-To: <023501c50491$b3a79300$650a10ac@XPBL2>
References: <8319e2d605012708186e8a3a86@mail.gmail.com>
<41F9155A.8030007@tonybibbs.com>
<023501c50491$b3a79300$650a10ac@XPBL2>
Message-ID: <8319e2d6050127092631f88608@mail.gmail.com>
On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang wrote:
>
> Dirk, Tom and I talked about this when implementing the new SPAMX API's and
> decided that it was best to still have a Non-Spamx API to allow other
> plugins to add any other comment related filtering or handling that may be
> required.
>
I'm still confused as to why different APIs are needed since they
appear to do the same thing. They are even called one after the
other.
I think one plugin call would be enough, something like:
PLG_commentPreSave(title, comment, ...) and have it return HTML to
output if there is an error (this can include a COM_refresh) otherwise
just return 0. If I can work it into the plugin API to pass the
comment and title by reference, plugins could modify those and still
return a "success" status.
Thoughts?
-Vinny
From tony at tonybibbs.com Thu Jan 27 13:22:48 2005
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 27 Jan 2005 12:22:48 -0600
Subject: [geeklog-devel] PLG_commentPreSave
In-Reply-To: <8319e2d6050127092631f88608@mail.gmail.com>
References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> <023501c50491$b3a79300$650a10ac@XPBL2> <8319e2d6050127092631f88608@mail.gmail.com>
Message-ID: <41F93178.6000206@tonybibbs.com>
Right, Vinny's question is why couldn't the spamx plugin just have used
PLG_commentPreSave then?
--Tony
Vincent Furia wrote:
>On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang wrote:
>
>
>>Dirk, Tom and I talked about this when implementing the new SPAMX API's and
>>decided that it was best to still have a Non-Spamx API to allow other
>>plugins to add any other comment related filtering or handling that may be
>>required.
>>
>>
>>
>I'm still confused as to why different APIs are needed since they
>appear to do the same thing. They are even called one after the
>other.
>
>I think one plugin call would be enough, something like:
>
>PLG_commentPreSave(title, comment, ...) and have it return HTML to
>output if there is an error (this can include a COM_refresh) otherwise
>just return 0. If I can work it into the plugin API to pass the
>comment and title by reference, plugins could modify those and still
>return a "success" status.
>
>Thoughts?
>
>-Vinny
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>
From geeklog at langfamily.ca Thu Jan 27 14:07:06 2005
From: geeklog at langfamily.ca (Blaine Lang)
Date: Thu, 27 Jan 2005 14:07:06 -0500
Subject: [geeklog-devel] PLG_commentPreSave
References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> <023501c50491$b3a79300$650a10ac@XPBL2> <8319e2d6050127092631f88608@mail.gmail.com> <41F93178.6000206@tonybibbs.com>
Message-ID: <08d301c504a3$64b1ee50$650a10ac@XPBL2>
Uh ok - went back through my emails and it was last Sept/Oct that I worked
on this.
Here was the email I sent to Dirk that raised this very question when I was
adding the spamx API's.
Have a read and see if this made sense.
-----
I'm wondering if there is a reason to preserve the new API that Tony added
to support the SPAMX feature in comments. Tony wrote a API that is very
generic and can be used for other purposes. It's passed a lot of PARMS which
would be useful by a Plugin if it needed to do something with that coment.
function PLG_commentPreSave($uid, $title, $comment, $sid, $pid, $type,
$postmode)
The SPAMX API now only needs 2 parms ($text and $action)
Tom's first idea was to change the PLG_commentPreSave API and I'm wondering
if we should keep it. This API is only called from comment.php - since that
is the only un-moderated way to add content to stories. But if we really
want a generic hook then it should be for new stories as well as comments I
think. I don't quite have the application in mind of how this would be used
other then for parsing bbcode tags or wiki language. In both those cases, I
think only the textual content would need to be passed as well.
So I'm not sure what to do with the PLG_commentPreSave API.
I'm thinking of adding a new PLG_checkforSpam($content,$action) API and that
would be called from comment.php. The PLG_checkforSpam is a wrapper to call
the plugin_checkforSpam_spamx()
The other idea is to add the call to plugin_checkforSpam_spamx in the
PLG_commentPreSave() so that it will be called plus what ever plugin related
functions that may be available.
Sorry to make this sound more complex - it's the current API and what to do
with it that make me stop and ask.
Blaine
------
----- Original Message -----
From: "Tony Bibbs"
To:
Sent: Thursday, January 27, 2005 1:22 PM
Subject: Re: [geeklog-devel] PLG_commentPreSave
Right, Vinny's question is why couldn't the spamx plugin just have used
PLG_commentPreSave then?
--Tony
Vincent Furia wrote:
>On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang
>wrote:
>
>
>>Dirk, Tom and I talked about this when implementing the new SPAMX API's
>>and
>>decided that it was best to still have a Non-Spamx API to allow other
>>plugins to add any other comment related filtering or handling that may be
>>required.
>>
>>
>>
>I'm still confused as to why different APIs are needed since they
>appear to do the same thing. They are even called one after the
>other.
>
>I think one plugin call would be enough, something like:
>
>PLG_commentPreSave(title, comment, ...) and have it return HTML to
>output if there is an error (this can include a COM_refresh) otherwise
>just return 0. If I can work it into the plugin API to pass the
>comment and title by reference, plugins could modify those and still
>return a "success" status.
>
>Thoughts?
>
>-Vinny
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel
From tony at tonybibbs.com Thu Jan 27 14:28:17 2005
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 27 Jan 2005 13:28:17 -0600
Subject: [geeklog-devel] PLG_commentPreSave
In-Reply-To: <08d301c504a3$64b1ee50$650a10ac@XPBL2>
References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> <023501c50491$b3a79300$650a10ac@XPBL2> <8319e2d6050127092631f88608@mail.gmail.com> <41F93178.6000206@tonybibbs.com> <08d301c504a3$64b1ee50$650a10ac@XPBL2>
Message-ID: <41F940D1.1070101@tonybibbs.com>
Hrm, k I see. So the question for me is do we really need the SPAMx
function in the API at all. What's wrong with exposing the checkSpam in
lib-common.php (or some other library)? Seems like this method (check
for spam) isn't an API specific thing, it is a feature that we would
like to expose to other plugins.
Thus, I say it would be up to the plugin author to explicitly check for
spam from within their own appropriate methods. Am I missing anything?
--Tony
Blaine Lang wrote:
>Uh ok - went back through my emails and it was last Sept/Oct that I worked
>on this.
>Here was the email I sent to Dirk that raised this very question when I was
>adding the spamx API's.
>
>Have a read and see if this made sense.
>
>-----
>I'm wondering if there is a reason to preserve the new API that Tony added
>to support the SPAMX feature in comments. Tony wrote a API that is very
>generic and can be used for other purposes. It's passed a lot of PARMS which
>would be useful by a Plugin if it needed to do something with that coment.
>
>function PLG_commentPreSave($uid, $title, $comment, $sid, $pid, $type,
>$postmode)
>
>The SPAMX API now only needs 2 parms ($text and $action)
>
>Tom's first idea was to change the PLG_commentPreSave API and I'm wondering
>if we should keep it. This API is only called from comment.php - since that
>is the only un-moderated way to add content to stories. But if we really
>want a generic hook then it should be for new stories as well as comments I
>think. I don't quite have the application in mind of how this would be used
>other then for parsing bbcode tags or wiki language. In both those cases, I
>think only the textual content would need to be passed as well.
>
>So I'm not sure what to do with the PLG_commentPreSave API.
>
>I'm thinking of adding a new PLG_checkforSpam($content,$action) API and that
>would be called from comment.php. The PLG_checkforSpam is a wrapper to call
>the plugin_checkforSpam_spamx()
>
>The other idea is to add the call to plugin_checkforSpam_spamx in the
>PLG_commentPreSave() so that it will be called plus what ever plugin related
>functions that may be available.
>
>Sorry to make this sound more complex - it's the current API and what to do
>with it that make me stop and ask.
>
>Blaine
>------
>
>----- Original Message -----
>From: "Tony Bibbs"
>To:
>Sent: Thursday, January 27, 2005 1:22 PM
>Subject: Re: [geeklog-devel] PLG_commentPreSave
>
>
>Right, Vinny's question is why couldn't the spamx plugin just have used
>PLG_commentPreSave then?
>
>--Tony
>
>Vincent Furia wrote:
>
>
>
>>On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang
>>wrote:
>>
>>
>>
>>
>>>Dirk, Tom and I talked about this when implementing the new SPAMX API's
>>>and
>>>decided that it was best to still have a Non-Spamx API to allow other
>>>plugins to add any other comment related filtering or handling that may be
>>>required.
>>>
>>>
>>>
>>>
>>>
>>I'm still confused as to why different APIs are needed since they
>>appear to do the same thing. They are even called one after the
>>other.
>>
>>I think one plugin call would be enough, something like:
>>
>>PLG_commentPreSave(title, comment, ...) and have it return HTML to
>>output if there is an error (this can include a COM_refresh) otherwise
>>just return 0. If I can work it into the plugin API to pass the
>>comment and title by reference, plugins could modify those and still
>>return a "success" status.
>>
>>Thoughts?
>>
>>-Vinny
>>_______________________________________________
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
>>http://lists.geeklog.net/listinfo/geeklog-devel
>>
>>
>>
>>
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>
From tony at tonybibbs.com Thu Jan 27 14:31:56 2005
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 27 Jan 2005 13:31:56 -0600
Subject: [geeklog-devel] PLG_commentPreSave
In-Reply-To: <41F940D1.1070101@tonybibbs.com>
References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> <023501c50491$b3a79300$650a10ac@XPBL2> <8319e2d6050127092631f88608@mail.gmail.com> <41F93178.6000206@tonybibbs.com> <08d301c504a3$64b1ee50$650a10ac@XPBL2> <41F940D1.1070101@tonybibbs.com>
Message-ID: <41F941AC.1020004@tonybibbs.com>
This also brings up the issue of plugin dependencies. We have this in
mind for GL2 on how to have some plugins either require or optionally
use features from other plugins. That's essentially what we want.
After I thought about the message below I sent I realized we can't
assume the spamx plugin is installed (even if it is a plugin). Seems
like an elegant fix might not be possible with the current paradigm.
--Tony
Tony Bibbs wrote:
> Hrm, k I see. So the question for me is do we really need the SPAMx
> function in the API at all. What's wrong with exposing the checkSpam
> in lib-common.php (or some other library)? Seems like this method
> (check for spam) isn't an API specific thing, it is a feature that we
> would like to expose to other plugins.
>
> Thus, I say it would be up to the plugin author to explicitly check
> for spam from within their own appropriate methods. Am I missing
> anything?
>
> --Tony
>
> Blaine Lang wrote:
>
>> Uh ok - went back through my emails and it was last Sept/Oct that I
>> worked on this.
>> Here was the email I sent to Dirk that raised this very question when
>> I was adding the spamx API's.
>>
>> Have a read and see if this made sense.
>>
>> -----
>> I'm wondering if there is a reason to preserve the new API that Tony
>> added to support the SPAMX feature in comments. Tony wrote a API that
>> is very generic and can be used for other purposes. It's passed a lot
>> of PARMS which would be useful by a Plugin if it needed to do
>> something with that coment.
>>
>> function PLG_commentPreSave($uid, $title, $comment, $sid, $pid,
>> $type, $postmode)
>>
>> The SPAMX API now only needs 2 parms ($text and $action)
>>
>> Tom's first idea was to change the PLG_commentPreSave API and I'm
>> wondering if we should keep it. This API is only called from
>> comment.php - since that is the only un-moderated way to add content
>> to stories. But if we really want a generic hook then it should be
>> for new stories as well as comments I think. I don't quite have the
>> application in mind of how this would be used other then for parsing
>> bbcode tags or wiki language. In both those cases, I think only the
>> textual content would need to be passed as well.
>>
>> So I'm not sure what to do with the PLG_commentPreSave API.
>>
>> I'm thinking of adding a new PLG_checkforSpam($content,$action) API
>> and that would be called from comment.php. The PLG_checkforSpam is a
>> wrapper to call the plugin_checkforSpam_spamx()
>>
>> The other idea is to add the call to plugin_checkforSpam_spamx in the
>> PLG_commentPreSave() so that it will be called plus what ever plugin
>> related functions that may be available.
>>
>> Sorry to make this sound more complex - it's the current API and what
>> to do with it that make me stop and ask.
>>
>> Blaine
>> ------
>>
>> ----- Original Message ----- From: "Tony Bibbs"
>> To:
>> Sent: Thursday, January 27, 2005 1:22 PM
>> Subject: Re: [geeklog-devel] PLG_commentPreSave
>>
>>
>> Right, Vinny's question is why couldn't the spamx plugin just have used
>> PLG_commentPreSave then?
>>
>> --Tony
>>
>> Vincent Furia wrote:
>>
>>
>>
>>> On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang
>>> wrote:
>>>
>>>
>>>
>>>
>>>> Dirk, Tom and I talked about this when implementing the new SPAMX
>>>> API's and
>>>> decided that it was best to still have a Non-Spamx API to allow other
>>>> plugins to add any other comment related filtering or handling that
>>>> may be
>>>> required.
>>>>
>>>>
>>>>
>>>>
>>>
>>> I'm still confused as to why different APIs are needed since they
>>> appear to do the same thing. They are even called one after the
>>> other.
>>>
>>> I think one plugin call would be enough, something like:
>>>
>>> PLG_commentPreSave(title, comment, ...) and have it return HTML to
>>> output if there is an error (this can include a COM_refresh) otherwise
>>> just return 0. If I can work it into the plugin API to pass the
>>> comment and title by reference, plugins could modify those and still
>>> return a "success" status.
>>>
>>> Thoughts?
>>>
>>> -Vinny
>>> _______________________________________________
>>> geeklog-devel mailing list
>>> geeklog-devel at lists.geeklog.net
>>> http://lists.geeklog.net/listinfo/geeklog-devel
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://lists.geeklog.net/listinfo/geeklog-devel
>>
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://lists.geeklog.net/listinfo/geeklog-devel
>>
>>
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
From geeklog at langfamily.ca Thu Jan 27 14:49:10 2005
From: geeklog at langfamily.ca (Blaine Lang)
Date: Thu, 27 Jan 2005 14:49:10 -0500
Subject: [geeklog-devel] PLG_commentPreSave
References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> <023501c50491$b3a79300$650a10ac@XPBL2> <8319e2d6050127092631f88608@mail.gmail.com> <41F93178.6000206@tonybibbs.com> <08d301c504a3$64b1ee50$650a10ac@XPBL2> <41F940D1.1070101@tonybibbs.com>
Message-ID: <08f901c504a9$453f2f00$650a10ac@XPBL2>
Well I think it is an API feature we want and thus why I created a wrapper
for it.
The API can and will also call any other plugins that have a spam related
function - 'plugin_checkforSpam_' . $pi_name;
If the spamx plugin is not installed then the wrapper returns the data
unchanged and no issues.
We felt this was the best way and left the options open later for other spam
filtering plugins to be used.
Blaine
----- Original Message -----
From: "Tony Bibbs"
To:
Sent: Thursday, January 27, 2005 2:28 PM
Subject: Re: [geeklog-devel] PLG_commentPreSave
Hrm, k I see. So the question for me is do we really need the SPAMx
function in the API at all. What's wrong with exposing the checkSpam in
lib-common.php (or some other library)? Seems like this method (check
for spam) isn't an API specific thing, it is a feature that we would
like to expose to other plugins.
Thus, I say it would be up to the plugin author to explicitly check for
spam from within their own appropriate methods. Am I missing anything?
--Tony
Blaine Lang wrote:
>Uh ok - went back through my emails and it was last Sept/Oct that I worked
>on this.
>Here was the email I sent to Dirk that raised this very question when I was
>adding the spamx API's.
>
>Have a read and see if this made sense.
>
>-----
>I'm wondering if there is a reason to preserve the new API that Tony added
>to support the SPAMX feature in comments. Tony wrote a API that is very
>generic and can be used for other purposes. It's passed a lot of PARMS
>which
>would be useful by a Plugin if it needed to do something with that coment.
>
>function PLG_commentPreSave($uid, $title, $comment, $sid, $pid, $type,
>$postmode)
>
>The SPAMX API now only needs 2 parms ($text and $action)
>
>Tom's first idea was to change the PLG_commentPreSave API and I'm wondering
>if we should keep it. This API is only called from comment.php - since that
>is the only un-moderated way to add content to stories. But if we really
>want a generic hook then it should be for new stories as well as comments I
>think. I don't quite have the application in mind of how this would be used
>other then for parsing bbcode tags or wiki language. In both those cases, I
>think only the textual content would need to be passed as well.
>
>So I'm not sure what to do with the PLG_commentPreSave API.
>
>I'm thinking of adding a new PLG_checkforSpam($content,$action) API and
>that
>would be called from comment.php. The PLG_checkforSpam is a wrapper to call
>the plugin_checkforSpam_spamx()
>
>The other idea is to add the call to plugin_checkforSpam_spamx in the
>PLG_commentPreSave() so that it will be called plus what ever plugin
>related
>functions that may be available.
>
>Sorry to make this sound more complex - it's the current API and what to do
>with it that make me stop and ask.
>
>Blaine
>------
>
>----- Original Message -----
>From: "Tony Bibbs"
>To:
>Sent: Thursday, January 27, 2005 1:22 PM
>Subject: Re: [geeklog-devel] PLG_commentPreSave
>
>
>Right, Vinny's question is why couldn't the spamx plugin just have used
>PLG_commentPreSave then?
>
>--Tony
>
>Vincent Furia wrote:
>
>
>
>>On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang
>>wrote:
>>
>>
>>
>>
>>>Dirk, Tom and I talked about this when implementing the new SPAMX API's
>>>and
>>>decided that it was best to still have a Non-Spamx API to allow other
>>>plugins to add any other comment related filtering or handling that may
>>>be
>>>required.
>>>
>>>
>>>
>>>
>>>
>>I'm still confused as to why different APIs are needed since they
>>appear to do the same thing. They are even called one after the
>>other.
>>
>>I think one plugin call would be enough, something like:
>>
>>PLG_commentPreSave(title, comment, ...) and have it return HTML to
>>output if there is an error (this can include a COM_refresh) otherwise
>>just return 0. If I can work it into the plugin API to pass the
>>comment and title by reference, plugins could modify those and still
>>return a "success" status.
>>
>>Thoughts?
>>
>>-Vinny
>>_______________________________________________
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
>>http://lists.geeklog.net/listinfo/geeklog-devel
>>
>>
>>
>>
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel
From tony at tonybibbs.com Thu Jan 27 15:05:47 2005
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 27 Jan 2005 14:05:47 -0600
Subject: [geeklog-devel] PLG_commentPreSave
In-Reply-To: <08f901c504a9$453f2f00$650a10ac@XPBL2>
References: <8319e2d605012708186e8a3a86@mail.gmail.com> <41F9155A.8030007@tonybibbs.com> <023501c50491$b3a79300$650a10ac@XPBL2> <8319e2d6050127092631f88608@mail.gmail.com> <41F93178.6000206@tonybibbs.com> <08d301c504a3$64b1ee50$650a10ac@XPBL2> <41F940D1.1070101@tonybibbs.com> <08f901c504a9$453f2f00$650a10ac@XPBL2>
Message-ID: <41F9499B.2000707@tonybibbs.com>
That's the argument I guess. I don't want to minimize the importance of
spam filtering but doing it this way essentially implies the use of
spamx. The plugins don't do the check for spam themselves the delegate
that and since it isn't the plugin doing the work I don't quite think
that would fit in an API. In otherwords, if the plugin doesn't
implement the spam check, it's really not an interface. OO purism
aside, I think what we have works and that it'd probably not make much
sense to go in and change things at this point in time.
--Tony
Blaine Lang wrote:
>Well I think it is an API feature we want and thus why I created a wrapper
>for it.
>The API can and will also call any other plugins that have a spam related
>function - 'plugin_checkforSpam_' . $pi_name;
>
>If the spamx plugin is not installed then the wrapper returns the data
>unchanged and no issues.
>
>We felt this was the best way and left the options open later for other spam
>filtering plugins to be used.
>
>Blaine
>----- Original Message -----
>From: "Tony Bibbs"
>To:
>Sent: Thursday, January 27, 2005 2:28 PM
>Subject: Re: [geeklog-devel] PLG_commentPreSave
>
>
>Hrm, k I see. So the question for me is do we really need the SPAMx
>function in the API at all. What's wrong with exposing the checkSpam in
>lib-common.php (or some other library)? Seems like this method (check
>for spam) isn't an API specific thing, it is a feature that we would
>like to expose to other plugins.
>
>Thus, I say it would be up to the plugin author to explicitly check for
>spam from within their own appropriate methods. Am I missing anything?
>
>--Tony
>
>Blaine Lang wrote:
>
>
>
>>Uh ok - went back through my emails and it was last Sept/Oct that I worked
>>on this.
>>Here was the email I sent to Dirk that raised this very question when I was
>>adding the spamx API's.
>>
>>Have a read and see if this made sense.
>>
>>-----
>>I'm wondering if there is a reason to preserve the new API that Tony added
>>to support the SPAMX feature in comments. Tony wrote a API that is very
>>generic and can be used for other purposes. It's passed a lot of PARMS
>>which
>>would be useful by a Plugin if it needed to do something with that coment.
>>
>>function PLG_commentPreSave($uid, $title, $comment, $sid, $pid, $type,
>>$postmode)
>>
>>The SPAMX API now only needs 2 parms ($text and $action)
>>
>>Tom's first idea was to change the PLG_commentPreSave API and I'm wondering
>>if we should keep it. This API is only called from comment.php - since that
>>is the only un-moderated way to add content to stories. But if we really
>>want a generic hook then it should be for new stories as well as comments I
>>think. I don't quite have the application in mind of how this would be used
>>other then for parsing bbcode tags or wiki language. In both those cases, I
>>think only the textual content would need to be passed as well.
>>
>>So I'm not sure what to do with the PLG_commentPreSave API.
>>
>>I'm thinking of adding a new PLG_checkforSpam($content,$action) API and
>>that
>>would be called from comment.php. The PLG_checkforSpam is a wrapper to call
>>the plugin_checkforSpam_spamx()
>>
>>The other idea is to add the call to plugin_checkforSpam_spamx in the
>>PLG_commentPreSave() so that it will be called plus what ever plugin
>>related
>>functions that may be available.
>>
>>Sorry to make this sound more complex - it's the current API and what to do
>>with it that make me stop and ask.
>>
>>Blaine
>>------
>>
>>----- Original Message -----
>>From: "Tony Bibbs"
>>To:
>>Sent: Thursday, January 27, 2005 1:22 PM
>>Subject: Re: [geeklog-devel] PLG_commentPreSave
>>
>>
>>Right, Vinny's question is why couldn't the spamx plugin just have used
>>PLG_commentPreSave then?
>>
>>--Tony
>>
>>Vincent Furia wrote:
>>
>>
>>
>>
>>
>>>On Thu, 27 Jan 2005 12:00:27 -0500, Blaine Lang
>>>wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Dirk, Tom and I talked about this when implementing the new SPAMX API's
>>>>and
>>>>decided that it was best to still have a Non-Spamx API to allow other
>>>>plugins to add any other comment related filtering or handling that may
>>>>be
>>>>required.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>I'm still confused as to why different APIs are needed since they
>>>appear to do the same thing. They are even called one after the
>>>other.
>>>
>>>I think one plugin call would be enough, something like:
>>>
>>>PLG_commentPreSave(title, comment, ...) and have it return HTML to
>>>output if there is an error (this can include a COM_refresh) otherwise
>>>just return 0. If I can work it into the plugin API to pass the
>>>comment and title by reference, plugins could modify those and still
>>>return a "success" status.
>>>
>>>Thoughts?
>>>
>>>-Vinny
>>>_______________________________________________
>>>geeklog-devel mailing list
>>>geeklog-devel at lists.geeklog.net
>>>http://lists.geeklog.net/listinfo/geeklog-devel
>>>
>>>
>>>
>>>
>>>
>>>
>>_______________________________________________
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
>>http://lists.geeklog.net/listinfo/geeklog-devel
>>
>>_______________________________________________
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
>>http://lists.geeklog.net/listinfo/geeklog-devel
>>
>>
>>
>>
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>
From tony at tonybibbs.com Thu Jan 27 15:30:26 2005
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 27 Jan 2005 14:30:26 -0600
Subject: [geeklog-devel] kses PHP5 (actual attachment)
Message-ID: <41F94F62.4060604@tonybibbs.com>
Sorry, my last email didn't include the attachment properly
-------- Original Message --------
Subject: Re: [Fwd: {Filename?} Re: Kses for PHP5?]
Date: Thu, 27 Jan 2005 14:30:20 -0600 (CST)
From: Chaos.org Webmaster
Reply-To: webfella at chaos.org
To: Tony Bibbs
On Thu, 27 Jan 2005, Tony Bibbs wrote:
| The updated php script got filtered out. Please try and resend or get
| me a URL where I can pull it down.
Oops. Let's try this again then.
Richard
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kses.php5
URL:
From tony at tonybibbs.com Thu Jan 27 22:01:39 2005
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 27 Jan 2005 21:01:39 -0600
Subject: [geeklog-devel] GL2 DataAccess Class
In-Reply-To: <8319e2d605011710386432525e@mail.gmail.com>
References: <8319e2d60501162044335efb64@mail.gmail.com> <41EBCC95.7080203@tonybibbs.com> <8319e2d605011706391e0c02d7@mail.gmail.com> <8319e2d6050117070717a15298@mail.gmail.com> <41EBF8C1.8070503@tonybibbs.com> <8319e2d605011710386432525e@mail.gmail.com>
Message-ID: <41F9AB13.3030605@tonybibbs.com>
Vinny, finally getting back to addressing some issues. You are right
here. However, 95% of the inserts, updates and deletes should come
through the use of the domain objects themselves, right? For the
remaining 5%, I think they should just use raw SQL in the named query file.
So to be clear you'd use the PropelDAO::save to do the inserts and
updates and the PropelDAO::delete to delete an object.
Correct me if I am missing something.
--Tony
Vincent Furia wrote:
>I guess I should have been more specific...
>
>There is no way to use criteria to do UPDATEs or DELETEs (criteria
>with INSERTs doesn't make much sense).
>
>It is not clear if what behavior specifying the SQL for UDPATEs,
>DELETEs and INSERTs will be. From reading the code it looks like the
>SQL will be executed, I'm just not sure if the program will stop with
>an error afterwards or throw an exception or just return an empty
>result set.
>
>I haven't tested the DAO code under these conditions, but it looks
>like something that needs be corrected.
>
>-Vinny
>
>
>On Mon, 17 Jan 2005 11:41:21 -0600, Tony Bibbs wrote:
>
>
>>You sure? It's an easy fix to get around that...but seems the
>>updates/deletes should work.
>>
>>--Tony
>>
>>Vincent Furia wrote:
>>
>>
>>
>>>Tony,
>>>
>>>Another issue with the DAO class is that it seems catered to providing
>>>support only for SELECT's. It won't work for doing INSERT's,
>>>UPDATE's, or DELETE's (etc...).
>>>
>>>-Vinny
>>>
>>>
>>>On Mon, 17 Jan 2005 09:39:04 -0500, Vincent Furia wrote:
>>>
>>>
>>>
>>>
>>>>Tony,
>>>>
>>>>Caching between page calls would be great. But even having a static
>>>>variable or something similar to persist between calls to the "find"
>>>>method would be a good start (and probably sufficient for most sites).
>>>>
>>>>-Vinny
>>>>
>>>>
>>>>On Mon, 17 Jan 2005 08:32:53 -0600, Tony Bibbs wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>You mean cache it to memory or to a file. I'd love to cache it to
>>>>>memory but, afaik, it would require php's shared memory which isn't
>>>>>enabled by default.
>>>>>
>>>>>I s'pose if the xml parsing itself if that bad, would could cache a
>>>>>php-friendly data structure to a file.
>>>>>
>>>>>I'm open to this. I just learned how to profile PHP applications this
>>>>>past week so finding poor performing code shouldn't be a problem.
>>>>>
>>>>>--Tony
>>>>>
>>>>>Vincent Furia wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Tony,
>>>>>>
>>>>>>Just looking through the DAO to understand everything it is doing
>>>>>>better. I noticed that the "find" method (and the other methods)
>>>>>>reloads the named queries from the xml file on every call. We should
>>>>>>look for a way to work around this (i.e. somehow cache the DOMXPath
>>>>>>object) so as not to suffer huge penalties for parsing the XML file on
>>>>>>every DB call.
>>>>>>
>>>>>>-Vinny
>>>>>>_______________________________________________
>>>>>>geeklog-devel mailing list
>>>>>>geeklog-devel at lists.geeklog.net
>>>>>>http://lists.geeklog.net/listinfo/geeklog-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>_______________________________________________
>>>>>geeklog-devel mailing list
>>>>>geeklog-devel at lists.geeklog.net
>>>>>http://lists.geeklog.net/listinfo/geeklog-devel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>_______________________________________________
>>>geeklog-devel mailing list
>>>geeklog-devel at lists.geeklog.net
>>>http://lists.geeklog.net/listinfo/geeklog-devel
>>>
>>>
>>>
>>>
>>_______________________________________________
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
>>http://lists.geeklog.net/listinfo/geeklog-devel
>>
>>
>>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>
From tony at tonybibbs.com Thu Jan 27 22:10:29 2005
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 27 Jan 2005 21:10:29 -0600
Subject: [geeklog-devel] Re: Autoincrement on Items
In-Reply-To: <8319e2d605012020456dcdeb72@mail.gmail.com>
References: <8319e2d605012020456dcdeb72@mail.gmail.com>
Message-ID: <41F9AD25.9000208@tonybibbs.com>
So you're saying to keep the 'security by obscurity' we get by using the
sid's? Sounds good, only gripe is what do you do if you are running
Geeklog-2 under more than one webserver?
This is a great question though. Do you depend a bit on obscurity or
depend on your code to do the appropriate security checking. If we want
to stick with some obscurity, is there something beside timestamps we
could do it with?
FYI, I moved this to the -devel list
--Tony
Vincent Furia wrote:
>Tony,
>
>Just was thinking about one concern about allowing visibility
>to/access by the auto increment column of the item table. Currently
>in Geeklog with the pseudo random story ids or manually set ids there
>is no chance of a person knowing that another item exists that they
>might have access to.
>
>But if you can see item ids in Gl2 (auto incrementing), and they can
>see story 5 and link 7 they know that there must be (or have been at
>some point) an item 6.
>
>Just something to keep in mind. Especially if we Gl2 to have the same
>reputation as 1.x.
>
>-Vinny
>
>
From tony at tonybibbs.com Thu Jan 27 22:28:07 2005
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 27 Jan 2005 21:28:07 -0600
Subject: [geeklog-devel] Links to-do
Message-ID: <41F9B147.90408@tonybibbs.com>
Here are some things the links plugin needs to do (in no particular
order). The first thing are things addressed across plugins and should
be addressed in the framework of the 'item' concept. The second list
are things specific to the link plugin.
- allow security defaults to be set for plugins
- email notification when items get accepted, denied, etc
- Disable items
- Rating of items (possibly a seperate plugin)
- Ability to report a broken or inappropriate link
- links give ownership to the submiter. Should work just like stories
in 1.3.x
- Nested categories (handled by current data model)
- Count click-thru's. Should be configurable to turn this off
- Automatic checking that links work (optional cron script or something)
More anybody? Trying to get this all articulate for Kevin. It's worth
noting that I did go through the 1.3.x feature list to generate some of
this. I need to double check it that I didn't miss something.
--Tony
From vfuria at gmail.com Fri Jan 28 11:32:11 2005
From: vfuria at gmail.com (Vincent Furia)
Date: Fri, 28 Jan 2005 11:32:11 -0500
Subject: [geeklog-devel] Links to-do
In-Reply-To: <41F9B147.90408@tonybibbs.com>
References: <41F9B147.90408@tonybibbs.com>
Message-ID: <8319e2d605012808329e57373@mail.gmail.com>
An addition for "accross all plugins":
- submission moderation
> - links give ownership to the submiter. Should work just like stories
> in 1.3.x
I think authorship should always go to the submitter, default
"ownership" in the sense of the ability to control the item (edit,
delete, change permissions) should be configurable in some way (and
probably should not default to the submitter).
-Vinny
On Thu, 27 Jan 2005 21:28:07 -0600, Tony Bibbs wrote:
> Here are some things the links plugin needs to do (in no particular
> order). The first thing are things addressed across plugins and should
> be addressed in the framework of the 'item' concept. The second list
> are things specific to the link plugin.
>
> - allow security defaults to be set for plugins
> - email notification when items get accepted, denied, etc
> - Disable items
> - Rating of items (possibly a seperate plugin)
>
> - Ability to report a broken or inappropriate link
> - links give ownership to the submiter. Should work just like stories
> in 1.3.x
> - Nested categories (handled by current data model)
> - Count click-thru's. Should be configurable to turn this off
> - Automatic checking that links work (optional cron script or something)
>
> More anybody? Trying to get this all articulate for Kevin. It's worth
> noting that I did go through the 1.3.x feature list to generate some of
> this. I need to double check it that I didn't miss something.
>
> --Tony
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
From vfuria at gmail.com Fri Jan 28 14:22:24 2005
From: vfuria at gmail.com (Vincent Furia)
Date: Fri, 28 Jan 2005 14:22:24 -0500
Subject: [geeklog-devel] Deleting comments
In-Reply-To: <8319e2d60501221822155fb96a@mail.gmail.com>
References: <8319e2d60501211534c725830@mail.gmail.com>
<20050122100058.4815@smtp.haun-online.de>
<8319e2d60501221822155fb96a@mail.gmail.com>
Message-ID: <8319e2d6050128112273f701c6@mail.gmail.com>
Well,
I think I'm done. Attached is the new documentation for Plugin
Comment Engine. Note the missing code examples. I was hoping to work
with Blaine, Tom, or one of the other plugin developers that use
comments to get the examples done (and to make sure that the new API
is reasonable).
Note that comment.php passes on requests to delete and save comments
to the plugin which then must call CMT_deleteComment or
CMT_saveComment respectively. That way plugins can do any
pre-save/delete checks and post-save/delete processing that they want.
Besides the major changes to the comment API, I have also refactored
the code in comment.php and consolidated comment related code in
system/lib-comment.php. A code review would be welcome, but at the
least some strenuous testing is required. Here is a list of files
that I ended up touching:
public_html/comment.php
public_html/article.php
public_html/layout/professional/comment/commentbar.thtml
public_html/layout/professional/comment/thread.thtml
public_html/lib-common.php
system/lib-comment.php
system/lib-plugins.php
I'll repeat. Please test this out a bit. I've done a lot of testing,
but the changes are pretty significant.
Thanks,
Vinny
On Sat, 22 Jan 2005 21:22:49 -0500, Vincent Furia wrote:
> With Dirk's blessing to break the comment plugin API. Here is my idea thus far:
>
> CMT_deleteComment and CMT_saveComment will be limited to exactly that
> functionality. They will act no different for articles or polls as
> they would for any other variable. They will return 0 for success or
> >0 for failure (and log the failure to the errorLog). I plan on doing
> something similar for CMT_commentForm.
>
> So there will now be plugin functions for saving and deleting comments
> which should simply call these functions when they are ready (and
> determine that the correct permissions hold, etc).
>
> I'll continue with this approach if it sounds good to everyone. I'd
> especially like some feedback from anyone currently using the plugin
> comment functionality.
>
> -Vinny
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dirk at haun-online.de Fri Jan 28 14:46:07 2005
From: dirk at haun-online.de (Dirk Haun)
Date: Fri, 28 Jan 2005 20:46:07 +0100
Subject: [geeklog-devel] Deleting comments
In-Reply-To: <8319e2d6050128112273f701c6@mail.gmail.com>
References: <8319e2d6050128112273f701c6@mail.gmail.com>
Message-ID: <20050128194607.17387@smtp.haun-online.de>
Vinny,
I'd like to suggest an additional change that shouldn't interfere with
what you did. I think in PLG_commentPreSave (and the plugin's
implementation of that function), $comment should be passed by reference.
That way, plugins could alter the text of the comment, e.g. to replace
smilies or whatever comes to mind.
Thoughts?
>A code review would be welcome, but at the
>least some strenuous testing is required.
geeklog.info is running on the latest CVS code. The site isn't too busy,
but that will provide some testing. I'll also have a look at the code.
bye, Dirk
--
http://www.haun-online.de/
http://www.tinyweb.de/
From vfuria at gmail.com Fri Jan 28 15:03:22 2005
From: vfuria at gmail.com (Vincent Furia)
Date: Fri, 28 Jan 2005 15:03:22 -0500
Subject: [geeklog-devel] Deleting comments
In-Reply-To: <20050128194607.17387@smtp.haun-online.de>
References: <8319e2d6050128112273f701c6@mail.gmail.com>
<20050128194607.17387@smtp.haun-online.de>
Message-ID: <8319e2d6050128120360240d77@mail.gmail.com>
I like the idea. And it seems like it wouldn't be too difficult to
implement. I think only title, comment, and postmode should be passed
by reference though.
-Vinny
On Fri, 28 Jan 2005 20:46:07 +0100, Dirk Haun wrote:
> Vinny,
>
> I'd like to suggest an additional change that shouldn't interfere with
> what you did. I think in PLG_commentPreSave (and the plugin's
> implementation of that function), $comment should be passed by reference.
>
> That way, plugins could alter the text of the comment, e.g. to replace
> smilies or whatever comes to mind.
>
> Thoughts?
>
>
> >A code review would be welcome, but at the
> >least some strenuous testing is required.
>
> geeklog.info is running on the latest CVS code. The site isn't too busy,
> but that will provide some testing. I'll also have a look at the code.
>
> bye, Dirk
>
> --
> http://www.haun-online.de/
> http://www.tinyweb.de/
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
From dirk at haun-online.de Fri Jan 28 15:48:35 2005
From: dirk at haun-online.de (Dirk Haun)
Date: Fri, 28 Jan 2005 21:48:35 +0100
Subject: [geeklog-devel] Deleting comments
In-Reply-To: <8319e2d6050128120360240d77@mail.gmail.com>
References: <8319e2d6050128120360240d77@mail.gmail.com>
Message-ID: <20050128204835.2089@smtp.haun-online.de>
Vincent Furia wrote:
>I think only title, comment, and postmode should be passed
>by reference though.
Makes perfect sense (to me at least ;-)
bye, Dirk
--
http://www.haun-online.de/
http://www.macosx-faq.de/
From tony at tonybibbs.com Fri Jan 28 17:04:37 2005
From: tony at tonybibbs.com (Tony Bibbs)
Date: Fri, 28 Jan 2005 16:04:37 -0600
Subject: [Fwd: Re: [geeklog-devel] GL2 DataAccess Class]
Message-ID: <41FAB6F5.6060304@tonybibbs.com>
Forgot to include the list.
--Tony
-------- Original Message --------
Subject: Re: [geeklog-devel] GL2 DataAccess Class
Date: Fri, 28 Jan 2005 15:46:53 -0600
From: Tony Bibbs
To: vmf at abtech.org
References: <8319e2d60501162044335efb64 at mail.gmail.com>
<41EBCC95.7080203 at tonybibbs.com>
<8319e2d605011706391e0c02d7 at mail.gmail.com>
<8319e2d6050117070717a15298 at mail.gmail.com>
<41EBF8C1.8070503 at tonybibbs.com>
<8319e2d605011710386432525e at mail.gmail.com>
<41F9AB13.3030605 at tonybibbs.com>
<8319e2d605012808432fb2eaeb at mail.gmail.com>
Vincent Furia wrote:
>Tony,
>
>I'm just sending this to you because I'm not sure if this debate
>belongs on the list. Feel free to move it there if you'd like.
>
>
I'll leave it there. I think it is a good debate so that we have a log
of consciously deciding these things.
>It is still undefined what return value should be expected when an
>UPDATE or INSERT is done. Normally the DAO returns an array of
>classes, that doesn't make sense for UPDATEs or INSERTs.
>
>
Updates deletes and inserts would all throw SQLExceptions. So you would
to do a TRY clause around them, and all database calls for that matter.
In otherwords, no return means all went well.
>I'm starting to get more and more concerned with speed issues for GL2.
> Between Creole being generally slow compared to other DBAPIs (by
>itself, not that big of a deal) and Propel loading/includes being very
>time intensive I'm worried adding additional layers are going to slow
>things down.
>
>All these things combine to make me want to reconsider using the DAO.
>We also need to get to the point where we can decide if the Propel
>speed issues are going to be a problem.
>
>
Stripping the DAO doesn't save you anything. The Creole/Propel issues
would still exist. I'm not skirting the issues with the performance. I
fully expect that I/we will have to do true profiling at some point with
this. The real question I think you are asking is just how much
overhead is the DAO and how does that compare to the benefits.
>Also, noting that the February deadline you imposed on yourself is
>looming, I'm curious if you feel work has progressed enough to keep to
>going (I feel that we're making good progress).
>
>
Yeah, I was just thinking about this the other day. I definitely think
things have progressed and that we have a ton of code to show for it.
My only worry is things stagnating again. I'm doing to do my best to
prevent this but getting continuing help from you and Kevin will be just
as important of a factor.
>As I said before, I'm don't feel strongly enough about the DAO to
>force the issue. But I think it warrants reconsideration.
>
>
Maybe we should take the link plugin, implement it fully and do some
serious performance analysis on it before deciding on the DAO. That way
we have only implemented time into one fairly minor plugin and I think
it has enough complexity to give us an idea on performance?
I'm leary of ditching the DAO as it has proven useful in all my apps
here at work. Here we recently went from using raw JDBC to using
Hibernate by simply implementing the new DAO layer and it saved us a
bunch of time. Granted that was Java but without going the DAO layer,
going to Hibernate wouldn't have even have been possible.
--Tony
From vfuria at gmail.com Fri Jan 28 18:15:16 2005
From: vfuria at gmail.com (Vincent Furia)
Date: Fri, 28 Jan 2005 18:15:16 -0500
Subject: [geeklog-devel] Deleting comments
In-Reply-To: <20050128204835.2089@smtp.haun-online.de>
References: <8319e2d6050128120360240d77@mail.gmail.com>
<20050128204835.2089@smtp.haun-online.de>
Message-ID: <8319e2d605012815152694fabf@mail.gmail.com>
Hows that for a feature improvement, only had to add 3 characters.
(Discussed fix checked in).
-Vinny
On Fri, 28 Jan 2005 21:48:35 +0100, Dirk Haun wrote:
> Vincent Furia wrote:
>
> >I think only title, comment, and postmode should be passed
> >by reference though.
>
> Makes perfect sense (to me at least ;-)
>
> bye, Dirk
>
> --
> http://www.haun-online.de/
> http://www.macosx-faq.de/
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
From dirk at haun-online.de Fri Jan 28 18:27:26 2005
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 29 Jan 2005 00:27:26 +0100
Subject: [geeklog-devel] Deleting comments
In-Reply-To: <8319e2d605012815152694fabf@mail.gmail.com>
References: <8319e2d605012815152694fabf@mail.gmail.com>
Message-ID: <20050128232726.7871@smtp.haun-online.de>
Vincent Furia wrote:
>Hows that for a feature improvement, only had to add 3 characters.
>(Discussed fix checked in).
Not bad. Quite a bit of overhead for those 3 characters, though ;-)
bye, Dirk
--
http://www.haun-online.de/
http://www.macosx-faq.de/
From vfuria at gmail.com Sat Jan 29 11:03:23 2005
From: vfuria at gmail.com (Vincent Furia)
Date: Sat, 29 Jan 2005 11:03:23 -0500
Subject: [geeklog-devel] GL2 link?
In-Reply-To: <20050125201153.17691@smtp.haun-online.de>
References: <20050125201153.17691@smtp.haun-online.de>
Message-ID: <8319e2d605012908035ab8da63@mail.gmail.com>
How about linking to
http://wiki.geeklog.net/wiki/index.php/Geeklog_2x_Documentation. I
think that has the most information about GL2 short of the mailing
lists.
-Vinny
On Tue, 25 Jan 2005 21:11:52 +0100, Dirk Haun wrote:
> What's a good link to point people to information about GL2? I've
> restructured the Resources block on geeklog.net a bit and noticed that
> the "Geeklog 2" link there points to the project page, which doesn't have
> a lot to say about GL2.
>
> Maybe someone wants to write a static page that can serve as a portal
> page to the various GL2 resources?
>
> Speaking of which: At one point, we had a GL2 vision document (linked to
> from ) but it's
> long gone. Search engines and human readers are still looking for it,
> though, so I've configured the server to send a "410 Gone". Does someone
> still have that document?
>
> bye, Dirk
>
> --
> http://www.haun-online.de/
> http://www.macosx-faq.de/
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
From dirk at haun-online.de Sat Jan 29 11:18:32 2005
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 29 Jan 2005 17:18:32 +0100
Subject: [geeklog-devel] GL2 link?
In-Reply-To: <8319e2d605012908035ab8da63@mail.gmail.com>
References: <8319e2d605012908035ab8da63@mail.gmail.com>
Message-ID: <20050129161832.31755@smtp.haun-online.de>
Vincent Furia wrote:
>How about linking to
>http://wiki.geeklog.net/wiki/index.php/Geeklog_2x_Documentation
Good idea - completely forgot about the Wiki.
bye, Dirk
--
http://www.haun-online.de/
http://geeklog.info/
From vfuria at gmail.com Sun Jan 30 18:51:37 2005
From: vfuria at gmail.com (Vincent Furia)
Date: Sun, 30 Jan 2005 18:51:37 -0500
Subject: [geeklog-devel] Dynamic Comments...
Message-ID: <8319e2d60501301551495082d9@mail.gmail.com>
Just a prototype right now:
http://vfuria.dyndns.org:8080/article.php?story=geeklog-1.3.10rc2&mode=dynamic
What do people think (try clicking on the blue arrows).
-Vinny
From dirk at haun-online.de Mon Jan 31 15:00:10 2005
From: dirk at haun-online.de (Dirk Haun)
Date: Mon, 31 Jan 2005 21:00:10 +0100
Subject: [geeklog-devel] Dynamic Comments...
In-Reply-To: <8319e2d60501301551495082d9@mail.gmail.com>
References: <8319e2d60501301551495082d9@mail.gmail.com>
Message-ID: <20050131200010.25528@smtp.haun-online.de>
Vinny,
>What do people think (try clicking on the blue arrows).
Nice. When can we expect it in CVS? ;-)
bye, Dirk
--
http://www.haun-online.de/
http://www.haun.info/
From vfuria at gmail.com Mon Jan 31 15:12:18 2005
From: vfuria at gmail.com (Vincent Furia)
Date: Mon, 31 Jan 2005 15:12:18 -0500
Subject: [geeklog-devel] Dynamic Comments...
In-Reply-To: <20050131200010.25528@smtp.haun-online.de>
References: <8319e2d60501301551495082d9@mail.gmail.com>
<20050131200010.25528@smtp.haun-online.de>
Message-ID: <8319e2d6050131121241e8e4a@mail.gmail.com>
I'm working on getting it past the prototype stage. While it (just)
works now, I need to do some modifications to make it integrate
cleanly and to not be embarrassed by my code. Hopefully I'll have it
checked into CVS in the next couple days.
Now, some possible downsides:
1. Each time a person clicks to expand (or collapse) a comment it is a
http request to the server, which means loading lib-common.php, etc.
While the page load for just the comment is relatively fast, server
load could be problem for a really popular server (especially, say,
during a slashdotting).
2. The images I'm using I grabbed from http://kuro5hin.org. I need to
check their licensing to make sure I don't piss anyone off.
3. Of course, as with all good things, theme updates are required.
-Vinny
From dirk at haun-online.de Mon Jan 31 15:20:00 2005
From: dirk at haun-online.de (Dirk Haun)
Date: Mon, 31 Jan 2005 21:20:00 +0100
Subject: [geeklog-devel] Dynamic Comments...
In-Reply-To: <8319e2d6050131121241e8e4a@mail.gmail.com>
References: <8319e2d6050131121241e8e4a@mail.gmail.com>
Message-ID: <20050131202000.25407@smtp.haun-online.de>
Vinny,
>While the page load for just the comment is relatively fast, server
>load could be problem for a really popular server (especially, say,
>during a slashdotting).
I was about to ask about the server load :-)
Any chance this could be made configurable? Comment-heavy sites like
groklaw could then switch it off.
>2. The images I'm using I grabbed from http://kuro5hin.org. I need to
>check their licensing to make sure I don't piss anyone off.
They don't quite fit in with the Professional theme anyway, IMHO. They
look a bit too heavy to me.
I'm sure Simon can come up with something royalty-free ;-)
bye, Dirk
--
http://www.haun-online.de/
http://www.haun.info/
From vfuria at gmail.com Mon Jan 31 15:31:15 2005
From: vfuria at gmail.com (Vincent Furia)
Date: Mon, 31 Jan 2005 15:31:15 -0500
Subject: [geeklog-devel] Dynamic Comments...
In-Reply-To: <20050131202000.25407@smtp.haun-online.de>
References: <8319e2d6050131121241e8e4a@mail.gmail.com>
<20050131202000.25407@smtp.haun-online.de>
Message-ID: <8319e2d605013112316b058ebd@mail.gmail.com>
On Mon, 31 Jan 2005 21:20:00 +0100, Dirk Haun wrote:
> I was about to ask about the server load :-)
>
> Any chance this could be made configurable? Comment-heavy sites like
> groklaw could then switch it off.
>
I'm sure its possible, I'm not sure it it will be easy or pretty
though. The comment modes are kept in the database now, so switching
"off" dynamic comments would at least require an admin to modify the
database and probably a $_CONF variable that would ignore requests for
single comments (outside the geeklog header/footer framework) and
ignore requests for comments to be displayed dynamically.
>
> They don't quite fit in with the Professional theme anyway, IMHO. They
> look a bit too heavy to me.
>
> I'm sure Simon can come up with something royalty-free ;-)
>
Simon: think you can whip something up?
-Vinny
From niels at creatype.nl Mon Jan 31 15:44:03 2005
From: niels at creatype.nl (Niels Leenheer)
Date: Mon, 31 Jan 2005 21:44:03 +0100
Subject: [geeklog-devel] Dynamic Comments...
In-Reply-To: <8319e2d6050131121241e8e4a@mail.gmail.com>
References: <8319e2d60501301551495082d9@mail.gmail.com> <20050131200010.25528@smtp.haun-online.de> <8319e2d6050131121241e8e4a@mail.gmail.com>
Message-ID: <41FE9893.5080500@creatype.nl>
Vincent Furia wrote:
>I'm working on getting it past the prototype stage. While it (just)
>works now, I need to do some modifications to make it integrate
>cleanly and to not be embarrassed by my code. Hopefully I'll have it
>checked into CVS in the next couple days.
>
>
Vincent, great idea!
However, I can see a couple of problems with the code you are currently
using.
First of all, you are using a single XMLHttpRequest object without
protecting
it from being called more than once. As a result it is possible to
interrupt an
ongoing request. Try clicking on quickly on multiple triangles after
each other,
without waiting for one to finish loading. Only the request clicked on
last will
be honoured, the other ones will be 'loading' indefinately.
The solution to this problem would be to use an array and push each
request in it. Then use a timer to frequently look at this array, shift
one request of the bottom and execute it. Repeat until the array is
empty...
Secondly, there is a bug in the XMLHttpRequest implementation of Opera,
which basically requeres and extra check inside the onreadystatechange
function, otherwise it will be called multiple times after each other,
but only the first time with the proper responseText.
var inprogress = false;
function loadFragmentInToElement(fragment_url, element_id) {
var element = document.getElementById(element_id);
element.innerHTML = 'Loading ...';
xmlhttp.open("GET", fragment_url);
xmlhttp.onreadystatechange = function() {
if (inprogress == true && xmlhttp.readyState == 4 &&
xmlhttp.status == 200) {
inprogress = false;
element.innerHTML = xmlhttp.responseText;
}
}
xmlhttp.send(null);
inprogress = true;
}
Niels
--
www.rakaz.nl
From justin.carlson at gmail.com Mon Jan 31 17:54:58 2005
From: justin.carlson at gmail.com (Justin Carlson)
Date: Mon, 31 Jan 2005 16:54:58 -0600
Subject: [geeklog-devel] Dynamic Comments...
In-Reply-To: <41FE9893.5080500@creatype.nl>
References: <8319e2d60501301551495082d9@mail.gmail.com>
<20050131200010.25528@smtp.haun-online.de>
<8319e2d6050131121241e8e4a@mail.gmail.com>
<41FE9893.5080500@creatype.nl>
Message-ID: <3d1a3f4e05013114547ff6b29b@mail.gmail.com>
It looks like it works well.
I do not see myself using it, and definitely request it to be optional.
On Mon, 31 Jan 2005 21:44:03 +0100, Niels Leenheer wrote:
> Vincent Furia wrote:
>
> >I'm working on getting it past the prototype stage. While it (just)
> >works now, I need to do some modifications to make it integrate
> >cleanly and to not be embarrassed by my code. Hopefully I'll have it
> >checked into CVS in the next couple days.
> >
> >
> Vincent, great idea!
>
> However, I can see a couple of problems with the code you are currently
> using.
>
> First of all, you are using a single XMLHttpRequest object without
> protecting
> it from being called more than once. As a result it is possible to
> interrupt an
> ongoing request. Try clicking on quickly on multiple triangles after
> each other,
> without waiting for one to finish loading. Only the request clicked on
> last will
> be honoured, the other ones will be 'loading' indefinately.
>
> The solution to this problem would be to use an array and push each
> request in it. Then use a timer to frequently look at this array, shift
> one request of the bottom and execute it. Repeat until the array is
> empty...
>
> Secondly, there is a bug in the XMLHttpRequest implementation of Opera,
> which basically requeres and extra check inside the onreadystatechange
> function, otherwise it will be called multiple times after each other,
> but only the first time with the proper responseText.
>
> var inprogress = false;
>
> function loadFragmentInToElement(fragment_url, element_id) {
> var element = document.getElementById(element_id);
> element.innerHTML = ' alt="Loading..."/>Loading ...';
> xmlhttp.open("GET", fragment_url);
> xmlhttp.onreadystatechange = function() {
> if (inprogress == true && xmlhttp.readyState == 4 &&
> xmlhttp.status == 200) {
> inprogress = false;
> element.innerHTML = xmlhttp.responseText;
> }
> }
> xmlhttp.send(null);
> inprogress = true;
> }
>
> Niels
> --
> www.rakaz.nl
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>