pas-dev — Development mailing list.

[Pas-dev] more on generic DB session obj

[Justin B. <ju...@le...>]

Poking around the directory some more:

- Org::Bgw::Pas::Session::MySQL becomes Org::Bgw::Pas::Session::DB.  _factory() 
method gets re-written to look up the driver from the config file and 
instantiate the appropriate DB factory driver for the session.

- Then we create a new Org::Bgw::Pas::Session::Factory.  Stuff that can be moved 
from Org::Bgw::Pas::Session::MySQL::Factory will be moved into this new class.

- The MySQL directory gets moved to a new name Factory.

- Org::Bgw::Pas::Session::MySQL::Factory becomes 
Org::Bgw::Pas::Session::Factory::MySQL.  All generic stuff is striped so it's 
MySQL specific and it's parent becomes Org::Bgw::Pas::Session::Factory.

- In the conf file we should add the driver to make it easy for the person to 
tell the app what DB they want to run for the session.  So you'll now have up to 
7 session variables for the config file:

   pas.session.dbname
   pas.session.driver
   pas.session.dsn
   pas.session.hostname
   pas.session.password
   pas.session.table
   pas.session.username

Of course, if you specify the dsn, you can skip the dbname & hostname.  The 
driver parameter will be a requirement!

Any questions?  Does this sound good?  Can I take a chain saw to it?  I'll at 
least get this working for MySQL in the near future.  Other implementations 
shouldn't be hard.

Justin

[Pas-dev] generic session DB factory

[Justin B. <ju...@le...>]

docs/proposals/genericSessionDbFactory

justin

Kyle R . Burton wrote:
> Excellent!  Would you mind writing that up as a proposal and checking it
> in to the archive?

[mortis@voicenet.com: Re: [Pas-dev] proposal: drop the Org::Bgw prefix in favor of just Pas]

[Kyle R . B. <mo...@vo...>]

----- Forwarded message from "Kyle R . Burton" <mo...@vo...> -----

Date: Fri, 17 May 2002 14:25:07 -0400
From: "Kyle R . Burton" <mo...@vo...>
To: Mental <me...@ne...>
Subject: Re: [Pas-dev] proposal: drop the Org::Bgw prefix in favor of just Pas
Reply-To: "Kyle R . Burton" <mo...@vo...>
X-Mailer: Mutt 095 us
In-Reply-To: <1021659278.15893.26.camel@warpath>; from Mental on Fri, May 17, 2002 at 02:14:37PM -0400

Proposal: Namespace change from Org::Bgw => Pas

> Its just a namespace thing. 

Agreed.  That's all it is.

> -PI (because).
>
> You're determined to make it as difficult as possible for me to do
> concurrent development arent you? :)

We can vote on it.  

We can always vote to deferr implementing it until some later date.

It will be a whole lot easier to do now than it will be later. :-P
The core issue is do we want to?  If we do, then the sooner the better.
Imagine having to fix applications down the road?

If we all reach a freeze, have 1 or 2 people make the change, everyone
can then just throw away their current working directories and do a new
checkout.   Could be fairly straightforward...


If there are other lingering issues like this, plesae speak up about them 
now.  We might vote them down now but pick them up again at some future date.
These kinds of things will have a massive impact, the sooner we bit the
bullet and get them over with, the better off we will be in the long
run.


votes?


Kyle



-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

----- End forwarded message -----

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

Re: [mortis@voicenet.com: Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config]

[Kyle R . B. <mo...@vo...>]

Excellent!  Would you mind writing that up as a proposal and checking it
in to the archive?

> >>+1 for some kind of Base SQL object and have PostgreSQL & MySQL derive from it.
> > 
> > 
> > Do you have any ideas for how to do this?  If you do, write up a proposal
> > on how to do it.
> 
> First off, in the config file, remove all references to mysql in the pas.session 
> name space.  ;)
> 
> Looking at Org::Bgw::Pas::Session::MySQL::Factory:
> 
> - All the constants can go in the parent object.
> 
> - load_session_rec() should be able to go in the parent without having to be 
> overridden.  Am I correct or making too much of an assumption?  Just because I'm 
> not sure of the blob issues between Mysql, PostgreSQL, Oracle, etc.
> 
> - store_session_rec() goes in the parent.
> 
> - update_session_rec() becomes an abstract method in the parent.  It must be 
> ovewritten.
> 
> - insert_session_rec() will follow update_session_rec() lead.
> 
> - update_atime_for_session_rec() goes in the parent(?).
> 
> - db_hostname(), db_dbname(), db_table(), get_username(), get_password() all to 
> the parent class.
> 
> - get_dsn() goes to the parent with one modification.  We add an abstract method 
> namded db_driver() to the parent.  db_driver() will return a constant value of 
> "mysql" or "Pg" or etc. in the child depending on the class.  Unless the dns 
> syntax is that different from DB to DB.  I guess it also depends on how 
> someone's configured their DB connections too.  Either way, it's easy enough to 
> abstract to the children.  And if we get the generic way to work, just put a 
> note in the docs of what to look for to override.
> 
> Justin
> 

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

