pbwebgui-development — Development discussion for WebGUI

Re: [Pbwebgui-development] quick temperature check

[Jay R. A. <jr...@ba...>]

On Fri, Jul 09, 2004 at 03:23:54PM -0500, JT Smith wrote:
> Therefore you have reads, writes, and high-priority reads. The latter
> two need to come from the master, and only the reads can come from the
> slave.

Would it be safer here to say "cacheable reads" and "non-cacheable
reads" and get them all from the slaves, forcing an update on the later
types?  That way you get your coherency for free.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jr...@ba...
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	"You know: I'm a fan of photosynthesis as much as the next guy,
	but if God merely wanted us to smell the flowers, he wouldn't 
	have invented a 3GHz microprocessor and a 3D graphics board."
					-- Luke Girardi

Re: [Pbwebgui-development] The new nav system

[JT S. <jt...@pl...>]

At the risk of sounding impatient, when do you think you might check this in? I'm hoping 
to put out 6.1 this weekend. The page tree system is the only thing left on the ticket. 
Having said that, I don't want to rush you. Better to have it tested than not. I just 
want to know what kind of timeframe we're looking at. If it's going to be a while, I 
might add one or two additional things to my todo list as quick adds to 6.1.


Also, as far as the upgrade goes, my suggestion is that you shouldn't create a new 
module, but instead do an inline package in the upgrade script. If you create a package 
and then delete it, you'll never be able to run the upgrade again on that box. So, what 
if you transfer a version 5.5 site to a version 6.4 box. You can't upgrade it because 
the module has already been deleted. But if it's inline in the upgrade script, it won't 
be deleted until the upgrade script get's deleted (a couple years down the road).



On Fri, 09 Jul 2004 13:15:59 +0200
  Martin Kamerbeek <ma...@pr...> wrote:
>Hi,
>
>As promised some more detail.
>
>The treeing system has become some sort of a hybrid form of an ajecency list and a 
>nested set, but maybe it's better to look at it as a nested set with some ajacency list 
>properties attached, since those properties are only used for quick comparisons (like 
>isParent), not for holding the tree together.
>
>Caching works as follows:
>-The navigation build method checks if a pageloop (id'ed by a combination of navId and 
>pageId) is in cache and fetches it if it's a hit, or, in case there was a miss, build 
>the loop and caches it.
>-The loop is then processed with user dependent stuff (canView) and everything work the 
>same as it used to from here on.
>-If a navigation object is edited, all cached navigation objects with the same navId 
>are purged.
>-If a page is edited or moved within, or deleted from/added to the tree all cached 
>navigation objects are purged.
>
>I'd urge anyone to backup their site regularly. I'm pretty sure the tree stays 
>consistent when you don't do weird stuff but you never know since I am also only human. 
>In the case you do weird stuff, you should be extra careful. For example, yesterday 
>after writing the previous mail I fixed a bug where you could mess up the tree by 
>cutting a page that's already on the clipboard (moving a page to it's own mother). In 
>this (and most) cases your tree will be repairable because of the ajacency list data in 
>the db, but backups are always a Good Thing.
>
>If have question concerning the 'new' constructor I created. Basically I had to extend 
>the 'new' constructor of DBIx::Tree::NestedSet, because I needed to put extra class 
>data in it. I did it this way:
>
>   1217 sub new {
>   1218         my ($class, $self, $properties);
>   1219         ($class, $properties) = @_;
>   1220         $self = $_[0]->SUPER::new(
>   1221                 table_name              => 'page',
>   1222                 left_column_name        => 'lft',
>   1223                 right_column_name       => 'rgt',
>   1224                 dbh                     => $session{dbh},
>   1225                 no_alter_table          => 1,
>   1226                 no_locking              => 1
>   1227                 );
>   1228         unless (ref($properties)) {
>   1229                 $properties = WebGUI::SQL->quickHashRef("select 
>* from page where pageId=$_[1]");
>   1230         }
>   1231
>   1232         return undef unless (defined $properties->{pageId});
>   1233         $self->{_pageProperties} = $properties;
>   1234         return $self;
>   1235 }
>
>This works quite nicely, but is this a correct way  to do it or is it a Bad Thing?
>
>Another question. The database needs to be converted to nested sets. I have a script 
>for this but that uses WebGUI::Page. My idea to do handle this problem is to create a 
>special (stripped down) copy of WebGUI::Page called Convert::NestedSet or something and 
>put that in the lib directory. That way the upgrade script can use it and get rid of it 
>when ready. Is that a solution you can find yourself in?
>
>Future improvements could be:
>- Rewrite parts of WebGUI::Page in WebGUI::NestedSet (or so), this way things that now 
>use WebGUI::Persistent::Tree can be converted to use that.
>- Enhance the cache purging to be more selective. A possible set back could be that the 
>cure is worse than the disease. If someone has ideas about this please tell 'em.
>- Perhaps make pages draggable. For that we need a moveLeftOf and a moveRightOf method, 
>which will probably be much like the current moveUp method.
>
>Any comments, anyone?
>Martin
>
>Martin Kamerbeek wrote:
>
>> Hi,
>>
>> So I think I'm finished with the new page tree system. I've tested 
>> almost everything, at least the page move/cut/paste/add stuff and the 
>> caching. Also Ikno for sure that the pedigree method works. What's 
>> left to test are the other nav methods (although sisters and those 
>> kind of method do work, as far as i know). Tomorrow I'll send a more 
>> detailed mail. But for now I'm gonna have a beer and go to bed. Don't 
>> be disappointed, though, to wet your appetite I attach the new Page.pm 
>> and Navigation.pm files and a ajacency list to nested set conversion 
>> script. Note that you need the old WebGUI::Page to run the conversion, 
>> so first run the conversion script, and then overwrite Page.pm
>>
>> martin
>>
>> BTW. I added the inCurrentRoot parameter from Len's HolyMenu to the 
>> navigation properties by the way.
>>
>>  
>>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top 
>technical experts, no vendor pitches, unmatched networking opportunities. Visit 
>www.blackhat.com
>_______________________________________________
>Pbwebgui-development mailing list
>Pbw...@li...
>https://lists.sourceforge.net/lists/listinfo/pbwebgui-development


JT ~ Plain Black

Create like a god, command like a king, work like a slave. 

Re: [Pbwebgui-development] quick temperature check

[JT S. <jt...@pl...>]

It's already implemented so this is someone of a lame duck discussion, but I think it's 
important that everyone understand what's going on.

Using replicated databases isn't as easy as just all writes go to the master and all 
reads come from the slave. There is a such thing as a high-priority read. Let me give 
you an example.

Let's say I'm editing my user profile (I'm not in admin mode). The data is read from a 
slave and then when I hit save it's written to the master. Now it may be a few minutes 
(or even longer) before the slave is updates. Let's say I forgot to update my phone 
number as well. I immediately go back and edit my profile, which reads from the slave. 
The problem here is that my new email address hasn't been written to the slave yet, so 
when the form is populated, it get's populated with stale data, then when I hit save 
again, my new email address is overwritten with the old one, but my phone number is up 
to date.

Therefore you have reads, writes, and high-priority reads. The latter two need to come 
from the master, and only the reads can come from the slave.

Then you might say, "Well then, anything that deals with editing must come from the 
master." That's also easier said than done. For instance if you have getter's and 
setters. The getters are used both to populate edit forms, and to display data to the 
user.

Anyway, all I'm trying to get across is that this isn't a simple flag to be thrown. It's 
a decision, that must be made for each query by a human at coding time. That's the 
reason why I implemented it in the way I did.





On Fri, 09 Jul 2004 22:53:27 +0200
  Christian Zoellin <chr...@zo...> wrote:
>So, why not transparently use the replicants until an UPDATE, CREATE, DELETE etc. 
>statement is issued. After that, there should be a switch on the user session to tie 
>the session to the master db.
>That way, users that just read from the database will use the replicants and users that 
>change content will always see the most up2date version. Only updates to the database 
>for statistics (we always have those for the page statistic) would have to be treated 
>different in that they don't set the switch.
>
>I think, that would be as transparent as it gets.
>
>Chris
>
>
>JT Smith wrote:
>>> 1) Aren't there cases when people will want to update a central database
>>> but not have admin on? For instance, posting to a "public" message
>>> board. I'm assuming the RDBMS takes care of keeping this in sync? I
>>> haven't had a need to set up replicated DBs yet.
>> 
>> 
>> 
>> Yes there are, but in those cases the developer will the main database 
>> and not one of the replicants.
>> 
>> In fact, all writes should use the master and not a slave.
>> 
>> 
>>> 2) Transparency == good, normally.  The more difficult path for you is
>>> probably the simplest for everyone.
>> 
>> 
>> 
>> Could you explain what you mean by that?
>> 
>>> What will adding replication do to performance for (an assumed majority)
>>> of WebGUI users that run only one database?
>> 
>> 
>> It will do nothing to the performance of the majority. They won't have 
>> to set anything up differently or anything else.
>> 
>> 
>> In fact, I should have mentioned this before, if no slaves are defined 
>> then the master will always be used regardless.
>> 
>> 
>> 
>>> On Fri, 2004-07-09 at 10:49, JT Smith wrote:
>>>
>>>> I've been struggling over the last week with how to implement the 
>>>> ability to use a replicated database as a read source. I've 
>>>> experimented with about 10 different ways of doing this and all 
>>>> either didn't work or were way too convoluted to be useful. I've come 
>>>> down to two ways to implement this, but I need about 2 seconds of 
>>>> feedback from a couple of people on this list to make sure I'm on the 
>>>> right track.
>>>>
>>>> Way #1: Refactor WebGUI::SQL 
>>>> Change WebGUI::SQL to not use all those class methods, but instead 
>>>> instance methods. So we'd add several constructors and remove the 
>>>> ability to pass in a new database handler on each seperate method. 
>>>> The new constructors would be:
>>>>
>>>> new ( [ dbh ] )
>>>>
>>>> This would default to the WebGUI db handler, but you could override 
>>>> it by passing in a dbh. This would be the common one everyone would use.
>>>>
>>>> newReplicant ( )
>>>>
>>>> This would use a random one of the defined replicated databases, 
>>>> except if the user was in admin mode.
>>>>
>>>>
>>>> newHandler ( dsn, user, pass [ , options ] )
>>>>
>>>> This would create a new DBH and set it in the object instance. And 
>>>> would require the use of a disconnect() method to destroy it.
>>>>
>>>>
>>>> So to use any of these you'd do something like this:
>>>>
>>>>
>>>> my $db = WebGUI::SQL->newReplicant;
>>>> my @arr = $db->quickArray($sql);
>>>>
>>>>
>>>>
>>>>
>>>> Way #2: Progie does more work, but gets more control 
>>>> We leave WebGUI::SQL as is, except for adding one method like:
>>>>
>>>> WebGUI::SQL->getReplicant()
>>>>
>>>>
>>>> Then the programmer in his code would write something like (when he 
>>>> wants to use a replicant):
>>>>
>>>> my $dbh = $session{dbh};
>>>> unless ($session{var}{adminOn} || $shouldntUseReplicant) {
>>>>    $dbh = WebGUI::SQL->getReplicant;
>>>> }
>>>> my @arr = WebGUI::SQL->quickAarry($sql,$dbh);
>>>>
>>>>
>>>>
>>>> Way #1 is cleaner, but requires refactoring all of WebGUI. (which 
>>>> I'll do if you guys think this is the best way to go)
>>>>
>>>> Way #2 is not nearly as clean, but requires no change to the rest of 
>>>> WebGUI.
>>>>
>>>>
>>>> I hope to implement one of these in a few hours, so quick feedback is 
>>>> appreciated.
>>>>
>>>>
>>>> JT ~ Plain Black
>>>>
>>>> Create like a god, command like a king, work like a slave.
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email sponsored by Black Hat Briefings & Training.
>>>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
>>>> self defense, top technical experts, no vendor pitches, unmatched 
>>>> networking opportunities. Visit www.blackhat.com
>>>> _______________________________________________
>>>> Pbwebgui-development mailing list
>>>> Pbw...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/pbwebgui-development
>>>
>>> -- 
>>> *-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*
>>>
>>> Daniel Collis Puro
>>> CTO and Lead Developer, MassLegalServices.org
>>> Massachusetts Law Reform Institute
>>> 99 Chauncy St., Suite 500
>>> Boston, MA 02111
>>> 617-357-0019 ext. 342
>>> dp...@ml...
>>> http://www.masslegalservices.org
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email sponsored by Black Hat Briefings & Training.
>>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
>>> self defense, top technical experts, no vendor pitches, unmatched 
>>> networking opportunities. Visit www.blackhat.com
>>> _______________________________________________
>>> Pbwebgui-development mailing list
>>> Pbw...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pbwebgui-development
>> 
>> 
>> 
>> JT ~ Plain Black
>> 
>> Create like a god, command like a king, work like a slave.
>> 
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
>> self defense, top technical experts, no vendor pitches, unmatched 
>> networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Pbwebgui-development mailing list
>> Pbw...@li...
>> https://lists.sourceforge.net/lists/listinfo/pbwebgui-development
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top 
>technical experts, no vendor pitches, unmatched networking opportunities. Visit 
>www.blackhat.com
>_______________________________________________
>Pbwebgui-development mailing list
>Pbw...@li...
>https://lists.sourceforge.net/lists/listinfo/pbwebgui-development


