php-windows Digest 18 Aug 2002 14:57:08 -0000 Issue 1295

Topics (messages 15332 through 15334):

Re: Problem passing variables with PHP 4.2
        15332 by: Rasmus Lerdorf

Re: XSLT - Problem passing variables with PHP 4.2 => Solved !
        15333 by: Ignatius Reilly

Re: Getting Field Names in Microsoft SQL
        15334 by: David Hollister

Administrivia:

To subscribe to the digest, e-mail:
        [EMAIL PROTECTED]

To unsubscribe from the digest, e-mail:
        [EMAIL PROTECTED]

To post to the list, e-mail:
        [EMAIL PROTECTED]


----------------------------------------------------------------------
--- Begin Message ---
Turn on register_globals in your php.ini file

On Sat, 17 Aug 2002, Ignatius Reilly wrote:

> Hi,
>
> Since upgrading from PHP 4.0 to 4.2, I do not manage any longer to pass parameters 
>from the PHP script. The XSLT transformations is performed allright, though, but use 
>empty string values for the parameters defined in the script.
>
> I tried to kludge by passing parameters in the form of string arguments:
> $xslt_args["lang"] = "<a>French</a>" ;
> and  <xsl:param name="lang" select="document('arg:/lang0')/a"/>
> ... but here again I get a 'arg:/lang' not found error
>
> I use Apache 1.3.14 on a W2K machine
>
> Anybody has encountered the same problem?
>
> Ignatius
>

--- End Message ---
--- Begin Message ---
Bonjour,

Thanks Sebastian, you put me in the right direction.

I turns out that the newest XSLT API will NOT pass the parameters array when 
xslt_process() uses URIs for the XML source and the XSL sheet, like it used to with 
the previous versions "xslt_run()". One must use arguments for the XML and XSL content.

In other words:
$xslt_args = array( '/_xml' => $xml, '/_xsl' => $xsl ) ;
$result = xslt_process( $xh, 'arg:/_xml', 'arg:/_xsl', NULL, $xslt_args, $xslt_params 
) ==> good


$xslt_args = array() ;
$result = xslt_process( $xh, 'xml_content.xml', 'xsl_sheet.xsl', NULL, $xslt_args, 
$xslt_params ) ==> bad
    (the transformation works correctly, but parameters are not passed)

Fortunately it did not prove necessary to turn register_globals ON.

Ignatius Reilly


--------------------------------------------------------------------------------

  ----- Original Message ----- 
  From: Ignatius Reilly 
  To: [EMAIL PROTECTED] 
  Sent: Saturday, August 17, 2002 6:10 PM
  Subject: Re: [Sab] Problem passing variables with PHP 4.2


  Thanks Mattes,

  That's in fact what I am doing. My script is conform to the documentation. However, 
my <xsl:value-of select="{$VAR_NAME}" /> fills empty string values for the variable.

  The really strange thing here is that it used to work with PHP 4.0, but not any more.

  Could it be a variable scoping problem? Anything to do with register_globals = off 
(in php.ini) ?

  I am really puzzled


------------------------------------------------------------------------------

    ----- Original Message ----- 
    From: Matthes 
    To: [EMAIL PROTECTED] 
    Sent: Saturday, August 17, 2002 7:35 PM
    Subject: Re: [Sab] Problem passing variables with PHP 4.2


    You can call your vars simply by defining <xsl:param name="lang" /> at
    the top of your script (after xsl headers but before templates
    definitions - see php online documentation, there's some comment
    about this) and then access them in your xsl script by calling them
    like <xsl:value-of select="{$VAR_NAME}" /> or so.

    try this:
    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
    <xsl:output method="html" indent="yes"/>
    <xsl:param name="lang" />

    ...

    <xsl:value-of select="$lang" />

    ...

    it should work ;)

    Matthes


    IR> Hi,

    IR> Since upgrading from PHP 4.0 to 4.2, I do not manage any longer to pass 
parameters from the PHP script. The XSLT transformations is performed allright, 
though, and use empty values for the
    IR> parameters defined.

    IR> I tried to kludge by passing parameters in the form of string arguments:
    IR> $xslt_args["lang"] = "<a>French</a>" ;
    IR> and  <xsl:param name="lang" select="document('arg:/lang0')/a"/>
    IR> ... but here again I get a 'arg:/lang' not found error

    IR> I use Apache 1.3.14 on a W2K machine

    IR> Anybody has encountered the same problem?
     
    IR> Ignatius
    IR> ------------------------------------------------------------------------

    IR> Archives and info: http://www.gingerall.org/charlie/ga/xml/m_ml.xml

    IR> Mailing list maintained by Ginger Alliance

    ------------------------------------------------------------------------

    Archives and info: http://www.gingerall.org/charlie/ga/xml/m_ml.xml

    Mailing list maintained by Ginger Alliance


--- End Message ---
--- Begin Message ---
The "select * from [tablename]" approach for MS SQL may be problematic if
you have very large tables even if you only return one row.  You don't have
an accessible index for "select *".  It also gives you no information about
table data types.  That's why I suggested using a "select [name] from
syscolumns where id = [your_table_id]".  If you are using MS SQL, you've
already made a platform choice (or had it jammed down your throat), and I
don't believe that one select statement determines portability.  It all
depends on your requirements.  

Dave

-----Original Message-----
From: Brad Thomas [mailto:[EMAIL PROTECTED]] 
Sent: Friday, August 16, 2002 9:35 PM
To: [EMAIL PROTECTED]
Subject: [PHP-WIN] Re: Getting Field Names in Microsoft SQL

"R.S. Herhuth" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
> I'm trying to build a dynamic script that basically extracts all of the
> fields in a MS SQL database...I just can't seem to figure out how to get
> at the field names themselves.  I am using the mssql_fetch_array
> followed by the $row['field_name'] in an array.  But I would like to
> make the field_name dynamic (i.e. not knowing the field_names ahead of
> time) which would make the script adaptable to any table in the
> database.  So if I get the field's value by $row['field_name'] how do I
> get at the field's name?
>
> thanks,
> Ron


--- End Message ---

Reply via email to