[Pas-dev] basic unit testing....

[Kyle R . B. <mo...@vo...>]

The framework is in place, just run bin/runUnitTests and it'll do whats
advertised.

There is only 1 unit test for now: Org::Bgw::BaseTest that has 2 methods
in it, one to test construction, and 1 to test the config() method.

So the framework is in place...I now expect all of us to start writing
good unit tests for the codebase.

:)

I also expect _all_ new code to be accompanied by a unit test.  At a
minimum, the unit tests ensure at least compilation success by virtue 
that the unit test that accompanies a package/module/object will use it.

The convention that I'm setting forth is that each pakcage/file/module will
have an assocaited unit test in the same directory in the codebase (see
Base and BaseTest).  The test name will be the object name with Test as
a suffix:

  Object.pm => ObjectTest.pm

If we follow this convention, then the test runner in bin will automatcally
pick up every single unit test in the src subdirectory.

I know some people like unit tests in sepearate directoires, but I feel
that if it's in the same directory as the object its testing, the developer
will be more likely to keep it up to date.

  [user@host Bgw]$ vi Base*.pm


When we get to the point where we're starting component, system or integration
testing, we can create a testing directory structure:

  ${PAS_BASE}/testing/component
  ${PAS_BASE}/testing/system
  ${PAS_BASE}/testing/integration





Kyle


-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

Re: [Pas-dev] proposal: drop the Org::Bgw prefix in favor of just Pas

[Mental <me...@ne...>]

On Fri, 2002-05-17 at 13:05, Kyle R . Burton wrote:
> Proposal:
> 
>   That would be a huge change to the codebase, but it would give us
>   the opportunity to implement the current crop of proposals all at once
>   and probably cleanly.
> 
>   It'd make for shorter packge names (nicer), and the Org::Bgw prefix is 
>   no longer appropraite now that the project is no longer hosted on bgw.org.
> 
> Impact:
>   The entire project, not just the core codebase.
> 

Its just a namespace thing. 
-PI (because).

You're determined to make it as difficult as possible for me to do
concurrent development arent you? :)



-- 
Mental (Me...@Ne...)

Re: [mortis@voicenet.com: Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config]

[Justin B. <ju...@le...>]

>>+1 for some kind of Base SQL object and have PostgreSQL & MySQL derive from it.
> 
> 
> Do you have any ideas for how to do this?  If you do, write up a proposal
> on how to do it.

First off, in the config file, remove all references to mysql in the pas.session 
name space.  ;)

Looking at Org::Bgw::Pas::Session::MySQL::Factory:

- All the constants can go in the parent object.

- load_session_rec() should be able to go in the parent without having to be 
overridden.  Am I correct or making too much of an assumption?  Just because I'm 
not sure of the blob issues between Mysql, PostgreSQL, Oracle, etc.

- store_session_rec() goes in the parent.

- update_session_rec() becomes an abstract method in the parent.  It must be 
ovewritten.

- insert_session_rec() will follow update_session_rec() lead.

- update_atime_for_session_rec() goes in the parent(?).

- db_hostname(), db_dbname(), db_table(), get_username(), get_password() all to 
the parent class.

- get_dsn() goes to the parent with one modification.  We add an abstract method 
namded db_driver() to the parent.  db_driver() will return a constant value of 
"mysql" or "Pg" or etc. in the child depending on the class.  Unless the dns 
syntax is that different from DB to DB.  I guess it also depends on how 
someone's configured their DB connections too.  Either way, it's easy enough to 
abstract to the children.  And if we get the generic way to work, just put a 
note in the docs of what to look for to override.

Justin

Re: [mortis@voicenet.com: Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config]

[Justin B. <ju...@le...>]

-1 for not being able to hit REPLY ALL!  :P

