php-general Digest 27 Oct 2010 21:10:30 -0000 Issue 7009
Topics (messages 309103 through 309122):
Re: Documentation
309103 by: Tommy Pham
309104 by: Nicholas Kell
309105 by: Teto
309106 by: Gary
Array problem
309107 by: Don Wieland
309108 by: Nicholas Kell
309109 by: Richard Quadling
309110 by: Nicholas Kell
309111 by: Marc Guay
309112 by: Steve Staples
309113 by: Nicholas Kell
Application settings, configuration, and preferences.
309114 by: mmestnik.nagios.com
309115 by: Ken Guest
309116 by: Bob McConnell
309117 by: Michael Shadle
309118 by: J Ravi Menon
309122 by: J Ravi Menon
Forcing Download - IE Issue
309119 by: Floyd Resler
309120 by: Bastien Koert
Re: Character encoding hell
309121 by: Marc Guay
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
> -----Original Message-----
> From: Jordan Jovanov [mailto:jovanovj...@gmail.com]
> Sent: Wednesday, October 27, 2010 1:53 AM
> To: php-gene...@lists.php.net
> Subject: [PHP] Documentation
>
> Hello All,
>
> I finished with coding and now I am on the part when need to write
> documentation. But I don't know how to write correct documentation.
> Does have some rules or standard for writing documentation for PHP?
> Or maybe have some programs for writing documentations?
>
> Best Regards,
> Jordan JOVANOV
>
Jordan,
I believe the standard is still phpdoc.org. If you're on Windows and use
phpDesigner, it has a nice built-in phpDocumentor to cover your basic
documentation. I don't know about other IDEs.
Regards,
Tommy
--- End Message ---
--- Begin Message ---
On Oct 27, 2010, at 4:09 AM, Tommy Pham wrote:
>> -----Original Message-----
>> From: Jordan Jovanov [mailto:jovanovj...@gmail.com]
>> Sent: Wednesday, October 27, 2010 1:53 AM
>> To: php-gene...@lists.php.net
>> Subject: [PHP] Documentation
>>
>> Hello All,
>>
>> I finished with coding and now I am on the part when need to write
>> documentation. But I don't know how to write correct documentation.
>> Does have some rules or standard for writing documentation for PHP?
>> Or maybe have some programs for writing documentations?
>>
>> Best Regards,
>> Jordan JOVANOV
>>
>
> Jordan,
>
> I believe the standard is still phpdoc.org. If you're on Windows and use
> phpDesigner, it has a nice built-in phpDocumentor to cover your basic
> documentation. I don't know about other IDEs.
>
> Regards,
> Tommy
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
As for IDE's I have used Netbeans. It autocompletes some of the function
headers for you as soon as you enter /** and hit enter, when directly above a
function, method or class. The things that it will autocomplete for you are:
params with names, and an @return if a return statement is present.
After I use NB for putting in headers I usually use phpdoc as mentioned. Aptana
has PHPDoc built into it.
--- End Message ---
--- Begin Message ---
On Wed, Oct 27, 2010 at 2:20 PM, Nicholas Kell <n...@monkeyknight.com>wrote:
>
> On Oct 27, 2010, at 4:09 AM, Tommy Pham wrote:
>
> >> -----Original Message-----
> >> From: Jordan Jovanov [mailto:jovanovj...@gmail.com]
> >> Sent: Wednesday, October 27, 2010 1:53 AM
> >> To: php-gene...@lists.php.net
> >> Subject: [PHP] Documentation
> >>
> >> Hello All,
> >>
> >> I finished with coding and now I am on the part when need to write
> >> documentation. But I don't know how to write correct documentation.
> >> Does have some rules or standard for writing documentation for PHP?
> >> Or maybe have some programs for writing documentations?
> >>
> >> Best Regards,
> >> Jordan JOVANOV
> >>
> >
> > Jordan,
> >
> > I believe the standard is still phpdoc.org. If you're on Windows and
> use
> > phpDesigner, it has a nice built-in phpDocumentor to cover your basic
> > documentation. I don't know about other IDEs.
> >
> > Regards,
> > Tommy
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
> As for IDE's I have used Netbeans. It autocompletes some of the function
> headers for you as soon as you enter /** and hit enter, when directly above
> a function, method or class. The things that it will autocomplete for you
> are: params with names, and an @return if a return statement is present.
>
> After I use NB for putting in headers I usually use phpdoc as mentioned.
> Aptana has PHPDoc built into it.
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> I use doxygen with eclipse. Eclipse fills automatically some fields like
netbeans. Doxygen is easy to use with the GUI and once you learned to use
it, you can use it for java,C++ etc...
--- End Message ---
--- Begin Message ---
Tommy Pham wrote:
>> -----Original Message-----
>> From: Jordan Jovanov
>> I finished with coding and now I am on the part when need to write
>> documentation.
> I believe the standard is still phpdoc.org.
There is also phpdoc.de
> I don't know about other IDEs.
Some things might be better outside IDEs, and this is one of them -
documentation generation is a project wide event which would be better
done on your CI server (IMO, of course).
--- End Message ---
--- Begin Message ---
Hi. I have question regarding an array:
This is a print of a POST array from a form of mine:
Array
(
[SelVol] => Array
(
[0] => ohonthele...@yahoo.com
[1] => d...@pointmade.net
)
[id_Event] => 10
[sDate] => 10/31/2010
[Note] => FFF
)
I am trying to implode the Sel_Vol and it is not giving me the results
I want.
$BCC = implode(",", $_POST['Sel_Vol']);
I want a comma separated result =
$BCC = "ohonthele...@yahoo.com,d...@pointmade.net";
Little help - pretty please
Don Wieland
--- End Message ---
--- Begin Message ---
On Oct 27, 2010, at 10:53 AM, Don Wieland wrote:
> Hi. I have question regarding an array:
>
> This is a print of a POST array from a form of mine:
>
> Array
> (
> [SelVol] => Array
> (
> [0] => ohonthele...@yahoo.com
> [1] => d...@pointmade.net
> )
>
> [id_Event] => 10
> [sDate] => 10/31/2010
> [Note] => FFF
> )
>
> I am trying to implode the Sel_Vol and it is not giving me the results I want.
>
> $BCC = implode(",", $_POST['Sel_Vol']);
>
> I want a comma separated result =
>
> $BCC = "ohonthele...@yahoo.com,d...@pointmade.net";
>
> Little help - pretty please
>
> Don Wieland
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
I am not sure if you have a typo or if your code is actually in error.
Here the key is Sel_Vol
> $BCC = implode(",", $_POST['Sel_Vol']);
Here you are debuging SelVol (Without the underscore)
> [SelVol] => Array
This is my only immediate reaction.
--- End Message ---
--- Begin Message ---
On 27 October 2010 16:53, Don Wieland <d...@dwdataconcepts.com> wrote:
> Hi. I have question regarding an array:
>
> This is a print of a POST array from a form of mine:
>
> Array
> (
> [SelVol] => Array
> (
> [0] => ohonthele...@yahoo.com
> [1] => d...@pointmade.net
> )
>
> [id_Event] => 10
> [sDate] => 10/31/2010
> [Note] => FFF
> )
>
> I am trying to implode the Sel_Vol and it is not giving me the results I
> want.
>
> $BCC = implode(",", $_POST['Sel_Vol']);
>
> I want a comma separated result =
>
> $BCC = "ohonthele...@yahoo.com,d...@pointmade.net";
>
> Little help - pretty please
>
> Don Wieland
[2010/10/27 16:37:28] [Z:\] [\\richardquadling\scratch$ ] >php
<?php
$_POST = Array
(
'SelVol' => Array
(
'ohonthele...@yahoo.com',
'd...@pointmade.net',
),
'id_Event' => 10,
'sDate' => '10/31/2010',
'Note' => 'FFF',
);
echo implode(',', $_POST['SelVol']);
?>
outputs ...
ohonthele...@yahoo.com,d...@pointmade.net
As Nicholas pointed out, the extra underscore in the key is the issue.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
On Oct 27, 2010, at 11:08 AM, Don Wieland wrote:
> DOH - yup! That's it.
>
> Thanks for pointing out my blunder ;-)
>
> Don
>
> On Oct 27, 2010, at 8:57 AM, Nicholas Kell wrote:
>
>> Here you are debuging SelVol (Without the underscore)
>>
>>> [SelVol] => Array
>>
>> This is my only immediate reaction.
>
No problem. It happens to the best of us ;)
--- End Message ---
--- Begin Message ---
> As Nicholas pointed out, the extra underscore in the key is the issue.
That's way too easy a fix. I think he should check to make sure his
version of PHP was compiled with the right extensions and that the
browser isn't doing something unpredictably bizarre when submitting
the form.
Marc
--- End Message ---
--- Begin Message ---
On Wed, 2010-10-27 at 12:14 -0400, Marc Guay wrote:
> > As Nicholas pointed out, the extra underscore in the key is the issue.
>
> That's way too easy a fix. I think he should check to make sure his
> version of PHP was compiled with the right extensions and that the
> browser isn't doing something unpredictably bizarre when submitting
> the form.
>
> Marc
>
maybe you could have overwrote the implode function, and if the
value/array wasn't set, it could then to a str_replace('_', '', $value)
so that it would "self correct" all your underscored mistakes and try
again?
j/k :)
I really hate the ID10T mistakes i make like that... my best one, was
where I used camel casing, and referred to a variable without a capital
in it... took me a while to find it, cuz i was looking right at the
error, echoing out the variable directly above it (writing it properly)
but ignored the mis-typed variable name...
Steve
--- End Message ---
--- Begin Message ---
On Oct 27, 2010, at 11:26 AM, Steve Staples wrote:
> On Wed, 2010-10-27 at 12:14 -0400, Marc Guay wrote:
>>> As Nicholas pointed out, the extra underscore in the key is the issue.
>>
>> That's way too easy a fix. I think he should check to make sure his
>> version of PHP was compiled with the right extensions and that the
>> browser isn't doing something unpredictably bizarre when submitting
>> the form.
>>
>> Marc
>>
> maybe you could have overwrote the implode function, and if the
> value/array wasn't set, it could then to a str_replace('_', '', $value)
> so that it would "self correct" all your underscored mistakes and try
> again?
>
> j/k :)
>
> I really hate the ID10T mistakes i make like that... my best one, was
> where I used camel casing, and referred to a variable without a capital
> in it... took me a while to find it, cuz i was looking right at the
> error, echoing out the variable directly above it (writing it properly)
> but ignored the mis-typed variable name...
>
>
> Steve
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
If I only had a nickel for every time I did something like that..... I could
probably buy a few of ya's lunch!
--- End Message ---
--- Begin Message ---
Recently we had a discussion about weather our code should be configured
using files or a DB back-end. As this topic effects nearly every
development team I was wondering if there shouldn't be a common library
that deals with all of these issues.
We came to the conclusion that either should work, but our project must
work on systems that would not have an SQLDB installed. There fore it
must be configured using files as supporting both would be a waste of
our development time.
Looking around for a solution I came across an extension to getopt that
read command line parameters from a file, essentially emulating "exec
$(cat);". As this did allow configuration from either the command line
or a file it's a good start. However we are specificually looking for
something that would accept configuration from a file or a DB, command
line options are not important. Though a great solution would take
configuration from anywhere.
A full featured solution would also support containing user preferences
and administrative settings. Allowing any of these to come from almost
anywhere. Here is how an example deployment might work. As this would
be a programming tool the user would be an administrator installing and
configuring the software.
Some configuration information contained in php should be extensible so
that all the configuration could be done there. In this case settings
and user preferences would be read-only, configuration information is
always read-only. This would usually specify a config file to be
located in the same folder or a subfolder.
This configuration file would have a default format that is configurable
in the php. Would be one of PHP, XML, bind, apache, and several other
config file formats. This file would contain information on where
settings and preferences could be written to, either another
configuration file some where in /var or connection information for a DB.
>From an application developers stand point this should all be as
difficult as getopt to setup, design decisions like what format the
config file is in should be left up to the admin installing the
software. The developer need only be concerned with defining the values
stored, there type, and other properties.
Does anything like this exist? This seams like an essential piece of
code that is re-invented for every project.
--
Mike Mestnik
Technical Team
___
Nagios Enterprises, INC.
Email: mmest...@nagios.com
Web: www.nagios.com
--- End Message ---
--- Begin Message ---
On Wed, Oct 27, 2010 at 5:27 PM, <mmest...@nagios.com> wrote:
> Recently we had a discussion about weather our code should be configured
> using files or a DB back-end. As this topic effects nearly every
> development team I was wondering if there shouldn't be a common library
> that deals with all of these issues.
>
> We came to the conclusion that either should work, but our project must
> work on systems that would not have an SQLDB installed. There fore it
> must be configured using files as supporting both would be a waste of
> our development time.
>
> Looking around for a solution I came across an extension to getopt that
> read command line parameters from a file, essentially emulating "exec
> $(cat);". As this did allow configuration from either the command line
> or a file it's a good start. However we are specificually looking for
> something that would accept configuration from a file or a DB, command
> line options are not important. Though a great solution would take
> configuration from anywhere.
>
> A full featured solution would also support containing user preferences
> and administrative settings. Allowing any of these to come from almost
> anywhere. Here is how an example deployment might work. As this would
> be a programming tool the user would be an administrator installing and
> configuring the software.
>
> Some configuration information contained in php should be extensible so
> that all the configuration could be done there. In this case settings
> and user preferences would be read-only, configuration information is
> always read-only. This would usually specify a config file to be
> located in the same folder or a subfolder.
>
> This configuration file would have a default format that is configurable
> in the php. Would be one of PHP, XML, bind, apache, and several other
> config file formats. This file would contain information on where
> settings and preferences could be written to, either another
> configuration file some where in /var or connection information for a DB.
>
> From an application developers stand point this should all be as
> difficult as getopt to setup, design decisions like what format the
> config file is in should be left up to the admin installing the
> software. The developer need only be concerned with defining the values
> stored, there type, and other properties.
>
> Does anything like this exist? This seams like an essential piece of
> code that is re-invented for every project.
>
>
PEAR's Config package sounds like a good match for what you are looking for.
It parses and outputs various formats and edits existing config files
http://pear.php.net/package/Config
There's a brief intro to what it can do at
http://pear.php.net/manual/en/package.configuration.config.intro.php
I have to admit I am somewhat biased as I'm currently on the PEAR Group
(read 'committee') - but I'd be surprised if there's not a Zend or
ezComponents/zetaComponents equivalent. I also have to admit there are some
outstanding issues that need to be addressed for PEAR's Config package - the
good news is someone has volunteered to resolve these today.
Good luck,
Ken
> --
> Mike Mestnik
> Technical Team
> ___
> Nagios Enterprises, INC.
> Email: mmest...@nagios.com
> Web: www.nagios.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
http://blogs.linux.ie/kenguest/
--- End Message ---
--- Begin Message ---
From: Ken Guest
> On Wed, Oct 27, 2010 at 5:27 PM, <mmest...@nagios.com> wrote:
>> Recently we had a discussion about weather our code should be
configured
>> using files or a DB back-end. As this topic effects nearly every
>> development team I was wondering if there shouldn't be a common
library
>> that deals with all of these issues.
>>
>> We came to the conclusion that either should work, but our project
must
>> work on systems that would not have an SQLDB installed. There fore
it
>> must be configured using files as supporting both would be a waste of
>> our development time.
>>
>> Looking around for a solution I came across an extension to getopt
that
>> read command line parameters from a file, essentially emulating "exec
>> $(cat);". As this did allow configuration from either the command
line
>> or a file it's a good start. However we are specificually looking
for
>> something that would accept configuration from a file or a DB,
command
>> line options are not important. Though a great solution would take
>> configuration from anywhere.
>>
>> A full featured solution would also support containing user
preferences
>> and administrative settings. Allowing any of these to come from
almost
>> anywhere. Here is how an example deployment might work. As this
would
>> be a programming tool the user would be an administrator installing
and
>> configuring the software.
>>
>> Some configuration information contained in php should be extensible
so
>> that all the configuration could be done there. In this case
settings
>> and user preferences would be read-only, configuration information is
>> always read-only. This would usually specify a config file to be
>> located in the same folder or a subfolder.
>>
>> This configuration file would have a default format that is
configurable
>> in the php. Would be one of PHP, XML, bind, apache, and several
other
>> config file formats. This file would contain information on where
>> settings and preferences could be written to, either another
>> configuration file some where in /var or connection information for a
DB.
>>
>> From an application developers stand point this should all be as
>> difficult as getopt to setup, design decisions like what format the
>> config file is in should be left up to the admin installing the
>> software. The developer need only be concerned with defining the
values
>> stored, there type, and other properties.
>>
>> Does anything like this exist? This seams like an essential piece of
>> code that is re-invented for every project.
>>
>
> PEAR's Config package sounds like a good match for what you are
looking for.
> It parses and outputs various formats and edits existing config files
>
> http://pear.php.net/package/Config
>
> There's a brief intro to what it can do at
> http://pear.php.net/manual/en/package.configuration.config.intro.php
>
> I have to admit I am somewhat biased as I'm currently on the PEAR
Group
> (read 'committee') - but I'd be surprised if there's not a Zend or
> ezComponents/zetaComponents equivalent. I also have to admit there are
some
> outstanding issues that need to be addressed for PEAR's Config package
- the
> good news is someone has volunteered to resolve these today.
There are nearly as many ways to do this as there are languages to
implement them in. I have been using YAML files for a while now, not
only for configuration and parameter storage, but also input for data
driven testing, for both unit and functional tests. Other teams here are
using JSON strings, which will actually become a proper subset of YAML
when the parsers catch up with the latest specification.
More info at <http://yaml.org/>.
Bob McConnell
--- End Message ---
--- Begin Message ---
I find json to be the most ideal data exchange format but using it for
configuration files one may edit by hand is horrible. XML, ini or yaml would be
better. I still prefer XML. Albeit verbose it is the easiest to read and easy
to validate against.
On Oct 27, 2010, at 10:12 AM, "Bob McConnell" <r...@cbord.com> wrote:
> From: Ken Guest
>
>> On Wed, Oct 27, 2010 at 5:27 PM, <mmest...@nagios.com> wrote:
>>> Recently we had a discussion about weather our code should be
> configured
>>> using files or a DB back-end. As this topic effects nearly every
>>> development team I was wondering if there shouldn't be a common
> library
>>> that deals with all of these issues.
>>>
>>> We came to the conclusion that either should work, but our project
> must
>>> work on systems that would not have an SQLDB installed. There fore
> it
>>> must be configured using files as supporting both would be a waste of
>>> our development time.
>>>
>>> Looking around for a solution I came across an extension to getopt
> that
>>> read command line parameters from a file, essentially emulating "exec
>>> $(cat);". As this did allow configuration from either the command
> line
>>> or a file it's a good start. However we are specificually looking
> for
>>> something that would accept configuration from a file or a DB,
> command
>>> line options are not important. Though a great solution would take
>>> configuration from anywhere.
>>>
>>> A full featured solution would also support containing user
> preferences
>>> and administrative settings. Allowing any of these to come from
> almost
>>> anywhere. Here is how an example deployment might work. As this
> would
>>> be a programming tool the user would be an administrator installing
> and
>>> configuring the software.
>>>
>>> Some configuration information contained in php should be extensible
> so
>>> that all the configuration could be done there. In this case
> settings
>>> and user preferences would be read-only, configuration information is
>>> always read-only. This would usually specify a config file to be
>>> located in the same folder or a subfolder.
>>>
>>> This configuration file would have a default format that is
> configurable
>>> in the php. Would be one of PHP, XML, bind, apache, and several
> other
>>> config file formats. This file would contain information on where
>>> settings and preferences could be written to, either another
>>> configuration file some where in /var or connection information for a
> DB.
>>>
>>> From an application developers stand point this should all be as
>>> difficult as getopt to setup, design decisions like what format the
>>> config file is in should be left up to the admin installing the
>>> software. The developer need only be concerned with defining the
> values
>>> stored, there type, and other properties.
>>>
>>> Does anything like this exist? This seams like an essential piece of
>>> code that is re-invented for every project.
>>>
>>
>> PEAR's Config package sounds like a good match for what you are
> looking for.
>> It parses and outputs various formats and edits existing config files
>>
>> http://pear.php.net/package/Config
>>
>> There's a brief intro to what it can do at
>> http://pear.php.net/manual/en/package.configuration.config.intro.php
>>
>> I have to admit I am somewhat biased as I'm currently on the PEAR
> Group
>> (read 'committee') - but I'd be surprised if there's not a Zend or
>> ezComponents/zetaComponents equivalent. I also have to admit there are
> some
>> outstanding issues that need to be addressed for PEAR's Config package
> - the
>> good news is someone has volunteered to resolve these today.
>
> There are nearly as many ways to do this as there are languages to
> implement them in. I have been using YAML files for a while now, not
> only for configuration and parameter storage, but also input for data
> driven testing, for both unit and functional tests. Other teams here are
> using JSON strings, which will actually become a proper subset of YAML
> when the parsers catch up with the latest specification.
>
> More info at <http://yaml.org/>.
>
> Bob McConnell
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
I am partial to the filesystem but I can see scenarios where the db
approach might be useful (single point of control) with good caching
strategy using apc or other mechanisms.
One approach I have followed is that if the config. field and values
are simple key-value pairs, you could store them in a dedicated conf
file and have it included in the main apache conf file (Include
directive). This way, all the configs are accessible via $_SERVER. The
separate conf file can be checked in svn, pushed separately as part of
release process etc... The same approach also works in standalone php
cli scripts via a shell wrapper - e.g.:
#!/bin/bash
.
# list fields directly here or load them separately - e.g:
# . /path/to/some_file.conf
export FIELD1="foo"
export FIELD2 ="bar"
# Note: values can have some structure too
export FIELD3="abc,cde,fgh"
.
.
/usr/bin/php some_script.php
You could also use the php ini style confs:
http://php.net/manual/en/function.parse-ini-file.php
In the $_SERVER approach above, the parsing is done at start-up, so
there is no setup cost at every request. For the ini or xml parsing
approach, you may need to cache the result if this parsing cost needs
to be avoided on every request.
Ravi
On Wed, Oct 27, 2010 at 10:17 AM, Michael Shadle <mike...@gmail.com> wrote:
> I find json to be the most ideal data exchange format but using it for
> configuration files one may edit by hand is horrible. XML, ini or yaml would
> be better. I still prefer XML. Albeit verbose it is the easiest to read and
> easy to validate against.
>
> On Oct 27, 2010, at 10:12 AM, "Bob McConnell" <r...@cbord.com> wrote:
>
>> From: Ken Guest
>>
>>> On Wed, Oct 27, 2010 at 5:27 PM, <mmest...@nagios.com> wrote:
>>>> Recently we had a discussion about weather our code should be
>> configured
>>>> using files or a DB back-end. As this topic effects nearly every
>>>> development team I was wondering if there shouldn't be a common
>> library
>>>> that deals with all of these issues.
>>>>
>>>> We came to the conclusion that either should work, but our project
>> must
>>>> work on systems that would not have an SQLDB installed. There fore
>> it
>>>> must be configured using files as supporting both would be a waste of
>>>> our development time.
>>>>
>>>> Looking around for a solution I came across an extension to getopt
>> that
>>>> read command line parameters from a file, essentially emulating "exec
>>>> $(cat);". As this did allow configuration from either the command
>> line
>>>> or a file it's a good start. However we are specificually looking
>> for
>>>> something that would accept configuration from a file or a DB,
>> command
>>>> line options are not important. Though a great solution would take
>>>> configuration from anywhere.
>>>>
>>>> A full featured solution would also support containing user
>> preferences
>>>> and administrative settings. Allowing any of these to come from
>> almost
>>>> anywhere. Here is how an example deployment might work. As this
>> would
>>>> be a programming tool the user would be an administrator installing
>> and
>>>> configuring the software.
>>>>
>>>> Some configuration information contained in php should be extensible
>> so
>>>> that all the configuration could be done there. In this case
>> settings
>>>> and user preferences would be read-only, configuration information is
>>>> always read-only. This would usually specify a config file to be
>>>> located in the same folder or a subfolder.
>>>>
>>>> This configuration file would have a default format that is
>> configurable
>>>> in the php. Would be one of PHP, XML, bind, apache, and several
>> other
>>>> config file formats. This file would contain information on where
>>>> settings and preferences could be written to, either another
>>>> configuration file some where in /var or connection information for a
>> DB.
>>>>
>>>> From an application developers stand point this should all be as
>>>> difficult as getopt to setup, design decisions like what format the
>>>> config file is in should be left up to the admin installing the
>>>> software. The developer need only be concerned with defining the
>> values
>>>> stored, there type, and other properties.
>>>>
>>>> Does anything like this exist? This seams like an essential piece of
>>>> code that is re-invented for every project.
>>>>
>>>
>>> PEAR's Config package sounds like a good match for what you are
>> looking for.
>>> It parses and outputs various formats and edits existing config files
>>>
>>> http://pear.php.net/package/Config
>>>
>>> There's a brief intro to what it can do at
>>> http://pear.php.net/manual/en/package.configuration.config.intro.php
>>>
>>> I have to admit I am somewhat biased as I'm currently on the PEAR
>> Group
>>> (read 'committee') - but I'd be surprised if there's not a Zend or
>>> ezComponents/zetaComponents equivalent. I also have to admit there are
>> some
>>> outstanding issues that need to be addressed for PEAR's Config package
>> - the
>>> good news is someone has volunteered to resolve these today.
>>
>> There are nearly as many ways to do this as there are languages to
>> implement them in. I have been using YAML files for a while now, not
>> only for configuration and parameter storage, but also input for data
>> driven testing, for both unit and functional tests. Other teams here are
>> using JSON strings, which will actually become a proper subset of YAML
>> when the parsers catch up with the latest specification.
>>
>> More info at <http://yaml.org/>.
>>
>> Bob McConnell
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
On Wed, Oct 27, 2010 at 11:39 AM, J Ravi Menon <jravime...@gmail.com> wrote:
> I am partial to the filesystem but I can see scenarios where the db
> approach might be useful (single point of control) with good caching
> strategy using apc or other mechanisms.
>
> One approach I have followed is that if the config. field and values
> are simple key-value pairs, you could store them in a dedicated conf
> file and have it included in the main apache conf file (Include
> directive). This way, all the configs are accessible via $_SERVER. The
> separate conf file can be checked in svn, pushed separately as part of
> release process etc... The same approach also works in standalone php
> cli scripts via a shell wrapper - e.g.:
>
> #!/bin/bash
> .
> # list fields directly here or load them separately - e.g:
> # . /path/to/some_file.conf
> export FIELD1="foo"
> export FIELD2 ="bar"
>
> # Note: values can have some structure too
> export FIELD3="abc,cde,fgh"
> .
> .
> /usr/bin/php some_script.php
>
> You could also use the php ini style confs:
>
> http://php.net/manual/en/function.parse-ini-file.php
>
> In the $_SERVER approach above, the parsing is done at start-up, so
> there is no setup cost at every request. For the ini or xml parsing
> approach, you may need to cache the result if this parsing cost needs
> to be avoided on every request.
>
> Ravi
>
>
>
> On Wed, Oct 27, 2010 at 10:17 AM, Michael Shadle <mike...@gmail.com> wrote:
>> I find json to be the most ideal data exchange format but using it for
>> configuration files one may edit by hand is horrible. XML, ini or yaml would
>> be better. I still prefer XML. Albeit verbose it is the easiest to read and
>> easy to validate against.
>>
>> On Oct 27, 2010, at 10:12 AM, "Bob McConnell" <r...@cbord.com> wrote:
>>
>>> From: Ken Guest
>>>
>>>> On Wed, Oct 27, 2010 at 5:27 PM, <mmest...@nagios.com> wrote:
>>>>> Recently we had a discussion about weather our code should be
>>> configured
>>>>> using files or a DB back-end. As this topic effects nearly every
>>>>> development team I was wondering if there shouldn't be a common
>>> library
>>>>> that deals with all of these issues.
>>>>>
>>>>> We came to the conclusion that either should work, but our project
>>> must
>>>>> work on systems that would not have an SQLDB installed. There fore
>>> it
>>>>> must be configured using files as supporting both would be a waste of
>>>>> our development time.
>>>>>
>>>>> Looking around for a solution I came across an extension to getopt
>>> that
>>>>> read command line parameters from a file, essentially emulating "exec
>>>>> $(cat);". As this did allow configuration from either the command
>>> line
>>>>> or a file it's a good start. However we are specificually looking
>>> for
>>>>> something that would accept configuration from a file or a DB,
>>> command
>>>>> line options are not important. Though a great solution would take
>>>>> configuration from anywhere.
>>>>>
>>>>> A full featured solution would also support containing user
>>> preferences
>>>>> and administrative settings. Allowing any of these to come from
>>> almost
>>>>> anywhere. Here is how an example deployment might work. As this
>>> would
>>>>> be a programming tool the user would be an administrator installing
>>> and
>>>>> configuring the software.
>>>>>
>>>>> Some configuration information contained in php should be extensible
>>> so
>>>>> that all the configuration could be done there. In this case
>>> settings
>>>>> and user preferences would be read-only, configuration information is
>>>>> always read-only. This would usually specify a config file to be
>>>>> located in the same folder or a subfolder.
>>>>>
>>>>> This configuration file would have a default format that is
>>> configurable
>>>>> in the php. Would be one of PHP, XML, bind, apache, and several
>>> other
>>>>> config file formats. This file would contain information on where
>>>>> settings and preferences could be written to, either another
>>>>> configuration file some where in /var or connection information for a
>>> DB.
>>>>>
>>>>> From an application developers stand point this should all be as
>>>>> difficult as getopt to setup, design decisions like what format the
>>>>> config file is in should be left up to the admin installing the
>>>>> software. The developer need only be concerned with defining the
>>> values
>>>>> stored, there type, and other properties.
>>>>>
>>>>> Does anything like this exist? This seams like an essential piece of
>>>>> code that is re-invented for every project.
>>>>>
>>>>
>>>> PEAR's Config package sounds like a good match for what you are
>>> looking for.
>>>> It parses and outputs various formats and edits existing config files
>>>>
>>>> http://pear.php.net/package/Config
>>>>
>>>> There's a brief intro to what it can do at
>>>> http://pear.php.net/manual/en/package.configuration.config.intro.php
>>>>
>>>> I have to admit I am somewhat biased as I'm currently on the PEAR
>>> Group
>>>> (read 'committee') - but I'd be surprised if there's not a Zend or
>>>> ezComponents/zetaComponents equivalent. I also have to admit there are
>>> some
>>>> outstanding issues that need to be addressed for PEAR's Config package
>>> - the
>>>> good news is someone has volunteered to resolve these today.
>>>
>>> There are nearly as many ways to do this as there are languages to
>>> implement them in. I have been using YAML files for a while now, not
>>> only for configuration and parameter storage, but also input for data
>>> driven testing, for both unit and functional tests. Other teams here are
>>> using JSON strings, which will actually become a proper subset of YAML
>>> when the parsers catch up with the latest specification.
>>>
>>> More info at <http://yaml.org/>.
>>>
>>> Bob McConnell
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
Whoops I forgot the rule on bottom--posting! So used to top-posting
elsewhere, it is 2nd nature now. I am re-adding my earlier response
below and missed to mention one more item:
> I am partial to the filesystem but I can see scenarios where the db
> approach might be useful (single point of control) with good caching
> strategy using apc or other mechanisms.
>
> One approach I have followed is that if the config. field and values
> are simple key-value pairs, you could store them in a dedicated conf
> file and have it included in the main apache conf file (Include
> directive). This way, all the configs are accessible via $_SERVER. The
> separate conf file can be checked in svn, pushed separately as part of
> release process etc... The same approach also works in standalone php
> cli scripts via a shell wrapper - e.g.:
>
> #!/bin/bash
> .
> # list fields directly here or load them separately - e.g:
> # . /path/to/some_file.conf
> export FIELD1="foo"
> export FIELD2 ="bar"
>
> # Note: values can have some structure too
> export FIELD3="abc,cde,fgh"
> .
> .
> /usr/bin/php some_script.php
>
> You could also use the php ini style confs:
>
> http://php.net/manual/en/function.parse-ini-file.php
>
> In the $_SERVER approach above, the parsing is done at start-up, so
> there is no setup cost at every request. For the ini or xml parsing
> approach, you may need to cache the result if this parsing cost needs
> to be avoided on every request.
>
> Ravi
Forgot to mention that in the apache case above, you would use the
'SetEnv' directive to define the key-value pairs in some conf file -
e.g.
SetEnv FIELD1 "foo"
SetEnv FIELD2 "bar"
SetEnv FIELD3 "abc,cde,fgh"
.
.
.
Ravi
--- End Message ---
--- Begin Message ---
I'm trying to force a download using the following code:
header('Content-type: text/calendar');
header('Content-Disposition: attachment; filename="calendar.ics"');
echo $calendar;
It works great in all browsers except IE. In IE, the window opens and then
closes without ever display the download save window. I'm not sure why it
isn't working in IE.
Thanks!
Floyd
--- End Message ---
--- Begin Message ---
On Wed, Oct 27, 2010 at 4:18 PM, Floyd Resler <fres...@adex-intl.com> wrote:
> I'm trying to force a download using the following code:
> header('Content-type: text/calendar');
> header('Content-Disposition: attachment; filename="calendar.ics"');
> echo $calendar;
>
> It works great in all browsers except IE. In IE, the window opens and then
> closes without ever display the download save window. I'm not sure why it
> isn't working in IE.
>
> Thanks!
> Floyd
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Have a look at the headers page in the manual
http://php.net/manual/en/function.header.php
There are a number of examples that talk about downloading for IE (it
blows as doing that)
--
Bastien
Cat, the other other white meat
--- End Message ---
--- Begin Message ---
> Have you tried using the utf8 meta tag rather than using the htmlentities()
> function? That should solve the first issue, as I reckon the problem lies
> with the way your encoding the filename.
It seems that the filenames are ISO encoded as if I set the meta tag
to ISO and remove the htmlentities() wrapper it displays the character
fine. Not sure how that helps or if this is even PHP related anymore
but thought I'd follow up.
--- End Message ---
