Re: [PEAR] Starting with MDB

At 30/04/2003 20.02 -0300, you wrote:
 >Hi.
 >
 > I need a tutorial to start using MDB.
 >
 > The info in www.backendmedia.com/MDB/docs seems too "techie" to start 
from... 

Look at the bottom-left frame: there's a link to a tutorial and to a 
PHP-Mag article,
plus other interesting reads, such as the datatypes and the xml schema 
explanations.
Regards,
Lorenzo

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Date Package

Hi, I'm just wondering what the procedure is for submitting 'tweaks' that
I think are reasonable to at least be considered for the Date package.

I have modified the Date_calc class to be able to handle the run-time allocation
of the first-day-of-the-week rather than it being hard-coded in a constant.

I also found the Date::compare method woefully inefficient because it always
converts the timezones of the dates before comparing them. This was taking
some hundreds of milli-seconds for each compare operation so you can imagine
what happened if even one compare call was made in a loop. I added a boolean
switch to optionally (and in my case default) turn off the timezone comparison.
 The computation time dropped so that it was not registering in the milliseconds.

I also have some other minor things but they can be discussed down the track.

Regards,
Andrew Eddie
Senior Systems Integrator
Toowoomba City Council, Australia

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Date Package

eddieajau <at> iprimus.com.au wrote:

>Hi, I'm just wondering what the procedure is for submitting 'tweaks' that
>I think are reasonable to at least be considered for the Date package.
>  
>
http://pear.php.net/manual/en/developers.supporting.php

Regards,

Jeroen

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Date Package

> From: Jeroen Houben [mailto:jeroen <at> terena.nl]
> Sent: Thursday, May 01, 2003 10:20 AM

> eddieajau <at> iprimus.com.au wrote:
> 
> >Hi, I'm just wondering what the procedure is for submitting 'tweaks'
that
> >I think are reasonable to at least be considered for the Date
package.
> >
> >
> http://pear.php.net/manual/en/developers.supporting.php

well the thing is the authors don't seem to react to any emails.
So I think we can consider this package orphaned. What do others think?

Date handling is very complicated and nasty. So we need to make sure a
new maintainer really knows his stuff in regards to Date handling
(Pierre luckily stopped me from proposing some stupid changes).

To: Baba and Monte .. if you read this please let us know what you
think, want etc ...

Regards,
Lukas

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

MDB docs update

Hi,

I have updated the API docs of MDB at www.backendmedia.com/MDB/docs.

Btw: anyone interested in helping me port the PEAR DB docbook
documentation please let me know.

Regards,
Lukas Smith
smith <at> backendmedia.com 
_______________________________ 
  BackendMedia 
  www.backendmedia.com 
  berlin <at> backendmedia.com 

  Linn Zwoch Smith GbR 
  Pariser Str. 44 
  D-10707 Berlin 

  Tel +49 30 83 22 50 00 
  Fax +49 30 83 22 50 07

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: PEAR Midgard wrapup

On Wed Apr 30, 2003 at 10:2147PM +1200, Martin Langhoff wrote:
> It was suggested that Midgard belongs to PECL, but that seems to be 
> targetted for C modules. I have not been able to find the PECL 
> guidelines either, so I am not sure if this is accurate. 

That's right. PECL is for PHP extensions written in C. Putting Midgard
there is nonsense.

> Of course, we can serve our packages from our servers -- we don't even 
> need a repository as the pear tools will take a valid URL, get the 
> package, and install it. However, this negates many advantages, 
> including dependance resolution, publicity (just by being alongside in 
> the same repository), search functionality, etc.

IMO using a own server is *the* way to go for projects like Horde,
Midgard et al. Actually this prevents us from running into trouble with
redundant packages: I suspect that both Horde and Midgard do have their
own Template or Authentation classes. Adding them to PEAR will be no
good, as our focus is to reduce redundant packages to a minimum. Having
those classes on a your own server instead seems to be no problem.