Kyle R . Burton wrote:
> ----- Forwarded message from "Kyle R . Burton" <mo...@vo...> -----
> 
> Date: Fri, 17 May 2002 12:46:12 -0400
> From: "Kyle R . Burton" <mo...@vo...>
> To: Justin Bedard <ju...@le...>
> Subject: Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config
> Reply-To: "Kyle R . Burton" <mo...@vo...>
> X-Mailer: Mutt 095 us
> In-Reply-To: <3CE...@le...>; from Justin Bedard on Fri, May 17, 2002 at 12:34:13PM -0400
> 
> 
>>+1 for PSP templates for DB record obj gen.
>>+1 for log4j (it's big pimpin'!)
>>+1 for TestCase
>>+1 for Error.pm
>>+1 for makeGetSet() altho in a web application, we really haven't seen
>>the performance hit of gss() but it does clean up some stuff.
> 
> Every little bit means more latency on the site, and less scalability.  
> Besides, it's an infrastructure issue, _and_ it's effectivly bettern than
> free, you get benefit (clartiy, maintainability, speed) with less cost 
> (less lines of code to write).

I agreed with the clarity.  Most of the time clarity can equal maintainability. 
  I already know it means speed.  Previous job we didn't run into the speed 
issue.  Current job we did but we're using gss() outside of PAS.

>>+1 for improving security
> 
> That's the input filter for script/embed tags just to make it clear.
> 
> I'll go and update the status on these as accepted but needs implementing.
 >
>>+1 for Jason (so he can vote twice this one time)
> 
> No, no developer get's more than 1 vote. (I know I'll come to regret this
> at some point, but we're a community not a tyranny).

But a dictatorship on how we vote is allowed?!?!  :P

>>+1 for some kind of Base SQL object and have PostgreSQL & MySQL derive from it.
> 
> Do you have any ideas for how to do this?  If you do, write up a proposal
> on how to do it.

I'd have to look at the code.  It's been too long.

>>+1 to just have a PostgreSQL plugin.
>>+1 for type checking.  i guess we can have different makeGetSets... 
>>makeGetSetString(), makeGetSetInt(), makeGetSetFloat(), etc.
> 
> Hrm...that could be a good thing.  Though for SQL purposes, we also
> want to track precision -- INTEGER(2) vs NUMBER(14).  That of course

Well, you could end up passing it an integer during construction so that it will 
also check length if that integer is defined.  You can't do:

makeGetSet(qw( foo bar kyle dictator ))

So you sorta go back to some of the maintenance issues of gss() but not nearly 
as bad.  Just thinking out loud.  Might be a better way to get length check in 
there.

> raises yet other issues with database differences -- MySQL, Oracle,
> and PostgreSQL all uses different types for their columns....should we
> just leave these validation routines up to the PSP templates?  Or a parent
> object written for just such a purpose?  Actualy, that's not a bad idea:
> 
>  Org::Bgw::Pas::Db::RecBase
>    |
>    +--Org::Bgw::Pas::Db::MySQLRec
>    |
>    +--Org::Bgw::Pas::Db::PgRec
> 
> Could RecBase do most of the abstracted stuff?  With the derived
> ones deferred to for the actual implementations?  How would that work
> for these type validation/checking issues?

Possibly.  Still need to look into how to implement length checking.

>>-1 for Kyle for not letting both of Jason's brain cells vote.
>>
>>did i cover them all?
> 
> How about _writing_ either documentation or, better yet, code 
> instead of just voting?  eh?

I'm a slow reader.  I'm just having problems keeping up with these emails.  :P 
How about I finish the address matching stuff first for my J-O-B.  ;)

Justin

[Pas-dev] proposal: drop the Org::Bgw prefix in favor of just Pas

[Kyle R . B. <mo...@vo...>]

Proposal:

  That would be a huge change to the codebase, but it would give us
  the opportunity to implement the current crop of proposals all at once
  and probably cleanly.

  It'd make for shorter packge names (nicer), and the Org::Bgw prefix is 
  no longer appropraite now that the project is no longer hosted on bgw.org.

Impact:
  The entire project, not just the core codebase.



?

Kyle


-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

[mortis@voicenet.com: Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config]

[Kyle R . B. <mo...@vo...>]

----- Forwarded message from "Kyle R . Burton" <mo...@vo...> -----

Date: Fri, 17 May 2002 12:46:12 -0400
From: "Kyle R . Burton" <mo...@vo...>
To: Justin Bedard <ju...@le...>
Subject: Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config
Reply-To: "Kyle R . Burton" <mo...@vo...>
X-Mailer: Mutt 095 us
In-Reply-To: <3CE...@le...>; from Justin Bedard on Fri, May 17, 2002 at 12:34:13PM -0400

> +1 for PSP templates for DB record obj gen.
> +1 for log4j (it's big pimpin'!)
> +1 for TestCase
> +1 for Error.pm
> +1 for makeGetSet() altho in a web application, we really haven't seen
> the performance hit of gss() but it does clean up some stuff.

Every little bit means more latency on the site, and less scalability.  
Besides, it's an infrastructure issue, _and_ it's effectivly bettern than
free, you get benefit (clartiy, maintainability, speed) with less cost 
(less lines of code to write).