JT ~ Plain Black

Create like a god, command like a king, work like a slave. 

Re: [Pbwebgui-development] quick temperature check

[JT S. <jt...@pl...>]

>A slightly esoteric point, probably.  And kinda hollow considering I'm
>not yet doing "core" WebGUI development. So I'll shut up now. :)

No reason to shut up. Feedback is good, even when I don't wish to hear it.

I think that the way I implemented it is a good balance of both worlds. It gives the 
developer some control, but s/he doesn't need to use it, and it isn't hard to use when 
you want to use it.

JT ~ Plain Black

Create like a god, command like a king, work like a slave. 

Re: [Pbwebgui-development] quick temperature check

[Christian Z. <chr...@zo...>]

So, why not transparently use the replicants until an UPDATE, CREATE, 
DELETE etc. statement is issued. After that, there should be a switch on 
the user session to tie the session to the master db.
That way, users that just read from the database will use the replicants 
and users that change content will always see the most up2date version. 
Only updates to the database for statistics (we always have those for 
the page statistic) would have to be treated different in that they 
don't set the switch.

I think, that would be as transparent as it gets.

Chris


JT Smith wrote:
>> 1) Aren't there cases when people will want to update a central database
>> but not have admin on? For instance, posting to a "public" message
>> board. I'm assuming the RDBMS takes care of keeping this in sync? I
>> haven't had a need to set up replicated DBs yet.
> 
> 
> 
> Yes there are, but in those cases the developer will the main database 
> and not one of the replicants.
> 
> In fact, all writes should use the master and not a slave.
> 
> 
>> 2) Transparency == good, normally.  The more difficult path for you is
>> probably the simplest for everyone.
> 
> 
> 
> Could you explain what you mean by that?
> 
>> What will adding replication do to performance for (an assumed majority)
>> of WebGUI users that run only one database?
> 
> 
> It will do nothing to the performance of the majority. They won't have 
> to set anything up differently or anything else.
> 
> 
> In fact, I should have mentioned this before, if no slaves are defined 
> then the master will always be used regardless.
> 
> 
> 
>> On Fri, 2004-07-09 at 10:49, JT Smith wrote:
>>
>>> I've been struggling over the last week with how to implement the 
>>> ability to use a replicated database as a read source. I've 
>>> experimented with about 10 different ways of doing this and all 
>>> either didn't work or were way too convoluted to be useful. I've come 
>>> down to two ways to implement this, but I need about 2 seconds of 
>>> feedback from a couple of people on this list to make sure I'm on the 
>>> right track.
>>>
>>> Way #1: Refactor WebGUI::SQL 
>>> Change WebGUI::SQL to not use all those class methods, but instead 
>>> instance methods. So we'd add several constructors and remove the 
>>> ability to pass in a new database handler on each seperate method. 
>>> The new constructors would be:
>>>
>>> new ( [ dbh ] )
>>>
>>> This would default to the WebGUI db handler, but you could override 
>>> it by passing in a dbh. This would be the common one everyone would use.
>>>
>>> newReplicant ( )
>>>
>>> This would use a random one of the defined replicated databases, 
>>> except if the user was in admin mode.
>>>
>>>
>>> newHandler ( dsn, user, pass [ , options ] )
>>>
>>> This would create a new DBH and set it in the object instance. And 
>>> would require the use of a disconnect() method to destroy it.
>>>
>>>
>>> So to use any of these you'd do something like this:
>>>
>>>
>>> my $db = WebGUI::SQL->newReplicant;
>>> my @arr = $db->quickArray($sql);
>>>
>>>
>>>
>>>
>>> Way #2: Progie does more work, but gets more control 
>>> We leave WebGUI::SQL as is, except for adding one method like:
>>>
>>> WebGUI::SQL->getReplicant()
>>>
>>>
>>> Then the programmer in his code would write something like (when he 
>>> wants to use a replicant):
>>>
>>> my $dbh = $session{dbh};
>>> unless ($session{var}{adminOn} || $shouldntUseReplicant) {
>>>    $dbh = WebGUI::SQL->getReplicant;
>>> }
>>> my @arr = WebGUI::SQL->quickAarry($sql,$dbh);
>>>
>>>
>>>
>>> Way #1 is cleaner, but requires refactoring all of WebGUI. (which 
>>> I'll do if you guys think this is the best way to go)
>>>
>>> Way #2 is not nearly as clean, but requires no change to the rest of 
>>> WebGUI.
>>>
>>>
>>> I hope to implement one of these in a few hours, so quick feedback is 
>>> appreciated.
>>>
>>>
>>> JT ~ Plain Black
>>>
>>> Create like a god, command like a king, work like a slave.
>>>
>>> -------------------------------------------------------
>>> This SF.Net email sponsored by Black Hat Briefings & Training.
>>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
>>> self defense, top technical experts, no vendor pitches, unmatched 
>>> networking opportunities. Visit www.blackhat.com
>>> _______________________________________________
>>> Pbwebgui-development mailing list
>>> Pbw...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pbwebgui-development
>>
>> -- 
>> *-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*
>>
>> Daniel Collis Puro
>> CTO and Lead Developer, MassLegalServices.org
>> Massachusetts Law Reform Institute
>> 99 Chauncy St., Suite 500
>> Boston, MA 02111
>> 617-357-0019 ext. 342
>> dp...@ml...
>> http://www.masslegalservices.org
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
>> self defense, top technical experts, no vendor pitches, unmatched 
>> networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Pbwebgui-development mailing list
>> Pbw...@li...
>> https://lists.sourceforge.net/lists/listinfo/pbwebgui-development
> 
> 
> 
> JT ~ Plain Black
> 
> Create like a god, command like a king, work like a slave.
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Pbwebgui-development mailing list
> Pbw...@li...
> https://lists.sourceforge.net/lists/listinfo/pbwebgui-development