I'm pretty sure that we can find a decent way to add links to prominent
places (like http://pear.php.net/packages.php) pointing to other "PEAR
servers" like pear.horde.org or migard-project.org.

Concering dependencies: Dependencies towards PEAR packages can also be
resolved, when one installs (Midgard|Horde) packages from another
server.

--

-- 

Re: PEAR::Date_Timezone

On Wed Apr 30, 2003 at 11:4431PM +0200, Lukas Smith wrote:
> I therefore propose the following additions to add the following line to
> setDefault():
>     function setDefault($id)
>     {
>         global $default;
>         if(Date_TimeZone::isValidID($id)) {
> +           if(!getenv('TZ')) putenv('TZ='.$id);

This isn't compatible to the coding standards, but I guess you know this
:).

> since we maintainers if this package seem to be less than active I don't
> know how to handle this aside from doing a little vote on pear-dev. Then
> again I can wait until after the pear-meeting on a commit.

If the maintainers don't reply to your mails in a reasonable timeframe
(~ 1 week), I guess you can go ahead and apply the changes. But
nevertheless, such issues should be discussed individually in the future.

-- 
    - Martin                           Martin Jansen
                            http://martinjansen.com/

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Sequences for DB:MySQL

Hi there,

I have just noticed an inconsistency between MySQL and PostgreSQL DB 
objects when you are creating sequences.

When you call createSequence() with MySQL it set's the value to 1,
so when you make your first call with nextId() a 2 is returned.

When you call createSequence() with Postgre and then call nextId() a 1
is returned, which is what I would expect.

I can't test what the other databases do, but by looking at nextId() fn 
in the other DB classes that are using tables to emulate sequences (ie 
mssql, fbsql and odbc) createSequence() appears to initialise the value 
to zero because these fns repeat in the do..while loop after creating 
the sequence.

I have attached a patch to the DB/mysql.php that fixes this issue in 
createSequence() and alters nextId() to perform the same repeat that the 
other classes do - please tell me what you think.

BTW - if you are wondering why I need to call createSequence() rather 
than just using the on demand feature of nextId() it has to do with 
Postgre, transactions and a failed NEXTVAL() call - see the points 
raised in this bug report, http://bugs.php.net/bug.php?id=22761

cheers

BCR

Re: [PEAR-DOC] Feature Request: deeper TOC for pear.php.net manual

Alexander Merz wrote:
> Greg Beaver wrote:
> 
>>> It would no problem to write, but this is the best way to confuse users.
>>
>> I don't follow you.  As a user, I would automatically search for a 
>> number manipulation package under "Math."  I would look for a number 
>> text manipulation package under "Text."  I would never think to look 
>> for a template engine under "HTML," that is completely illogical.  
>> Template 
> 
> This is not a doc problem - the peardoc categories follows the 
> categories of the package browser.
> 
> I think you has two problems of understanding:
> 1.) rendering vs logical structure, as proposed in an early mail, we can 
> provide a toc with a simple package overview

Thank you, this would be very helpful

> 2.) the categories are given by the pear community - if a Template 
> category would exists, it will exists in the manual too.

Well, I would like to ask the pear community at large then.

In the interest of attracting more users, I'd like to propose a 
re-organization of all template classes into a new Template category. 
This would be the first place people looking for a template will look, 
they may not continue to browse to html.  For backwards compatibility, 

XML_Tree bug fix

Hi there,

I sent this
     http://marc.theaimsgroup.com/?l=pear-dev&m=104872687731346&w=2
to the list a while ago but I think people probably got put off looking
into it because of the length of the message, so I'll try for an
abbreviated version.

Basically there are two aims for this patch on the current
CVS version :
1. $node->content *always* returns the unescaped contents
2. $node->get() returns attributes that are have double quotes escaped.

Point 1 basically involves moving the call to _xml_entities() - which
escapes the contents of the node - from the setContent() fn to the get() fn.

While point 2 involves adding a simple str_replace in get()

Thoughts ?

BCR

--- ./new/XML/Tree/Node.php.cvs	Fri May  2 10:29:47 2003
+++ ./new/XML/Tree/Node.php	Fri May  2 10:33:36 2003
 <at>  <at>  -67,7 +67,7  <at>  <at> 
     function XML_Tree_Node($name, $content = '', $attributes = array()) {
         $this->attributes = $attributes;
         $this->children   = array();
-        $this->set_content($content);