> +1 for improving security

That's the input filter for script/embed tags just to make it clear.

I'll go and update the status on these as accepted but needs implementing.

> +1 for Jason (so he can vote twice this one time)

No, no developer get's more than 1 vote. (I know I'll come to regret this
at some point, but we're a community not a tyranny).

> +1 for some kind of Base SQL object and have PostgreSQL & MySQL derive from it.

Do you have any ideas for how to do this?  If you do, write up a proposal
on how to do it.

> +1 to just have a PostgreSQL plugin.
> +1 for type checking.  i guess we can have different makeGetSets... 
> makeGetSetString(), makeGetSetInt(), makeGetSetFloat(), etc.

Hrm...that could be a good thing.  Though for SQL purposes, we also
want to track precision -- INTEGER(2) vs NUMBER(14).  That of course
raises yet other issues with database differences -- MySQL, Oracle,
and PostgreSQL all uses different types for their columns....should we
just leave these validation routines up to the PSP templates?  Or a parent
object written for just such a purpose?  Actualy, that's not a bad idea:

 Org::Bgw::Pas::Db::RecBase
   |
   +--Org::Bgw::Pas::Db::MySQLRec
   |
   +--Org::Bgw::Pas::Db::PgRec

Could RecBase do most of the abstracted stuff?  With the derived
ones deferred to for the actual implementations?  How would that work
for these type validation/checking issues?

> -1 for Kyle for not letting both of Jason's brain cells vote.
> 
> did i cover them all?

How about _writing_ either documentation or, better yet, code 
instead of just voting?  eh?

:)

Kyle

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

----- End forwarded message -----

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config

[Justin B. <ju...@le...>]

Kyle R . Burton wrote:
>>>Does this make sense?  Then you can just substitute out the particular
>>>psp template that generates the recod objects in the way you like it to.
>>>
>>>The templates will be infinitly easier to create and maintain than the
>>>current borked generator design.
>>>
>>
>>+2. Dont worry if someone else doesnt like it. I like it enough for both
>>of us. :)
> 
> 
> Hey, we each only get 1 vote.  This might be a meritocracy, but we're going
> to run it as much like a democracy as possible.
> 
> 1 vote per develpoer.
> 
> So thats 2 in favor of PSP templates for db record object generation and 0
> against.
> 
> I think we need 3 for a majority.

didn't you get my rash of +1s?

+1 for PSP templates for DB record obj gen.
+1 for log4j (it's big pimpin'!)
+1 for TestCase
+1 for Error.pm
+1 for Jason (so he can vote twice this one time)
+1 for some kind of Base SQL object and have PostgreSQL & MySQL derive from it.
+1 to just have a PostgreSQL plugin.
+1 for makeGetSet() altho in a web application, we really haven't seen
the performance hit of gss() but it does clean up some stuff.
+1 for type checking.  i guess we can have different makeGetSets... 
makeGetSetString(), makeGetSetInt(), makeGetSetFloat(), etc.
-1 for Kyle for not letting both of Jason's brain cells vote.
+1 for improving security

did i cover them all?

justin

[Pas-dev] commited stuff

[Mental <me...@ne...>]

added a dataInquisitor proposal. 


-- 
Mental (Me...@Ne...)

[Pas-dev] added proposal dbRecordGeneration

[Kyle R . B. <mo...@vo...>]

Subject says it all

Kyle

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

[Pas-dev] I added proposals: doc/proposals

[Kyle R . B. <mo...@vo...>]

For exceptions and unit tests.

They have a pretty simple layout:

  Status:
  Propsal:
  Rationale:
  Impact:
  References:

Should make working as a team easier...

k

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

Re: [Pas-dev] css (security)

[Mental <me...@ne...>]

On Fri, 2002-05-17 at 12:05, Kyle R . Burton wrote:
> > I'm afraid you're off on the angle bracket thing. That was only one of
> > my half baked ideas. The other was deterministicly looking for=20
> > <SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>
> > The angle bracket thing was my over simplified method for dealing with
> > them.=20
>=20
> I like this.  That would be a nice filter to have.  This would be an
> inbound filter for query data correct?  I am liking this more and more...
>=20

Yes.

<snip>
> You konw if we have this feature, it'll set our product apart from
> most of the other web development systems out there...
>=20
>=20

Like dynamic recompilation based on changes to include files? :)


> Thanks for the idea Jason!
>

Dont thank me til you see the code. :/


So far on my TODO is:
Postges Episode 1: Make It Go
Inbound Request Data: The Inquisition
Page Object Metadata Objects: The Recursion of the Page Object Metadata
Objects