Re: [Pbwebgui-development] quick temperature check

[Dan C. P. <dp...@ml...>]

On Fri, 2004-07-09 at 14:31, JT Smith wrote:

> >2) Transparency == good, normally.  The more difficult path for you is
> >probably the simplest for everyone.
> 
> 
> Could you explain what you mean by that? 
> 

I mean that fewer decisions are better.  If the use of replicants
(Bladerunner, anyone? :) ) can be behind the scenes as much as
possible,  the easier it'll be on the folks that develop other parts of
the app.    

I guess I've thought of you (JT) as developing the core API that folks
build Wobjects around. The easier you make the core API to build on the
better it is for people creating Wobjects and other functionality. Part
of making stuff easier is keeping the number of variables a developer
has to juggle to a minimum.

A slightly esoteric point, probably.  And kinda hollow considering I'm
not yet doing "core" WebGUI development. So I'll shut up now. :)

-DJCP

-- 
*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*

Daniel Collis Puro
CTO and Lead Developer, MassLegalServices.org
Massachusetts Law Reform Institute
99 Chauncy St., Suite 500
Boston, MA 02111
617-357-0019 ext. 342
dp...@ml...
http://www.masslegalservices.org

Re: [Pbwebgui-development] quick temperature check

[JT S. <jt...@pl...>]

Hey everyone, just thought I'd let you know that I've made my decision, and have 
implemented it. Sorry for not giving much notice for input on this one. I'm trying to 
get 6.1 out the door and this and the page tree stuff is all that is remaining.

Here's what I decided to do:

I implemented a new method:

my $dbh = WebGUI::SQL->getSlave;

getSlave will return a random slave dbh, unless admin mode is enabled, then it will 
return undef. Likewise it will return undef if no slaves have been defined. You can 
define up to 3 slaves in the config file like this:

dbslave1 = dsn => "DBI:mysql:name_of_slave_db", \
            user => "webgui", \
            pass => "password"


I chose this way because:

1) It was easy to implement.

2) It was the least disruptive implementation.

3) By adding the undef return in admin mode it accomplished what the other thing was 
going to do.


I'm going to put the new method to use in a few heavily traffic'd areas of WebGUI. But 
by all means not everywhere that it could be used. As time goes forward and we see more 
people using and wanting to use replicated databases, we can update the other parts of 
the system to use this functionality.







On Fri, 09 Jul 2004 09:49:29 -0500
  JT Smith <jt...@pl...> wrote:
>I've been struggling over the last week with how to implement the ability to use a 
>replicated database as a read source. I've experimented with about 10 different ways of 
>doing this and all either didn't work or were way too convoluted to be useful. I've 
>come down to two ways to implement this, but I need about 2 seconds of feedback from a 
>couple of people on this list to make sure I'm on the right track.
>
>Way #1: Refactor WebGUI::SQL  
>Change WebGUI::SQL to not use all those class methods, but instead instance methods. So 
>we'd add several constructors and remove the ability to pass in a new database handler 
>on each seperate method. The new constructors would be:
>
>new ( [ dbh ] )
>
>This would default to the WebGUI db handler, but you could override it by passing in a 
>dbh. This would be the common one everyone would use. 
>
>newReplicant ( )
>
>This would use a random one of the defined replicated databases, except if the user was 
>in admin mode.
>
>
>newHandler ( dsn, user, pass [ , options ] )
>
>This would create a new DBH and set it in the object instance. And would require the 
>use of a disconnect() method to destroy it.
>
>
>So to use any of these you'd do something like this:
>
>
>my $db = WebGUI::SQL->newReplicant;
>my @arr = $db->quickArray($sql);
>
>
>
>
>Way #2: Progie does more work, but gets more control  
>We leave WebGUI::SQL as is, except for adding one method like:
>
>WebGUI::SQL->getReplicant()
>
>
>Then the programmer in his code would write something like (when he wants to use a 
>replicant):
>
>my $dbh = $session{dbh};
>unless ($session{var}{adminOn} || $shouldntUseReplicant) {
>   $dbh = WebGUI::SQL->getReplicant;
>}
>my @arr = WebGUI::SQL->quickAarry($sql,$dbh);
>
>
>
>Way #1 is cleaner, but requires refactoring all of WebGUI. (which I'll do if you guys 
>think this is the best way to go)
>
>Way #2 is not nearly as clean, but requires no change to the rest of WebGUI.
>
>
>I hope to implement one of these in a few hours, so quick feedback is appreciated.
>
>
>JT ~ Plain Black
>
>Create like a god, command like a king, work like a slave. 
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top 
>technical experts, no vendor pitches, unmatched networking opportunities. Visit 
>www.blackhat.com
>_______________________________________________
>Pbwebgui-development mailing list
>Pbw...@li...
>https://lists.sourceforge.net/lists/listinfo/pbwebgui-development


JT ~ Plain Black

Create like a god, command like a king, work like a slave. 

Re: [Pbwebgui-development] quick temperature check

[JT S. <jt...@pl...>]

>1) Aren't there cases when people will want to update a central database
>but not have admin on? For instance, posting to a "public" message
>board. I'm assuming the RDBMS takes care of keeping this in sync? I
>haven't had a need to set up replicated DBs yet.


Yes there are, but in those cases the developer will the main database and not one of 
the replicants.

In fact, all writes should use the master and not a slave.


>2) Transparency == good, normally.  The more difficult path for you is
>probably the simplest for everyone.


Could you explain what you mean by that? 


>What will adding replication do to performance for (an assumed majority)
>of WebGUI users that run only one database?

It will do nothing to the performance of the majority. They won't have to set anything 
up differently or anything else.


In fact, I should have mentioned this before, if no slaves are defined then the master 
will always be used regardless.