=20
> Kyle
>=20
> --=20
>=20
> -------------------------------------------------------------------------=
-----
> Wisdom and Compassion are inseparable.
>         -- Christmas Humphreys
> mo...@vo...                            http://www.voicenet.com/~m=
ortis
> -------------------------------------------------------------------------=
-----
>=20
> _______________________________________________________________
>=20
> Hundreds of nodes, one monster rendering program.
> Now that=92s a super model! Visit http://clustering.foundries.sf.net/
> _______________________________________________
> Pas-dev mailing list
> Pa...@li...
> https://lists.sourceforge.net/lists/listinfo/pas-dev
--=20
Mental (Me...@Ne...)

Re: [Pas-dev] another proposal Test::Unit::TestCase

[John B. <jo...@po...>]

Hello,

I reckon this would be an excellent thing to do.

I've been using Test::Unit::TestCase at home and a different JUnit port at
work.

It's a really, really good idea Kyle.

My vote is a "+1".

John.



----- Original Message -----
From: "Kyle R . Burton" <mo...@vo...>
To: "Pas Dev" <pa...@li...>
Sent: Friday, May 17, 2002 4:53 PM
Subject: [Pas-dev] another proposal Test::Unit::TestCase


> Test::Unit::TestCase is the Perl equivalent of JUnit.  I've used it at
> my current employer and would like to institute it's use in Pas.  Again,
> it's not Java (I have also used the C++ version), it's just a good unit
> testing framework.
>
> You write your test cases like this:
>
>   package ObjectTest; # tests Object
>   use strict;
>   use warnings;
>   use Test::Unit::TestCase;
>   use Test::Unit::Assertion::Boolean;
>   our @ISA = qw( Test::Unit::TestCase );
>
>   sub test_construction
>   {
>     my($self) = @_;
>     my $obj = Object->new();
>     $self->assert( $obj, "Error, construction failed" );
>   }
>
> Then you run it with a simple test runner -- I usualy write one that
> finds all .pm files that end in *Test.pm and create a test suite,
> then runs them all in a single suite -- that way it's one command to
> run the entire set of unit tests.
>
>
> I would _really_ like to institute this.  It makes writing unit tests
> stupid simple.  The easier that is, the more likely it is that we'll
> have unit tests to begin with.
>
>
> Votes?  +1/-1?
>
> My vote is of course +1
>
> k
>
>
> --
>
> --------------------------------------------------------------------------
----
> Wisdom and Compassion are inseparable.
>         -- Christmas Humphreys
> mo...@vo...
http://www.voicenet.com/~mortis
> --------------------------------------------------------------------------
----
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> Pas-dev mailing list
> Pa...@li...
> https://lists.sourceforge.net/lists/listinfo/pas-dev

Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config

[Kyle R . B. <mo...@vo...>]

> > Does this make sense?  Then you can just substitute out the particular
> > psp template that generates the recod objects in the way you like it to.
> > 
> > The templates will be infinitly easier to create and maintain than the
> > current borked generator design.
> > 
> 
> +2. Dont worry if someone else doesnt like it. I like it enough for both
> of us. :)

Hey, we each only get 1 vote.  This might be a meritocracy, but we're going
to run it as much like a democracy as possible.

1 vote per develpoer.

So thats 2 in favor of PSP templates for db record object generation and 0
against.

I think we need 3 for a majority.


k


-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config

[Douglas R. <dou...@mi...>]

Kyle R . Burton wrote:
>>Sounds reasonable. I often get the feeling we're following java at this
>>point. I suppose we are. Still, its a good idea. I can see it being
>>useful.
> 
> 
> Yea and no.  We're modeling the good aspects of JSP and the servelt model
> as those aspects translate and work well in the Perl/mod_perl arena.
> 
> The log4j package is not Java, it is just a really good logging package that
> happens to have been first written in Java.  Now it's available for Perl,
> and it's good, so I say we use it.
> 
> That's 2 +1s, anyone else have an opinion?

sounds good.  +1.

>>>Second proposal: Exception handling
>>
>>It didnt silently fail, it was in pas.log, just not in the browser. But
>>yes. Why reinvent the wheel? Error.pm does indeed have some nice
>>to-haves. Leverage CPAN and note it in the INSTALL.
> 
> 
> That's 2 +1s, anyone else have an opinion?

also good.  yah.  +1.

>>>Third proposal: get rid of _gss()/_get_set_scalar()
>>
>>I agree for different reasons. I feel generic get/set functions are
>>error prone. Except in the most basic situations they're probably not
>>what you want. If its just a string to display, remember it. 
> 
> 
> What errors?  Their purpose is to keep you from writing the ever present
> standard get/set functions.  That's all - if you need more functionality,
> then don't use it, write the get/set yourself and add in the desired
> behavior.  Just because it's there doesn't mean you have to use it, it's
> optional so you don't have to use it if it's not appropriate.
> 
> 
>>The context of this will determine if I like it or not. 
> 
> 
> The only difference between makeGetSetMethods() and _gss() is that
> _gss is slower, and you have to write more code, which opens up possibilities
> for errors.  That's it.
> 
> I know I've doen this before:
> 
>   sub foo {shift->_gss('foo');}
> 
> and wasted time debugging it, when it should have been:
> 
>   sub foo {shift->_gss('foo',@_);}
> 
> makeGetSet is better for these kinds of programmer errors.  It is also
> faster because there is 1 level of function call involved, not two.  It's
> also faster, because you're not shifting @_ to call your parent's _gss()
> method.

i'd have to think about it some more, but makeGetSet does sound useful.  +1.

<snip>

>>I do have a fourth proposal.
>>
>>four: Modify object generator to gen smarter objects.
> 
> 
> I personaly like this.  On a project Justin and I just did, and in 
> some conversations I had with Andy, we want to generate the proper
> SQL staemetns for SELECT,INSERT,UPDATE and DELETE.  That way they
> can deferr to a parent object for these operatsions -- the generated
> record objects will be smart enough to know how to perform these operations
> on themselves.  For the project Justin and I worked on, we only wrote
> sql statements for reporting purposes.  Of the few hundred sql statemetns
> we would have had to write for the 30 or so database tables, they all
> got handled implicitly by the code in the generated objects.  That saved
> us no end of time.  Of course it's not necessarily the most optimized
> SQL code, but we optmized afterwards when we saw hotspots in the 
> application, which ended up being about 2 places.
> 
> 
> 
>>I think we can make db records be smart enough that when I call a get
>>set with bad data, the object catches it and yells.
>>
>>Thus, if an object is generated and has a get/set for a number 2 column,
>>and  call $obj->foo('string'), it shouldn't like it. My argument for
>>doing this is its easier to do when generating an object than it is when
>>trying to store an object. Its too error prone. And getting exceptions
>>on insert doesnt always tell me _which_ value was too large for a
>>column. The side effect of this is that we're probably going to have to
>>subclass objectgenerator for every database we support to deal with
>>their different personalitys. Since we currently only support MySQL,
>>this isnt a huge amount of work. However, going forward, the question of
>>access to every possible backend becomes an issue.
> 
> 
> I like the idea of adding in type checking or validation.  We could
> either make that a switch on the generator, or a run-time swtich so
> you could use it in development, and turn it off for production for
> speed/performance reasons.
> 
> 
>>What do you think? This lack of data checking in generated objects is
>>making me seriously rethink their merits. Sure it takes longer, but I
>>can write an object by hand that will not accept bad data. I'd rather
>>spend the time up front writing the object, than debugging on insert
>>errors.

very good idea.  =)  despite admittedly having only 2 brain cells, jason 
comes up with another good idea.  8^)

> I have a new proposal for the generator.  The current appraoch sucks.
> I don't think we need to sub-class the generator, we need to throw it away.  
> As It is currently written it is a bad approach (too much maintenence).
> 
> I propose that we do what Justin and I did for the last project at HMS:
> use PSP to generate the objects.  It's _soo_ much easier.  We write
> a driver program:
> 
>   dbRecGenerator.pl --dbiDsn="dsnString" --dbUser=user --dbPass=pass \
>      --dbTable=TABLE_NAME --genClassName=Some::Class::RecName \
>      --pspTemplate=recGen.psp
>      
> The driver program connects to the database, and puts togeather a data
> structure (or better yet, an object) that has all of the data about the
> table.  Then the PSP looks like this:
> 
>   <%
>     my $tableInfo = $self->query()->param('tableInfo');
>     my $packageName = $self->query()->param('packageName');
>   %>package <%= $packageName %>;
>   use strict;
>   use warnings;
>   <%
>     foreach my $use ( @someListOfObjectsToUse ) {
>   %>
>   use <%= $use %>;
>   <%
>     }
>   %>
>   our @ISA = qw( <%= @ourParentList %> );
> 
>   <% foreach my $colInfo ( $tableInfo->columns() ) { %>
>   sub <%= $colInfo->functionName() %>
>   {
>     my($self) = @_;
>     if( @_ > 2 ) { # a set
>       $self->validate<%= $colInfo->functionName() %>($_[1]);
>       return $self->setVal(x,y,z); # something like that
>     }
> 
>     # put get code here
>   }
> 
>   sub validate<%= $colInfo->functionName() %>
>   {
>     my($self,$val) = @_;
>     # do your validation based on the col type and precision here...
>   }
>   <% } %>
> 
>   sub recInsertSql
>   {
>     # return sql for a basic insert
>   }
>   # also do a select, update, and delete...
> 
>   1;
> 
> Does this make sense?  Then you can just substitute out the particular
> psp template that generates the recod objects in the way you like it to.
> 
> The templates will be infinitly easier to create and maintain than the
> current borked generator design.
> 
> Comments?