>On Fri, 2004-07-09 at 10:49, JT Smith wrote:
>> I've been struggling over the last week with how to implement the ability to use a 
>> replicated database as a read source. I've experimented with about 10 different ways 
>>of 
>> doing this and all either didn't work or were way too convoluted to be useful. I've 
>>come 
>> down to two ways to implement this, but I need about 2 seconds of feedback from a 
>>couple 
>> of people on this list to make sure I'm on the right track.
>> 
>> Way #1: Refactor WebGUI::SQL  
>> 
>> Change WebGUI::SQL to not use all those class methods, but instead instance methods. 
>>So 
>> we'd add several constructors and remove the ability to pass in a new database handler 
>> on each seperate method. The new constructors would be:
>> 
>> new ( [ dbh ] )
>> 
>> This would default to the WebGUI db handler, but you could override it by passing in a 
>> dbh. This would be the common one everyone would use. 
>> 
>> 
>> newReplicant ( )
>> 
>> This would use a random one of the defined replicated databases, except if the user 
>>was 
>> in admin mode.
>> 
>> 
>> newHandler ( dsn, user, pass [ , options ] )
>> 
>> This would create a new DBH and set it in the object instance. And would require the 
>>use 
>> of a disconnect() method to destroy it.
>> 
>> 
>> So to use any of these you'd do something like this:
>> 
>> 
>> my $db = WebGUI::SQL->newReplicant;
>> my @arr = $db->quickArray($sql);
>> 
>> 
>> 
>> 
>> Way #2: Progie does more work, but gets more control  
>> 
>> We leave WebGUI::SQL as is, except for adding one method like:
>> 
>> WebGUI::SQL->getReplicant()
>> 
>> 
>> Then the programmer in his code would write something like (when he wants to use a 
>> replicant):
>> 
>> my $dbh = $session{dbh};
>> unless ($session{var}{adminOn} || $shouldntUseReplicant) {
>>    $dbh = WebGUI::SQL->getReplicant;
>> }
>> my @arr = WebGUI::SQL->quickAarry($sql,$dbh);
>> 
>> 
>> 
>> Way #1 is cleaner, but requires refactoring all of WebGUI. (which I'll do if you guys 
>> think this is the best way to go)
>> 
>> Way #2 is not nearly as clean, but requires no change to the rest of WebGUI.
>> 
>> 
>> I hope to implement one of these in a few hours, so quick feedback is appreciated.
>> 
>> 
>> JT ~ Plain Black
>> 
>> Create like a god, command like a king, work like a slave. 
>> 
>> 
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>> digital self defense, top technical experts, no vendor pitches, 
>> unmatched networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Pbwebgui-development mailing list
>> Pbw...@li...
>> https://lists.sourceforge.net/lists/listinfo/pbwebgui-development
>-- 
>*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*
>
>Daniel Collis Puro
>CTO and Lead Developer, MassLegalServices.org
>Massachusetts Law Reform Institute
>99 Chauncy St., Suite 500
>Boston, MA 02111
>617-357-0019 ext. 342
>dp...@ml...
>http://www.masslegalservices.org
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>digital self defense, top technical experts, no vendor pitches, 
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>Pbwebgui-development mailing list
>Pbw...@li...
>https://lists.sourceforge.net/lists/listinfo/pbwebgui-development


JT ~ Plain Black

Create like a god, command like a king, work like a slave. 

Re: [Pbwebgui-development] quick temperature check

[Dan C. P. <dp...@ml...>]

JT,

1) Aren't there cases when people will want to update a central database
but not have admin on? For instance, posting to a "public" message
board. I'm assuming the RDBMS takes care of keeping this in sync? I
haven't had a need to set up replicated DBs yet.

2) Transparency == good, normally.  The more difficult path for you is
probably the simplest for everyone.

What will adding replication do to performance for (an assumed majority)
of WebGUI users that run only one database?

-DJCP

On Fri, 2004-07-09 at 10:49, JT Smith wrote:
> I've been struggling over the last week with how to implement the ability to use a 
> replicated database as a read source. I've experimented with about 10 different ways of 
> doing this and all either didn't work or were way too convoluted to be useful. I've come 
> down to two ways to implement this, but I need about 2 seconds of feedback from a couple 
> of people on this list to make sure I'm on the right track.
> 
> Way #1: Refactor WebGUI::SQL  
> 
> Change WebGUI::SQL to not use all those class methods, but instead instance methods. So 
> we'd add several constructors and remove the ability to pass in a new database handler 
> on each seperate method. The new constructors would be:
> 
> new ( [ dbh ] )
> 
> This would default to the WebGUI db handler, but you could override it by passing in a 
> dbh. This would be the common one everyone would use. 
> 
> 
> newReplicant ( )
> 
> This would use a random one of the defined replicated databases, except if the user was 
> in admin mode.
> 
> 
> newHandler ( dsn, user, pass [ , options ] )
> 
> This would create a new DBH and set it in the object instance. And would require the use 
> of a disconnect() method to destroy it.
> 
> 
> So to use any of these you'd do something like this:
> 
> 
> my $db = WebGUI::SQL->newReplicant;
> my @arr = $db->quickArray($sql);
> 
> 
> 
> 
> Way #2: Progie does more work, but gets more control  
> 
> We leave WebGUI::SQL as is, except for adding one method like:
> 
> WebGUI::SQL->getReplicant()
> 
> 
> Then the programmer in his code would write something like (when he wants to use a 
> replicant):
> 
> my $dbh = $session{dbh};
> unless ($session{var}{adminOn} || $shouldntUseReplicant) {
>    $dbh = WebGUI::SQL->getReplicant;
> }
> my @arr = WebGUI::SQL->quickAarry($sql,$dbh);
> 
> 
> 
> Way #1 is cleaner, but requires refactoring all of WebGUI. (which I'll do if you guys 
> think this is the best way to go)
> 
> Way #2 is not nearly as clean, but requires no change to the rest of WebGUI.
> 
> 
> I hope to implement one of these in a few hours, so quick feedback is appreciated.
> 
> 
> JT ~ Plain Black
> 
> Create like a god, command like a king, work like a slave. 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Pbwebgui-development mailing list
> Pbw...@li...
> https://lists.sourceforge.net/lists/listinfo/pbwebgui-development
-- 
*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*

Daniel Collis Puro
CTO and Lead Developer, MassLegalServices.org
Massachusetts Law Reform Institute
99 Chauncy St., Suite 500
Boston, MA 02111
617-357-0019 ext. 342
dp...@ml...
http://www.masslegalservices.org

[Pbwebgui-development] quick temperature check

[JT S. <jt...@pl...>]

I've been struggling over the last week with how to implement the ability to use a 
replicated database as a read source. I've experimented with about 10 different ways of 
doing this and all either didn't work or were way too convoluted to be useful. I've come 
down to two ways to implement this, but I need about 2 seconds of feedback from a couple 
of people on this list to make sure I'm on the right track.

Way #1: Refactor WebGUI::SQL  

Change WebGUI::SQL to not use all those class methods, but instead instance methods. So 
we'd add several constructors and remove the ability to pass in a new database handler 
on each seperate method. The new constructors would be:

new ( [ dbh ] )

This would default to the WebGUI db handler, but you could override it by passing in a 
dbh. This would be the common one everyone would use. 


newReplicant ( )

This would use a random one of the defined replicated databases, except if the user was 
in admin mode.


newHandler ( dsn, user, pass [ , options ] )

This would create a new DBH and set it in the object instance. And would require the use 
of a disconnect() method to destroy it.


So to use any of these you'd do something like this:


my $db = WebGUI::SQL->newReplicant;
my @arr = $db->quickArray($sql);




Way #2: Progie does more work, but gets more control  

We leave WebGUI::SQL as is, except for adding one method like:

WebGUI::SQL->getReplicant()


Then the programmer in his code would write something like (when he wants to use a 
replicant):

my $dbh = $session{dbh};
unless ($session{var}{adminOn} || $shouldntUseReplicant) {
   $dbh = WebGUI::SQL->getReplicant;
}
my @arr = WebGUI::SQL->quickAarry($sql,$dbh);



Way #1 is cleaner, but requires refactoring all of WebGUI. (which I'll do if you guys 
think this is the best way to go)

Way #2 is not nearly as clean, but requires no change to the rest of WebGUI.


I hope to implement one of these in a few hours, so quick feedback is appreciated.


JT ~ Plain Black

Create like a god, command like a king, work like a slave. 

Re: [Pbwebgui-development] extras URL

[JT S. <jt...@pl...>]

I'm not sure how this solves the security problem. The javascript will still be calling 
a page from a new host, so wouldn't it then still cause a security problem?

I guess what I'm saying is that I don't think this is a WebGUI configuration issue, but 
rather a server config issue. To avoid the security issue I think you need a front end 
proxy that masks the backend servers. So when a request is made for a page that has 
javascript in it, you'd have this:


page req -> proxy (www.me.com) -> webgui (wg.me.com)

js req -> proxy (www.me.com) -> static server (extras.me.com)

With a setup like this it will both boost performance (because the proxy server is 
handling the latent requests) and solve the security issue (because the browser thinks 
everything came from the same source).


On 09 Jul 2004 15:21:42 +0200
  Leendert Bottelberghs <lee...@un...> wrote:
>I'm currently experimenting with setting up WebGUI to run on two
>different http servers. I use an Apache/mod_perl server for the dynamic
>content (generating the pages), and thttpd (a forth-generation
>Non-blocking I/O server) for serving all static content (uploads and
>extras).
>I was very pleased with the way WebGUI supports the configuration of the
>extras and uploads URL, this makes setting up a config like mine quite
>easy.
>I encountered a problem though with some of the javascript that is in
>the extras directory and is used in functionality such as the HTML
>editors. The extras-url must be different from the site-url because it
>is served by a different http-server. It's also possible to use the same
>url, but on a different port. This results in the HTML-editor javascript
>to be served from a different domain than the website in which the edit
>form is present. This causes a javascript security exception, so the
>editor will NOT work.
>
>To conclude: as long as the default javascripts that come with WebGUI
>are approached from the extrasURL that is configured in the config-file,
>you can't serve the extras folder from another server.
>Solution: seperate the javascript that comes with WebGUI and put them in
>a javascript folder that can be configured seperately from the
>extras-folder and -url. It won't be a bad idea at all to join all
>javascript into one folder, aside from the reasons mentioned before.
>
>JT, what do you say about this?
>
>-leendert


JT ~ Plain Black

Create like a god, command like a king, work like a slave. 

Re: [Pbwebgui-development] extras URL

[Martin K. <ma...@pr...>]

Flavio Curti wrote:

>Hello
>
>On Fri, Jul 09, 2004 at 03:33:44PM +0200, Martin Kamerbeek wrote:
>  
>
>>If I understand you correctly, I think using some transparent proxy 
>>(that redirects all http://my.url.tld/extras/* ) also solves your 
>>problem. This way the url stays the same but the server serving the 
>>scripts and collateral is actually another. I think mod_rewrite can also 
>>do this, but I'm not entirely sure.
>>    
>>
>mod_rewrite could certainly do this, but only (imho) using the proxy
>directive. but then apache has to fetch the url and serve the content to
>the client, which imho defeats the purpose of seperate servers...
>  
>
I think you can connect through sockets, which is AFAIK pretty fast.

>i'm not even sure if <script lang='javascript'
>src='http://somewhere.else/bla.js'> would work and not trigger a
>security exception too... 
>
>  
>
It would if you use the somewhere.else url, but using a proxy you can 
use the same url as the rest of the site runs on.

Re: [Pbwebgui-development] extras URL

[Flavio C. <lis...@no...>]

Hello

On Fri, Jul 09, 2004 at 03:33:44PM +0200, Martin Kamerbeek wrote:
> If I understand you correctly, I think using some transparent proxy 
> (that redirects all http://my.url.tld/extras/* ) also solves your 
> problem. This way the url stays the same but the server serving the 
> scripts and collateral is actually another. I think mod_rewrite can also 
> do this, but I'm not entirely sure.
mod_rewrite could certainly do this, but only (imho) using the proxy
directive. but then apache has to fetch the url and serve the content to
the client, which imho defeats the purpose of seperate servers...

i'm not even sure if <script lang='javascript'
src='http://somewhere.else/bla.js'> would work and not trigger a
security exception too... 

hope it helps & greets

Flavio

--
http://no-way.org/~fcu/

Mach mit bei der Community-Bibliothek
  - In Zuerich/CH http://zurich.communitybooks.org/
  - Worldwide http://dlpdev.theps.net/ListOfExistingDlpNodes

Re: [Pbwebgui-development] extras URL

[Dan C. P. <dp...@ml...>]

Leendert,

You could just proxy through the extras folder via a rewrite rule.  Then
apache sits on the frontend with thttpd sitting behind serving the
static stuff.

That may seem pointless at first look because you're using the heavy
apache interpreter as a proxy for the lightweight thttpd (is that a
kernel-level httpd daemon?). However,  as I understand it apache is an
extremely efficient proxy server.

The big efficiency you'll miss using apache as a proxy is the "lingering
socket" problems associated with users on slower connections (the slower
the download, the longer a user ties a heavy mod_perl process up), but
the "negotiate/read/serve" part will be handled mostly by thttpd.

It'd probably make more sense to come at this from the other direction,
though.  Put thttpd in front of your apache/mod_perl process and then
have it handle everything under /extras/ and /uploads/ (though what'll
that do for security?) and proxy everything else through to your
mod_perl process. I assume thttpd supports this kind of setup, otherwise
you can just use a lightweight apache interpreter without mod_perl for
the frontend.  

I've set up a couple systems like this in the past, with a "lightweight"
apache interpreter serving static content in front and a heavier
mod_perl interpreter in back serving mod_perl stuff. It's not hard.

I can help you with the rewrite/proxy stuff if you want. 

-DJCP

On Fri, 2004-07-09 at 09:21, Leendert Bottelberghs wrote:
> I'm currently experimenting with setting up WebGUI to run on two
> different http servers. I use an Apache/mod_perl server for the
> dynamic content (generating the pages), and thttpd (a forth-generation
> Non-blocking I/O server) for serving all static content (uploads and
> extras).
> I was very pleased with the way WebGUI supports the configuration of
> the extras and uploads URL, this makes setting up a config like mine
> quite easy.
> I encountered a problem though with some of the javascript that is in
> the extras directory and is used in functionality such as the HTML
> editors. The extras-url must be different from the site-url because it
> is served by a different http-server. It's also possible to use the
> same url, but on a different port. This results in the HTML-editor
> javascript to be served from a different domain than the website in
> which the edit form is present. This causes a javascript security
> exception, so the editor will NOT work.
> 
> To conclude: as long as the default javascripts that come with WebGUI
> are approached from the extrasURL that is configured in the
> config-file, you can't serve the extras folder from another server.
> Solution: seperate the javascript that comes with WebGUI and put them
> in a javascript folder that can be configured seperately from the
> extras-folder and -url. It won't be a bad idea at all to join all
> javascript into one folder, aside from the reasons mentioned before.
> 
> JT, what do you say about this?
> 
> -leendert
-- 
*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*

Daniel Collis Puro
CTO and Lead Developer, MassLegalServices.org
Massachusetts Law Reform Institute
99 Chauncy St., Suite 500
Boston, MA 02111
617-357-0019 ext. 342
dp...@ml...
http://www.masslegalservices.org

Re: [Pbwebgui-development] extras URL

[Martin K. <ma...@pr...>]

Leendert Bottelberghs wrote:

> To conclude: as long as the default javascripts that come with WebGUI 
> are approached from the extrasURL that is configured in the 
> config-file, you can't serve the extras folder from another server.
> Solution: seperate the javascript that comes with WebGUI and put them 
> in a javascript folder that can be configured seperately from the 
> extras-folder and -url. It won't be a bad idea at all to join all 
> javascript into one folder, aside from the reasons mentioned before.
>
If I understand you correctly, I think using some transparent proxy 
(that redirects all http://my.url.tld/extras/* ) also solves your 
problem. This way the url stays the same but the server serving the 
scripts and collateral is actually another. I think mod_rewrite can also 
do this, but I'm not entirely sure.


> JT, what do you say about this?
>
> -leendert 

[Pbwebgui-development] extras URL

[Leendert B. <lee...@un...>]

I'm currently experimenting with setting up WebGUI to run on two
different http servers. I use an Apache/mod_perl server for the dynamic
content (generating the pages), and thttpd (a forth-generation
Non-blocking I/O server) for serving all static content (uploads and
extras).
I was very pleased with the way WebGUI supports the configuration of the
extras and uploads URL, this makes setting up a config like mine quite
easy.
I encountered a problem though with some of the javascript that is in
the extras directory and is used in functionality such as the HTML
editors. The extras-url must be different from the site-url because it
is served by a different http-server. It's also possible to use the same
url, but on a different port. This results in the HTML-editor javascript
to be served from a different domain than the website in which the edit
form is present. This causes a javascript security exception, so the
editor will NOT work.

To conclude: as long as the default javascripts that come with WebGUI
are approached from the extrasURL that is configured in the config-file,
you can't serve the extras folder from another server.
Solution: seperate the javascript that comes with WebGUI and put them in
a javascript folder that can be configured seperately from the
extras-folder and -url. It won't be a bad idea at all to join all
javascript into one folder, aside from the reasons mentioned before.

JT, what do you say about this?

-leendert

Re: [Pbwebgui-development] The new nav system

[Martin K. <ma...@pr...>]

Hi,

As promised some more detail.

The treeing system has become some sort of a hybrid form of an ajecency 
list and a nested set, but maybe it's better to look at it as a nested 
set with some ajacency list properties attached, since those properties 
are only used for quick comparisons (like isParent), not for holding the 
tree together.

Caching works as follows:
-The navigation build method checks if a pageloop (id'ed by a 
combination of navId and pageId) is in cache and fetches it if it's a 
hit, or, in case there was a miss, build the loop and caches it.
-The loop is then processed with user dependent stuff (canView) and 
everything work the same as it used to from here on.
-If a navigation object is edited, all cached navigation objects with 
the same navId are purged.
-If a page is edited or moved within, or deleted from/added to the tree 
all cached navigation objects are purged.

I'd urge anyone to backup their site regularly. I'm pretty sure the tree 
stays consistent when you don't do weird stuff but you never know since 
I am also only human. In the case you do weird stuff, you should be 
extra careful. For example, yesterday after writing the previous mail I 
fixed a bug where you could mess up the tree by cutting a page that's 
already on the clipboard (moving a page to it's own mother). In this 
(and most) cases your tree will be repairable because of the ajacency 
list data in the db, but backups are always a Good Thing.

If have question concerning the 'new' constructor I created. Basically I 
had to extend the 'new' constructor of DBIx::Tree::NestedSet, because I 
needed to put extra class data in it. I did it this way:

   1217 sub new {
   1218         my ($class, $self, $properties);
   1219         ($class, $properties) = @_;
   1220         $self = $_[0]->SUPER::new(
   1221                 table_name              => 'page',
   1222                 left_column_name        => 'lft',
   1223                 right_column_name       => 'rgt',
   1224                 dbh                     => $session{dbh},
   1225                 no_alter_table          => 1,
   1226                 no_locking              => 1
   1227                 );
   1228         unless (ref($properties)) {
   1229                 $properties = WebGUI::SQL->quickHashRef("select 
* from page where pageId=$_[1]");
   1230         }
   1231
   1232         return undef unless (defined $properties->{pageId});
   1233         $self->{_pageProperties} = $properties;
   1234         return $self;
   1235 }

This works quite nicely, but is this a correct way  to do it or is it a 
Bad Thing?

Another question. The database needs to be converted to nested sets. I 
have a script for this but that uses WebGUI::Page. My idea to do handle 
this problem is to create a special (stripped down) copy of WebGUI::Page 
called Convert::NestedSet or something and put that in the lib 
directory. That way the upgrade script can use it and get rid of it when 
ready. Is that a solution you can find yourself in?

Future improvements could be:
- Rewrite parts of WebGUI::Page in WebGUI::NestedSet (or so), this way 
things that now use WebGUI::Persistent::Tree can be converted to use that.
- Enhance the cache purging to be more selective. A possible set back 
could be that the cure is worse than the disease. If someone has ideas 
about this please tell 'em.
- Perhaps make pages draggable. For that we need a moveLeftOf and a 
moveRightOf method, which will probably be much like the current moveUp 
method.

Any comments, anyone?
Martin

Martin Kamerbeek wrote:

> Hi,
>
> So I think I'm finished with the new page tree system. I've tested 
> almost everything, at least the page move/cut/paste/add stuff and the 
> caching. Also Ikno for sure that the pedigree method works. What's 
> left to test are the other nav methods (although sisters and those 
> kind of method do work, as far as i know). Tomorrow I'll send a more 
> detailed mail. But for now I'm gonna have a beer and go to bed. Don't 
> be disappointed, though, to wet your appetite I attach the new Page.pm 
> and Navigation.pm files and a ajacency list to nested set conversion 
> script. Note that you need the old WebGUI::Page to run the conversion, 
> so first run the conversion script, and then overwrite Page.pm
>
> martin
>
> BTW. I added the inCurrentRoot parameter from Len's HolyMenu to the 
> navigation properties by the way.
>
>  
>

[Pbwebgui-development] The new nav system

[Martin K. <ma...@pr...>]

Hi,

So I think I'm finished with the new page tree system. I've tested 
almost everything, at least the page move/cut/paste/add stuff and the 
caching. Also Ikno for sure that the pedigree method works. What's left 
to test are the other nav methods (although sisters and those kind of 
method do work, as far as i know). Tomorrow I'll send a more detailed 
mail. But for now I'm gonna have a beer and go to bed. Don't be 
disappointed, though, to wet your appetite I attach the new Page.pm and 
Navigation.pm files and a ajacency list to nested set conversion script. 
Note that you need the old WebGUI::Page to run the conversion, so first 
run the conversion script, and then overwrite Page.pm

martin

BTW. I added the inCurrentRoot parameter from Len's HolyMenu to the 
navigation properties by the way.

Re: [Pbwebgui-development] Idea: "My Home" page.

[Roy J. <RJo...@sp...>]

This is along the lines I was thinking.  Having a system such that =
www.mysite.com/username took someone to "their" page would be great.

I also like the idea of adding a user to a "portal owner" group or similar =
that gives them the "My Home Page" option without having to make them =
content managers.

This idea came from evaluating other CMS Platforms (PHPNuke in particular).=
  If any of you have seen/or used that CMS maybe what I'm talking about =
would be more clear.

The dashboard sounds like something that will be very cool but I'm not =
sure that it would accomplish the same things that I'm referring to.

1) A "My Home" page would give a user their own page on which they could =
do anything that a page owner could normally do.  i.e., proxy wobjects, =
create new wobjects, change page template, etc.

2) After reading the dashboard description, it seems that it would be a =
feature aimed at users of a lower skill level and give them less flexibilit=
y.  I agree that for the majority of users this is exactly what you want.

This is why I like the idea of a "Portal Owner" group or similar.  This =
would give site admins the ability to give their power users a place to =
build what is essentially their own one page website.

Hope this clears things up a bit.

Roy

>>> dp...@di... 07/07/04 02:50AM >>>
Sounds a lot like a user-customizable "portal" page to me.

He says the home page would have a link to a "My Home Page", and when you =
click this link
you'd get a page that's totally under your own control.

Doesn't sound that much different than what would be needed to support =
"self-replicating"
sites, except he's postulating that the user needs to be logged in first.

Consider two options:

(1) A URL like "www.mysite.com/joe" would bring up joe's page

(2) Or, going to "www.mysite.com" and then logging in as "joe" would =
present a link to
"www.mysite.com/joe" as "My Home Page".  (Unless there's supposed to be =
some kind of
polymorphic "virtual" link named, eg., "my_home_page" that the system =
knows how to render
for each logged-in user automatically.  This would be rather complicated.)

A flag somewhere would say whether it's public, like (1), or totally =
private, like (2).  Or,
perhaps, the page could have both public and private things on it.  (I =
think this latter bit
is already supported if you've got WObject perms enabled.)

Anyway, this is doable now, but the Admin has to jump through a lot of =
hoops to manually
create the initial page and proper groups and ownership for each user.  To =
do this
automatically (if you don't go the "polymorphic virtual link" route), then =
you need to be
able to: create a new user and group and make the proper associations; =
create a new page
with a specific template (layout); instantiate a predefined Package on =
that page that fits
its template (layout); and finally set the new user as the owner (and =
content manager) of
the page.

It would be doubly great if a new class of user was defined that can =
perform these
operations (eg., "Portal Manger") independently of most other user classes =
(ie, any
Registered User can be ordained a Portal Manager without having to be an =
Admin).

It would be tripley great if this process could be almost entirely =
automated, similar to
signing up as an affiliate and giving the Admin the option of saying =
whether to run this
process automatically, or queue it up somehow pending approval by a Portal =
Manager.

-David

JT Smith wrote:

> After re-reading your post I'm unsure whether my initial impression of =
what you're
> looking to do is correct.
>
> Are you looking to have a way for users to publish their own web site =
within a site sort
> of like sub-sites for each user (for public viewing), or are you looking =
for a place
> where users can set up for their own needs (only they can see it)?
>
> On Tue, 06 Jul 2004 22:37:13 -0400
>   "Roy Johnson" <RJo...@sp...> wrote:
> >I would like to develop a "My Home" page for WebGUI.  I looked at the =
Roadmap for 6.x
> >and did not see this on the list.  Basically what I'm referring to is a =
page that is
> >unique to every registered user in WebGUI on which they can do =
everything one could do
> >when adding a normal page in WebGUI.
> >
> >This would basically be like a sandbox for each user to put things =
(content) that they
> >found useful.  In our company, we use WebGUI to run our corporate =
intranet so this
> >would be extremely useful to us.
> >
> >I'm thinking it could work something like this:
> >
> >1) User logs in and within the navigation system there is automatically =
a link to "My
> >Home" or something similar.
> >
> >2) When the user clicks on this page they are free to do everything =
they could do on a
> >regular page that was added in WebGUI.  The difference would be that =
the content on the
> >page would be unique to their login.
> >
> >Has this concept/idea been explored before?  Can anyone think of a way =
to implement
> >this functionality within WebGUI as it exists now?
> >
> >If anyone has any ideas on ways to approach this or would be interested =
in working on
> >it with me please let me know.  I'm fairly new to the WebGUI API but am =
willing to
> >devote a large amount of time to the project.
> >
> >Comments/Feedback/Flames are welcomed {:-)  Thanks!
> >
> >Roy
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email sponsored by Black Hat Briefings & Training.
> >Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> >digital self defense, top technical experts, no vendor pitches,
> >unmatched networking opportunities. Visit www.blackhat.com=20
> >_______________________________________________
> >Pbwebgui-development mailing list
> >Pbw...@li...=20
> >https://lists.sourceforge.net/lists/listinfo/pbwebgui-development=20
>
> JT ~ Plain Black
>
> Create like a god, command like a king, work like a slave.
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com=20
> _______________________________________________
> Pbwebgui-development mailing list
> Pbw...@li...=20
> https://lists.sourceforge.net/lists/listinfo/pbwebgui-development=20



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
digital self defense, top technical experts, no vendor pitches,=20
unmatched networking opportunities. Visit www.blackhat.com=20
_______________________________________________
Pbwebgui-development mailing list
Pbw...@li...=20
https://lists.sourceforge.net/lists/listinfo/pbwebgui-development

Re: [Pbwebgui-development] Idea: "My Home" page.

[Wouter V. <wvi...@sc...>]

Hi,
Martin Kamerbeek wrote:
> Of course you also need some code 
> to create the page and set the privilege correctly at user creation 
> time. 

Just a thought: can't the op=deployPackage functionality be used for 
this? Maybe I'm missing something, but it seems to me like most of the 
functionality is already present in WebGUI. Want you want is:
- a package with the default page, the user can edit it anyway he/she 
pleases
- set the owner of the deployed page to the specified user and the 
"view" and "edit" groups to "Admins". Maybe some code is needed to do 
this at user creation time (together with the deployment).
- wobject privileges turned, so that the owner can specify who can view 
which wobject

Maybe it's an idea to create a special group "Page owners" or something 
similar, which contains users that can own a page, but don't have any 
other special privileges (currently they have to be at least Content 
Managers to be able to own a page, which is something we clearly don't 
want for this!). All the users that want a personalized homepage should 
be added to this group.

Is my line of thought too simple?

Greets,
Wouter

Re: [Pbwebgui-development] Idea: "My Home" page.

[Martin K. <ma...@pr...>]

Roy,

I you're trying the thing Nils-Magne talks about I think functionality 
like this could be created quite easily by using WobjectProxies and some 
code that put 'em on this 'home page'. Of course you also need some code 
to create the page and set the privilege correctly at user creation 
time. This could either be done by putting the setup code in a macro and 
put that Macro in the 'Run on registration field' or by writing your own 
auth handler. The latter approach is way safer the the first. If you 
were going down the Dark Macro Path be sure to have your macro return 
undef and have it check that $session{form}{op} is actually set to 
'createAccountSave'. That is with 5.x.x and lower auth system. I haven't 
toyed with the 6.x.x system yet, so I can't say to much about that.

Martin


Nils-Magne Kvammen wrote:

>The company i work for use Microsoft Sharepoint portal server, and the
>intranet is huge and covers four different languages. This intranet is
>loaded with information that is crusial for us to do our daily job. And it
>is possible for us to find nearly everything on this intranet. But it has a
>feature that it's called "My Home Page", this page is a spesial page with a
>predifined layout (5-6 regions) where onely you as a user have the rights to
>view.
>To populate this page you can view any page on the intranet and clik on a
>link on that page that say's "put on My Home Page" it then copys itself to
>one of the regions on "My Home Page" and you hav instant acsess to it. The
>administrator desides which region a page should be placed in.
>In the end we end up with a page that is customased to each persons need. If
>WebGUI could extend this furtermore with the ability to not put the whole
>page in this page but elements from the page too... that would be great. And
>your plannes for the dashboard wobject would be perfect for extending such a
>page to be even more useful.
>Just think of it. You are visiting a huge site wich contains a lot of useful
>stuf in a lot of different places. You are offered the possibility to create
>your own customased "home Page" which containes only the stuff that you are
>interested of and a section of What is new on the site. I addition you have
>alle the toy's
>  
>

Re: [Pbwebgui-development] Idea: "My Home" page.

[Nils-Magne K. <nil...@kv...>]

The company i work for use Microsoft Sharepoint portal server, and the
intranet is huge and covers four different languages. This intranet is
loaded with information that is crusial for us to do our daily job. And it
is possible for us to find nearly everything on this intranet. But it has a
feature that it's called "My Home Page", this page is a spesial page with a
predifined layout (5-6 regions) where onely you as a user have the rights to
view.
To populate this page you can view any page on the intranet and clik on a
link on that page that say's "put on My Home Page" it then copys itself to
one of the regions on "My Home Page" and you hav instant acsess to it. The
administrator desides which region a page should be placed in.
In the end we end up with a page that is customased to each persons need. If
WebGUI could extend this furtermore with the ability to not put the whole
page in this page but elements from the page too... that would be great. And
your plannes for the dashboard wobject would be perfect for extending such a
page to be even more useful.
Just think of it. You are visiting a huge site wich contains a lot of useful
stuf in a lot of different places. You are offered the possibility to create
your own customased "home Page" which containes only the stuff that you are
interested of and a section of What is new on the site. I addition you have
alle the toy's
> Here are some we have planned: stock ticker, rss feed
> viewer, weather, server monitor, todo list, calculator, discussion
agregator (gets data
> from all the discussions in WebGUI), mini calendar, pop3 watcher, link
list, box scores
> (sports scores).
This begin to look like my "startup Page"

This was my understanding of what Roy meant and extended with the thoughts
of JT, I can only say that this feature would bring WebGUI a big step
forward.

Nils-Magne
----- Original Message ----- 
From: "JT Smith" <jt...@pl...>
To: <pbw...@li...>
Sent: Wednesday, July 07, 2004 5:07 AM
Subject: Re: [Pbwebgui-development] Idea: "My Home" page.


> This is part of the 7.x roadmap, which we have not yet publicly published.
I think it's
> in 7.1, but that's a long way off.
>
> What we have planned is a dashboard wobject. The dashboard will have some
sort of
> pluggable component (portlet, widget, gizmo, dashlet, whatever). Each
component will
> serve a different function. Here are some we have planned: stock ticker,
rss feed
> viewer, weather, server monitor, todo list, calculator, discussion
agregator (gets data
> from all the discussions in WebGUI), mini calendar, pop3 watcher, link
list, box scores
> (sports scores). When in admin mode the the administrator creates a
default state for
> the dashboard, file drawer (an upload place to store files). When a new
user (except
> visitor, they get the default) browses to the dashboard, a clone of the
default is made
> for them, and they can then add/remove/rearrange to their hearts content.
Each component
> will have three "views": class properties (only admin can set), instance
properties (the
> user sets), and display (the resulting output). The user can also
configure how many
> columns the dashboard has, the width of each columan, and the organization
of the
> dashlets in each column.
>
>
> On Tue, 06 Jul 2004 22:37:13 -0400
>   "Roy Johnson" <RJo...@sp...> wrote:
> >I would like to develop a "My Home" page for WebGUI.  I looked at the
Roadmap for 6.x
> >and did not see this on the list.  Basically what I'm referring to is a
page that is
> >unique to every registered user in WebGUI on which they can do everything
one could do
> >when adding a normal page in WebGUI.
> >
> >This would basically be like a sandbox for each user to put things
(content) that they
> >found useful.  In our company, we use WebGUI to run our corporate
intranet so this
> >would be extremely useful to us.
> >
> >I'm thinking it could work something like this:
> >
> >1) User logs in and within the navigation system there is automatically a
link to "My
> >Home" or something similar.
> >
> >2) When the user clicks on this page they are free to do everything they
could do on a
> >regular page that was added in WebGUI.  The difference would be that the
content on the
> >page would be unique to their login.
> >
> >Has this concept/idea been explored before?  Can anyone think of a way to
implement
> >this functionality within WebGUI as it exists now?
> >
> >If anyone has any ideas on ways to approach this or would be interested
in working on
> >it with me please let me know.  I'm fairly new to the WebGUI API but am
willing to
> >devote a large amount of time to the project.
> >
> >Comments/Feedback/Flames are welcomed {:-)  Thanks!
> >
> >Roy
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email sponsored by Black Hat Briefings & Training.
> >Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> >digital self defense, top technical experts, no vendor pitches,
> >unmatched networking opportunities. Visit www.blackhat.com
> >_______________________________________________
> >Pbwebgui-development mailing list
> >Pbw...@li...
> >https://lists.sourceforge.net/lists/listinfo/pbwebgui-development
>
>
> JT ~ Plain Black
>
> Create like a god, command like a king, work like a slave.
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Pbwebgui-development mailing list
> Pbw...@li...
> https://lists.sourceforge.net/lists/listinfo/pbwebgui-development
>