ah ha.  and now we come full circle to why i installed pas in the 1st 
place: to see about generating php record objects and to poke it where 
it hurts.  :0)  given that pseudo code, i'll hafta try it out.

sorry i didn't comment more, but we're putting a bid on yet another 
house and my PERL5LIB is acting up.  :-(

peace,

doug

Re: [Pas-dev] Error.pm and Log::Dispatch/Log::Dispatch::Config

[Mental <me...@ne...>]

On Fri, 2002-05-17 at 11:43, Kyle R . Burton wrote:

> Does this make sense?  Then you can just substitute out the particular
> psp template that generates the recod objects in the way you like it to.
> 
> The templates will be infinitly easier to create and maintain than the
> current borked generator design.
> 

+2. Dont worry if someone else doesnt like it. I like it enough for both
of us. :)


-- 
Mental (Me...@Ne...)

Re: [Pas-dev] css (security)

[Kyle R . B. <mo...@vo...>]

> > And it doesnt need to be angle brackets we worry about. We can look for
> > /\<\s*script/ whatever... this is why I'm asking. :)
> > 
> > An optional 'block the skript kiddies' filter might be nice. 

Ok, step 1 should be for you to write up your idea for the filter system
and this first filter implementaiton and put it in the docs directory
for now.  Maybe create a proposals subdirectory?  We'll keep discussing
the ideas and tweaking them on the mailing list, but putting them down
into a document will make them real.


k

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

Re: [Pas-dev] css (security)

[Kyle R . B. <mo...@vo...>]

> Yes, but what if you never plan on using that? :)

True. True.

> It absolutely should be configurable. Just like the include file
> datecheck stuff. 

Great.

> And it doesnt need to be angle brackets we worry about. We can look for
> /\<\s*script/ whatever... this is why I'm asking. :)
> 
> An optional 'block the skript kiddies' filter might be nice. 

Ah, I wasn't thinking that way.  Give the hampster a minute to get
the wheel craked all the way up.

> Correct. Again, we could have several choices. And hopefully some user
> contributed filters as well. 

That would rock.

> I'm afraid you're off on the angle bracket thing. That was only one of
> my half baked ideas. The other was deterministicly looking for 
> <SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>
> The angle bracket thing was my over simplified method for dealing with
> them. 

I like this.  That would be a nice filter to have.  This would be an
inbound filter for query data correct?  I am liking this more and more...

> If developers _want_ to pass these along, then in my mind thats no
> different than complaining something isnt suid. If you want to disable
> the safety, fine. But dont complain to me when you shoot yourself in the
> foot. Thats all.

Ok, we do it as an optional input filter with the default behavior being
set to on.  If they turn it off, that's their descision.

> Ok, so a plugin you can optionally turn off that looks for the tags
> mentioned in the cert advisory
> (http://www.cert.org/advisories/CA-2000-02.html) then?

+1


You konw if we have this feature, it'll set our product apart from
most of the other web development systems out there...


Thanks for the idea Jason!

Kyle

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

Re: [Pas-dev] css (security)

[Mental <me...@ne...>]

On Fri, 2002-05-17 at 11:48, Kyle R . Burton wrote:

> I'm aware of this kind of attack.  Are there no possible instances where
> someone using Pas would actualy use angle brackets?  What about if/when
> we start handling XML?  XML-RPC/SOAP?

Yes, but what if you never plan on using that? :)

It absolutely should be configurable. Just like the include file
datecheck stuff. 

And it doesnt need to be angle brackets we worry about. We can look for
/\<\s*script/ whatever... this is why I'm asking. :)

An optional 'block the skript kiddies' filter might be nice. 



> If we institute a blanket solution we're bound to break something.
>

Correct. Again, we could have several choices. And hopefully some user
contributed filters as well. 

 
> How about we make it either a filter module, or configurable behavior?
> 

Yes. 

> How can we determinsiticly say what/where data is allowed to have angle
> brackets?  I'm not sure I can see how we can always do the right thing.
> I'm afraid we'll do the wrong thing often enough to make using Pas 
> unpleasant.
> 

I'm afraid you're off on the angle bracket thing. That was only one of
my half baked ideas. The other was deterministicly looking for 
<SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>
The angle bracket thing was my over simplified method for dealing with
them. 