Re: [Pbwebgui-development] Idea: "My Home" page.

[David S. <dp...@di...>]

Sounds a lot like a user-customizable "portal" page to me.

He says the home page would have a link to a "My Home Page", and when you click this link
you'd get a page that's totally under your own control.

Doesn't sound that much different than what would be needed to support "self-replicating"
sites, except he's postulating that the user needs to be logged in first.

Consider two options:

(1) A URL like "www.mysite.com/joe" would bring up joe's page

(2) Or, going to "www.mysite.com" and then logging in as "joe" would present a link to
"www.mysite.com/joe" as "My Home Page".  (Unless there's supposed to be some kind of
polymorphic "virtual" link named, eg., "my_home_page" that the system knows how to render
for each logged-in user automatically.  This would be rather complicated.)

A flag somewhere would say whether it's public, like (1), or totally private, like (2).  Or,
perhaps, the page could have both public and private things on it.  (I think this latter bit
is already supported if you've got WObject perms enabled.)

Anyway, this is doable now, but the Admin has to jump through a lot of hoops to manually
create the initial page and proper groups and ownership for each user.  To do this
automatically (if you don't go the "polymorphic virtual link" route), then you need to be
able to: create a new user and group and make the proper associations; create a new page
with a specific template (layout); instantiate a predefined Package on that page that fits
its template (layout); and finally set the new user as the owner (and content manager) of
the page.

It would be doubly great if a new class of user was defined that can perform these
operations (eg., "Portal Manger") independently of most other user classes (ie, any
Registered User can be ordained a Portal Manager without having to be an Admin).

It would be tripley great if this process could be almost entirely automated, similar to
signing up as an affiliate and giving the Admin the option of saying whether to run this
process automatically, or queue it up somehow pending approval by a Portal Manager.

-David

JT Smith wrote:

> After re-reading your post I'm unsure whether my initial impression of what you're
> looking to do is correct.
>
> Are you looking to have a way for users to publish their own web site within a site sort
> of like sub-sites for each user (for public viewing), or are you looking for a place
> where users can set up for their own needs (only they can see it)?
>
> On Tue, 06 Jul 2004 22:37:13 -0400
>   "Roy Johnson" <RJo...@sp...> wrote:
> >I would like to develop a "My Home" page for WebGUI.  I looked at the Roadmap for 6.x
> >and did not see this on the list.  Basically what I'm referring to is a page that is
> >unique to every registered user in WebGUI on which they can do everything one could do
> >when adding a normal page in WebGUI.
> >
> >This would basically be like a sandbox for each user to put things (content) that they
> >found useful.  In our company, we use WebGUI to run our corporate intranet so this
> >would be extremely useful to us.
> >
> >I'm thinking it could work something like this:
> >
> >1) User logs in and within the navigation system there is automatically a link to "My
> >Home" or something similar.
> >
> >2) When the user clicks on this page they are free to do everything they could do on a
> >regular page that was added in WebGUI.  The difference would be that the content on the
> >page would be unique to their login.
> >
> >Has this concept/idea been explored before?  Can anyone think of a way to implement
> >this functionality within WebGUI as it exists now?
> >
> >If anyone has any ideas on ways to approach this or would be interested in working on
> >it with me please let me know.  I'm fairly new to the WebGUI API but am willing to
> >devote a large amount of time to the project.
> >
> >Comments/Feedback/Flames are welcomed {:-)  Thanks!
> >
> >Roy
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email sponsored by Black Hat Briefings & Training.
> >Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> >digital self defense, top technical experts, no vendor pitches,
> >unmatched networking opportunities. Visit www.blackhat.com
> >_______________________________________________
> >Pbwebgui-development mailing list
> >Pbw...@li...
> >https://lists.sourceforge.net/lists/listinfo/pbwebgui-development
>
> JT ~ Plain Black
>
> Create like a god, command like a king, work like a slave.
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Pbwebgui-development mailing list
> Pbw...@li...
> https://lists.sourceforge.net/lists/listinfo/pbwebgui-development

Re: [Pbwebgui-development] Idea: "My Home" page.

[JT S. <jt...@pl...>]

After re-reading your post I'm unsure whether my initial impression of what you're 
looking to do is correct.

Are you looking to have a way for users to publish their own web site within a site sort 
of like sub-sites for each user (for public viewing), or are you looking for a place 
where users can set up for their own needs (only they can see it)?


On Tue, 06 Jul 2004 22:37:13 -0400
  "Roy Johnson" <RJo...@sp...> wrote:
>I would like to develop a "My Home" page for WebGUI.  I looked at the Roadmap for 6.x 
>and did not see this on the list.  Basically what I'm referring to is a page that is 
>unique to every registered user in WebGUI on which they can do everything one could do 
>when adding a normal page in WebGUI.
>
>This would basically be like a sandbox for each user to put things (content) that they 
>found useful.  In our company, we use WebGUI to run our corporate intranet so this 
>would be extremely useful to us.
>
>I'm thinking it could work something like this:
>
>1) User logs in and within the navigation system there is automatically a link to "My 
>Home" or something similar.
>
>2) When the user clicks on this page they are free to do everything they could do on a 
>regular page that was added in WebGUI.  The difference would be that the content on the 
>page would be unique to their login.
>
>Has this concept/idea been explored before?  Can anyone think of a way to implement 
>this functionality within WebGUI as it exists now?
>
>If anyone has any ideas on ways to approach this or would be interested in working on 
>it with me please let me know.  I'm fairly new to the WebGUI API but am willing to 
>devote a large amount of time to the project.  
>
>Comments/Feedback/Flames are welcomed {:-)  Thanks!
>
>Roy
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>digital self defense, top technical experts, no vendor pitches, 
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>Pbwebgui-development mailing list
>Pbw...@li...
>https://lists.sourceforge.net/lists/listinfo/pbwebgui-development


JT ~ Plain Black

Create like a god, command like a king, work like a slave. 

Re: [Pbwebgui-development] Idea: "My Home" page.

[Jay R. A. <jr...@ba...>]

On Tue, Jul 06, 2004 at 10:37:13PM -0400, Roy Johnson wrote:
> I would like to develop a "My Home" page for WebGUI. I looked at the
> Roadmap for 6.x and did not see this on the list. Basically what I'm
> referring to is a page that is unique to every registered user in
> WebGUI on which they can do everything one could do when adding a
> normal page in WebGUI.
>
> This would basically be like a sandbox for each user to put things
> (content) that they found useful. In our company, we use WebGUI to run
> our corporate intranet so this would be extremely useful to us.

Hmmm...

> I'm thinking it could work something like this:
>
> 1) User logs in and within the navigation system there is
> automatically a link to "My Home" or something similar.
>
> 2) When the user clicks on this page they are free to do everything
> they could do on a regular page that was added in WebGUI. The
> difference would be that the content on the page would be unique to
> their login.
>
> Has this concept/idea been explored before? Can anyone think of a way
> to implement this functionality within WebGUI as it exists now?

My snap reaction is that MyHomePage and MySandbox are both useful, but
they're *different*.

MySandbox is a page that is visible only to a logged in user and
looks different to each one even though it's in the same place in the
navtree for everyone.

MyHomePage is a page that is automatically a directory of all
registered users, and a link to a page owned by that user, but which
*is* visible to everyone including visitors (by default).

Or so it seems to me.

Was that clear enough?  On reflection, I'm not entirely sure I made the
distinction I wanted to...

> If anyone has any ideas on ways to approach this or would be
> interested in working on it with me please let me know. I'm fairly new
> to the WebGUI API but am willing to devote a large amount of time to
> the project.

The latter one is slightly less unobvious to implement, so it seems to
me, but they're both useful...

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jr...@ba...
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	"You know: I'm a fan of photosynthesis as much as the next guy,
	but if God merely wanted us to smell the flowers, he wouldn't 
	have invented a 3GHz microprocessor and a 3D graphics board."
					-- Luke Girardi