If developers _want_ to pass these along, then in my mind thats no
different than complaining something isnt suid. If you want to disable
the safety, fine. But dont complain to me when you shoot yourself in the
foot. Thats all.



> I think I like the idea of either making it a plug-in or a run-time 
> configuration option.  It should be documeted in the manuals somewhere...
> 

Ok, so a plugin you can optionally turn off that looks for the tags
mentioned in the cert advisory
(http://www.cert.org/advisories/CA-2000-02.html) then?


-- 
Mental (Me...@Ne...)

Re: [Pas-dev] another proposal Test::Unit::TestCase

[Justin B. <ju...@le...>]

all good ideas.  i just can't count that high to tell you what my plus total is.  ;)

justin

Kyle R . Burton wrote:
> Test::Unit::TestCase is the Perl equivalent of JUnit.  I've used it at
> my current employer and would like to institute it's use in Pas.  Again,
> it's not Java (I have also used the C++ version), it's just a good unit
> testing framework.
> 
> You write your test cases like this:
> 
>   package ObjectTest; # tests Object
>   use strict;
>   use warnings;
>   use Test::Unit::TestCase;
>   use Test::Unit::Assertion::Boolean;
>   our @ISA = qw( Test::Unit::TestCase );
> 
>   sub test_construction
>   { 
>     my($self) = @_;
>     my $obj = Object->new();
>     $self->assert( $obj, "Error, construction failed" );
>   }
> 
> Then you run it with a simple test runner -- I usualy write one that
> finds all .pm files that end in *Test.pm and create a test suite,
> then runs them all in a single suite -- that way it's one command to
> run the entire set of unit tests.
> 
> 
> I would _really_ like to institute this.  It makes writing unit tests
> stupid simple.  The easier that is, the more likely it is that we'll
> have unit tests to begin with.
> 
> 
> Votes?  +1/-1?
> 
> My vote is of course +1

[Pas-dev] another proposal Test::Unit::TestCase

[Kyle R . B. <mo...@vo...>]

Test::Unit::TestCase is the Perl equivalent of JUnit.  I've used it at
my current employer and would like to institute it's use in Pas.  Again,
it's not Java (I have also used the C++ version), it's just a good unit
testing framework.

You write your test cases like this:

  package ObjectTest; # tests Object
  use strict;
  use warnings;
  use Test::Unit::TestCase;
  use Test::Unit::Assertion::Boolean;
  our @ISA = qw( Test::Unit::TestCase );

  sub test_construction
  { 
    my($self) = @_;
    my $obj = Object->new();
    $self->assert( $obj, "Error, construction failed" );
  }

Then you run it with a simple test runner -- I usualy write one that
finds all .pm files that end in *Test.pm and create a test suite,
then runs them all in a single suite -- that way it's one command to
run the entire set of unit tests.


I would _really_ like to institute this.  It makes writing unit tests
stupid simple.  The easier that is, the more likely it is that we'll
have unit tests to begin with.


Votes?  +1/-1?

My vote is of course +1

k


-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

Re: [Pas-dev] css (security)

[Kyle R . B. <mo...@vo...>]

> What do we think of dropping tags like SCRIPT,et all from the request
> inside the RequestHandler?  Sure, each page should be doing input
> validation, but if we prune off malicious code at the source, we win. It
> could even be configurable.
> 
> It would make things like this impossible on every page (this should be
> one long line):
> 
> http://www.neverlight.com/pas/css.psp?foo=%3Cscript%3Ealert('oops')%3C/script%3E
> 
> Since I never embed javascript, iframe or any html tags really in query
> parameters I was considering a couple different aproaches.
> 
> URL encode all angle brackets. That would make the litteral script print
> in the page when it retrieves the query parameter.
> 
> Look for all the malicious tags in the cert advisory re: css from a year
> or so ago and remove them. That would still let you embed image tags and
> what not (like on a discussion board), but would filter out 'known
> malicious' tags. 

I'm aware of this kind of attack.  Are there no possible instances where
someone using Pas would actualy use angle brackets?  What about if/when
we start handling XML?  XML-RPC/SOAP?

We could have the default error handlers do the html entity encoding on
form data so errors don't by default cause these issues.  But transparently
changing the input data could make developers who are not expecting that
extremely frustrated. 

If we institute a blanket solution we're bound to break something.

How about we make it either a filter module, or configurable behavior?

How can we determinsiticly say what/where data is allowed to have angle
brackets?  I'm not sure I can see how we can always do the right thing.
I'm afraid we'll do the wrong thing often enough to make using Pas 
unpleasant.

I think I like the idea of either making it a plug-in or a run-time 
configuration option.  It should be documeted in the manuals somewhere...


Kyle

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------