NEOHAPSIS - Peace of Mind Through Integrity and Insight

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com

Neohapsis > Archives > PHP Discussion Digest> 2000-03

Subject: php3 Digest 21 Mar 2000 19:25:21 -0000 Issue 1552
From: php3-digest-helplists.php.net
Date: Tue Mar 21 2000 - 13:25:21 CST

Next message: php3-digest-helplists.php.net: "php3 Digest 22 Mar 2000 06:00:00 -0000 Issue 1553"
Previous message: php3-digest-helplists.php.net: "php3 Digest 21 Mar 2000 18:25:21 -0000 Issue 1551"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

php3 Digest 21 Mar 2000 19:25:21 -0000 Issue 1552

Topics (messages 82054 through 82102):

Please help???
82054 by: "sufi malak" <sufi_mhotmail.com>
82092 by: Unnikrishnan <unnikrishnangocubs.com>

[PHP Template] Re: [PHP3] Re: [PHP Template] Re:[PHP3] PHP Template Engine spec revision 0.52
        82055 by: Monte Ohrt <monteispi.net>
        82064 by: Andi Gutmans <andizend.com>
        82089 by: Monte Ohrt <monteispi.net>
        82098 by: Zeev Suraski <zeevzend.com>

querying info in a drop down using php
82056 by: php-info <php-infosoldusa.com>
82081 by: Unnikrishnan <unnikrishnangocubs.com>

msie caching variable data?!?
82057 by: Jason Morehead <jmoreheadalphalincoln.com>

file handling problem; urgent.
82058 by: "Rajarshi Sadhukha" <rajcnpl.co.in>
82079 by: Unnikrishnan <unnikrishnangocubs.com>

[PHP Template] Re: [PHP3] PHP Template Engine spec revision 0.52
        82059 by: Andrei Zmievski <andreiispi.net>
        82062 by: Auke van Slooten <aukemuze.nl>
        82063 by: Cliff Rowley <dozpromptonsea.com>
        82069 by: Zeev Suraski <zeevzend.com>
        82075 by: Zeev Suraski <zeevzend.com>
        82078 by: Andrei Zmievski <andreiispi.net>
        82080 by: Andrei Zmievski <andreiispi.net>
        82084 by: Zeev Suraski <zeevzend.com>
        82086 by: Zeev Suraski <zeevzend.com>
        82094 by: Andrei Zmievski <andreiispi.net>
        82096 by: Zeev Suraski <zeevzend.com>
        82101 by: Zeev Suraski <zeevzend.com>
        82102 by: John Coggeshall <cogg1256kettering.edu>

Is printing HTML code bad?
        82060 by: Chris Moewes-Bystrom <christophermoewes.com>
        82071 by: Chris Moewes-Bystrom <christophermoewes.com>
        82082 by: "Jason Stechschulte" <jpstechnc.edu>

Dynamic loading in Apache 1.3.6
82061 by: "Benoit Grigaut , WCN" <benoitwcn.co.uk>

denying method="get" variables?
82065 by: Rasmus Lerdorf <rasmusphp.net>

phplib local.inc errors. Gurus needed
82066 by: "Marc Swanson" <marcswansonmediaone.net>
82068 by: John Coggeshall <cogg1256kettering.edu>

**** Help with PHPGem (Parent/Child table display/edits) ??? ****
82067 by: Sue Collins <sue_collins71yahoo.com>

PHP Template Engine spec revision0.52
82070 by: Andrei Zmievski <andreiispi.net>

SQL Server 7 from Linux
82072 by: Mark Nold <marknalverstone.com.au>

times() function
82073 by: David Diaz i Torrico <ddiazdrac.com>

Appears in View Source
82074 by: "Andrew Sheh (DME)" <andrewdmetechnologies.com>

Problems with Ora_bind() [urgent]
82076 by: Guilhem Esteve <gesteveinfo-ufr.univ-montp2.fr>

removing duplicate entries from an array
82077 by: Keith Vance <keithvbzln.com>
82083 by: David Nagel <nagelursu.uregina.ca>

NON-PHP: text and background color of digest
82085 by: Chris Toth <toth.22osu.edu>

Is this working?
82087 by: "Jesper Hess Nielsen" <jespergraffen.dk>

Help me?...
82088 by: "Yul-ho, Seong$¼º¿È£$" <yhseonginouttech.co.kr>

[CGI] formatting text question:PERL
82090 by: Arjen Bax <arjen.baxcmg.nl>

Remote ODBC
82091 by: "Andrew Hill" <ahillopenlinksw.com>

Selecting "String" from Pull-Down menus
82093 by: "Andrew Sheh" <asheadmetechnologies.com>

jump.altavista.com using PHP
82095 by: "Stephen Cope" <kimihiamaxnet.co.nz>

Counting hits in and out
82097 by: "Stephen Cope" <kimihiamaxnet.co.nz>

Qmail and mail()
82099 by: Chris Shenton <cshentonuucom.com>

magic_quotes_runtime not supported by ISP?
82100 by: "Jason Brackins" <jasonbrackinserols.com>

Administrivia:

To subscribe to the digest, e-mail:
php3-digest-subscribelists.php.net

To unsubscribe from the digest, e-mail:
php3-digest-unsubscribelists.php.net

To post to the list, e-mail:
php3lists.php.net

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

attached mail follows:

I have a table like this :
----------------------------------
| City | DEMOGRAPHY | F1 | F2 | F3 |

What I am looking for is:
if I am in the page that show the city Boston, I needd to colect
the results (F1, F2, F3) in arrays of two cities above Boston and
two below Boston ( by comparing demography), so with Boston included
it will be five arrays.
Thanks
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

attached mail follows:

Pure programatic way, I am not sure is there a PHP feature to do this. If anybody know, please let me know.

You can do this using two ways. The first option is to do a select and move the result into an array.

Then perform an search for the city to find the index. From there move index two backwards and forward and you get all your five rows.

Other option is using simple program logic like the
firstrec=secondrec=1strec=2ndrec=''
j=0;
cityfound=false;

for(i=0;i<numofrecs;i++){
if(city==cityvalue){
  cityfound=true;
  cityrec=currentrec;
} elseif (cityfound==true and j < 2){
   temprec=2ndrec;
   2ndrec=currentrec;
   1strec=temprec;
} else {
   temprec=secondrec;
   secondrec=currentrec;
   firstrec=temprec;
}
if(j==2) break;
}

On Tue, 21 March 2000, "sufi malak" wrote:

>
> I have a table like this :
> ----------------------------------
> | City | DEMOGRAPHY | F1 | F2 | F3 |
>
> What I am looking for is:
> if I am in the page that show the city Boston, I needd to colect
> the results (F1, F2, F3) in arrays of two cities above Boston and
> two below Boston ( by comparing demography), so with Boston included
> it will be five arrays.
> Thanks
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
>
>
> --
> PHP 3 Mailing List <http://www.php.net/>
> To unsubscribe, send an empty message to php3-unsubscribelists.php.net
> To subscribe to the digest, e-mail: php3-digest-subscribelists.php.net
> To search the mailing list archive, go to: http://www.php.net/mailsearch.php3
> To contact the list administrators, e-mail: php-list-adminlists.php.net

http://www.unni.com
If there is a WILL there is a WAY
______________________________________________________________
Go Cubs Email - The Official Email Service of the Chicago Cubs
Get your free Go Cubs Email account http://www.cubs.com

attached mail follows:

Hi Andi,

Andi Gutmans wrote:
>
> Then just teach them the PHP "if" and "include" commands :) What is the
> use of rewriting these commands for templates?
>
> Andi

We discussed this, its too messy and terse for your average designer to
easily comprehend. We have found that keeping all logic constructs in
curly braces {} makes the templates much more readable and
understandable to the designer. Our coders and designers are NOT the
same people, thus the demand for templates! The designers are very
visually oriented people, so the templates must resemble the final
output as closely as possible. This doesn't work with PHP style syntax.

Maybe I can do this with an example.

Template using the PHP template engine:

<HTML>
  <HEAD>
    <TITLE>{$PageTitle}</TITLE>
  </HEAD>
  <BODY>
    <TABLE border=0>

       {if $TableHead ne ""}
          <TR>
            <TD colspan=3>{$TableHead}</TD>
          </TR>
       {/if}

       {section}
          <TR>
             <TD>{Name}</TD>
             <TD>{Address}</TD>
             <TD>{Phone}</TD>
          </TR>
       {/section}

</TABLE>
</BODY>
</HTML>

No how do you propose the template would look using PHP?

Monte

attached mail follows:

On Mon, 20 Mar 2000, Monte Ohrt wrote:

> Hello,
>
> Hopefully I'll be able to clarify some important things to know about this
> template engine. You can't just take a glance at the spec and say "it's too
> complex", there is a lot of time-consuming thought and input from everyone that
> derived the way it is designed.
>
> The engine specifications are designed around the top priority being
> ease-of-use, followed by flexibility. The template engine IS easy to use, yet
> harnesses the power designers will want once they get comfortable with it. We
> wanted to keep the syntax as close to HTML as possible (since the majority of
> designers are comfortable with this), yet retain the ability to handle basic
> template logic controls.
>
> Andrei and I come from a background where we interact with the designers on a
> daily basis. We've tried all sorts of template solutions out there and quite
> frankly, none of them cut it. We need to separate form from content, yet give
> the designers the flexibility they need to design! Far too often the designers
> have one hand tied behind their back because of the limitations the templates
> give them. They can't just come tap us on the shoulder every time they have an
> idea. Through our experience, the majority of what designers need can be covered
> with "includes", basic "if" logic and section looping. This opens a whole new
> perspective of options for them without having to learn all the little
> idiosyncrasies of the PHP language, not to mention they don't break our code!

Then just teach them the PHP "if" and "include" commands :) What is the
use of rewriting these commands for templates?

Andi

attached mail follows:

Hi Zeev,

I think we're all going a bit overboard on the whole "two separate
languages" argument. Templates allow form to be separated from content.
The PHP scripts and the templates are really two separate beasts, you're
comparing apples to oranges. Look at FastTemplate for example, the
syntax does not resemble PHP code whatsoever. That is because it is a
template, not a PHP script. Whoever said that designers don't want
anything more complicated than Dreamweaver... right on. The templates
engine, at its most rudimentary form, closely resembles the resulting
html pages. If the designer needs a bit more control over the template,
that is what the logic controls are there for. Calling this a "second
language" makes it sound like template logic is a vast complexity like
PHP itself, when in fact it is nowhere near that. It is merely a small
subset of logic to give designers the flexibility they need, with a
syntax that is easy to comprehend (in comparison to PHP) by the non
programmer.

I think we need to provide template examples. Just looking at the spec
makes it seem much more complicated than it really is.

Monte

Zeev Suraski wrote:
>
> On Tue, 21 Mar 2000, Cliff Rowley wrote:
>
> > As far as saying "PHP already does what we need..." is not an
> > argument. Adding a template engine bears no effect on those who choose
> > not to use it.
>
> But it does! Imagine that the template engine goes live, in say, two
> months. After a month, or two months, or half a year - sooner or later -
> people will start using it. They may be 0.1% of the PHP users, they may
> be 20% of the PHP users. They will write code based on this whole new
> language. Some of them will release some of that code in the various code
> exchanges. And wham - someone that until now was quite capable of
> understanding PHP scripts that he downloaded, will now bump into something
> that doesn't even reminds him of PHP, but for some odd reason, is also
> considered PHP code. Time to look for the spec to figure out what it's
> all about.
>
> In my opinion, that's bad. It has nothing to do with the language Andrei
> suggested. He may argue that it's better, I may argue that it's not. It
> doesn't matter. The point is that PHP should not feature two
> completely different syntaxes to do the same thing. It's bad for the
> users.
>
> Zeev
>

attached mail follows:

You can't write ANY sort of logic in FastTemplates. Thus, you can't
replace PHP code with FastTemplates code. This does not apply for the
template spec Andrei sent out earlier today.

On Tue, 21 Mar 2000, Monte Ohrt wrote:

> Hi Zeev,
>
> I think we're all going a bit overboard on the whole "two separate
> languages" argument. Templates allow form to be separated from content.
> The PHP scripts and the templates are really two separate beasts, you're
> comparing apples to oranges. Look at FastTemplate for example, the
> syntax does not resemble PHP code whatsoever. That is because it is a
> template, not a PHP script. Whoever said that designers don't want
> anything more complicated than Dreamweaver... right on. The templates
> engine, at its most rudimentary form, closely resembles the resulting
> html pages. If the designer needs a bit more control over the template,
> that is what the logic controls are there for. Calling this a "second
> language" makes it sound like template logic is a vast complexity like
> PHP itself, when in fact it is nowhere near that. It is merely a small
> subset of logic to give designers the flexibility they need, with a
> syntax that is easy to comprehend (in comparison to PHP) by the non
> programmer.
>
> I think we need to provide template examples. Just looking at the spec
> makes it seem much more complicated than it really is.
>
> Monte
>
> Zeev Suraski wrote:
> >
> > On Tue, 21 Mar 2000, Cliff Rowley wrote:
> >
> > > As far as saying "PHP already does what we need..." is not an
> > > argument. Adding a template engine bears no effect on those who choose
> > > not to use it.
> >
> > But it does! Imagine that the template engine goes live, in say, two
> > months. After a month, or two months, or half a year - sooner or later -
> > people will start using it. They may be 0.1% of the PHP users, they may
> > be 20% of the PHP users. They will write code based on this whole new
> > language. Some of them will release some of that code in the various code
> > exchanges. And wham - someone that until now was quite capable of
> > understanding PHP scripts that he downloaded, will now bump into something
> > that doesn't even reminds him of PHP, but for some odd reason, is also
> > considered PHP code. Time to look for the spec to figure out what it's
> > all about.
> >
> > In my opinion, that's bad. It has nothing to do with the language Andrei
> > suggested. He may argue that it's better, I may argue that it's not. It
> > doesn't matter. The point is that PHP should not feature two
> > completely different syntaxes to do the same thing. It's bad for the
> > users.
> >
> > Zeev
> >
>

-- 
Zeev Suraski <zeevzend.com>
http://www.zend.com/

attached mail follows:

hello I am trying to pull info from a table from oracle using php3. here is the code. I get no errors but no data either.

how can I get the echo statement to populate the drop down menu?

thanks for any help

brad

attached mail follows:

Include a line after echo "<OPTION value="$type">"; as echo $type;

it will work.

On Tue, 21 March 2000, php-info wrote:

> > hello > I am trying to pull info from a table from oracle using > php3. here is the code. I get no errors but no data either. > > <select name="f_credcard" size =1 > > <?php > $link = ocilogon("php","php","dev1"); > $stmt = ociparse($link,"select type from cc_type"); > ociexecute($stmt,OCI_DEFAULT); > echo "<OPTION value="$type">"; > ?> > </select> > > how can I get the echo statement to populate the drop down menu? > > thanks for any help > > brad > > -- > PHP 3 Mailing List <http://www.php.net/> > To unsubscribe, send an empty message to php3-unsubscribelists.php.net > To subscribe to the digest, e-mail: php3-digest-subscribelists.php.net > To search the mailing list archive, go to: http://www.php.net/mailsearch.php3 > To contact the list administrators, e-mail: php-list-adminlists.php.net

http://www.unni.com If there is a WILL there is a WAY ______________________________________________________________ Go Cubs Email - The Official Email Service of the Chicago Cubs Get your free Go Cubs Email account http://www.cubs.com

attached mail follows:

hi all...

my co-workers and i are running into a problem with MSIE caching variable data. we've created several sites that have admin sections where the site's owners can go in and update various parts of the site via a php frontend and a mysql database. but the problem is that MSIE doesn't always reflect the changes that have been made to the database.

for example, one of the sites has a membership directory. if i want to delete a member, i go into the admin section and do a search for the member i want to delete. the query brings up a list of members that meet the criteria, and i can then delete the member i want. that works perfectly. however, in MSIE, if i go back, it will still list the member(s) that i've deleted. this doesn't happen in any of the other browsers i use.

has anyone else come across this, or know of a solution? i looked through the archives, but didn't find anything.

any ideas or suggestions would be appreciated.

jason

-- http://www.alphalincoln.com/ alphagraphics of nebraska - web services 201 n 14th - lincoln, ne 68508 - 402.475.0000

attached mail follows:

hi! everybody,

i am having problems while handling large files, i am handling 3 files in my script all in read mode. all files are system files. my program seems to work fine with small files of 10-20 records. but when the no. of records goes beyond 150, it gives inconsistent result. i would be thankfull if someone can help me.

raj.

attached mail follows:

What kind of problems you are facing? like errors or reaching end of files?

On Mon, 20 March 2000, "Rajarshi Sadhukha" wrote:

> > hi! > everybody, > > i am having problems while handling large files, i am handling 3 files > in my script all in read mode. > all files are system files. > my program seems to work fine with small files of 10-20 records. but > when the no. of records goes > beyond 150, it gives inconsistent result. > i would be thankfull if someone can help me. > > raj. > > > > -- > PHP 3 Mailing List <http://www.php.net/> > To unsubscribe, send an empty message to php3-unsubscribelists.php.net > To subscribe to the digest, e-mail: php3-digest-subscribelists.php.net > To search the mailing list archive, go to: http://www.php.net/mailsearch.php3 > To contact the list administrators, e-mail: php-list-adminlists.php.net

http://www.unni.com If there is a WILL there is a WAY ______________________________________________________________ Go Cubs Email - The Official Email Service of the Chicago Cubs Get your free Go Cubs Email account http://www.cubs.com

attached mail follows:

On Tue, 21 Mar 2000, Zeev Suraski wrote: > I'll try to say why I think it's actually very bad for PHP to have a > powerful template engine, and why it's not harmless.

Ghm.

> The way I see it, if the templates engine actually gets implemented > successfully, then people would see it as an integral part of the > language. Now, some would think it's better to use, and some won't. The > thing is, you would now have two very very different ways to implement > your logic.

I and many others view it as a strength, not a weakness.

> Writing a certain script would be possible to do in two *completely* > different languages, but both are considered PHP. The two versions of the > script will have NOTHING to do with each other, and a person understanding > one version of the script (say, the PHP-code version) will not understand > the other (template) version. Suddenly, someone who knows PHP will no > longer be able to understand a large (or rather, unknown) portion of the > PHP code that will be out there. A book that doesn't cover templates will > no longer be enough, since without being aware of the complex template > syntax, which is essentially a language in its own right, you won't be > able to understand many of the scripts out there. That is why I think > that every single person on this mailing list, or at least most of them, > would be affected by such a template implementation, and thus, I think the > discussion belongs here rather than a cut-down 'for template > professionals' mailing list.

Firstly, if you can make predictions for the future, then you should be playing on the stock market. :) Secondly, I disagree with your opinion that the same application written in PHP and in PHP+templates will have _nothing_ to do with each other. If the application is written properly, then they will have a lot in common. Thirdly, you seem to be afraid that people who already know PHP will be loathe to learn something new that will empower them. Do not underestimate people's desire for learning.

I have to stress once again that, perhaps, a wide range of developers will not even have a need for a template engine. They can happily go on developing the way they've been doing it now. But then there are those of us who have work day in and day out with the designers. We tried writing applications with HTML embedded PHP code. Our designers screamed and said they'll never touch something like that again. PHP, while a greatly generalized language, is not a good choice for templates because of its C/Java/Perl legacy and other issues. That's why we want a template language and, yes, it has its own syntax and rules.

> I think that in the way the spec is laid out right now, templates are > truly a language inside a language, and regardless of their specific > syntax, it's always bad to have two completely different syntaxes to do > the same thing, *especially* if you're staying in the scope of the same > language (I think we would be one of the first examples for this, and it's > not a very good thing!).

Yes, they are a language inside a language. But if you remember from the Developers' meeting, we did not want to touch PHP's parser in order to accomodate some features of the template engine (like sections, for example). That's why I decided to write an implementation using its own syntax that's more geared for layout stuff.

> As opposed to this, a trivial (in the literal sense) template > implementation, which would literally have no learning curve, much like > the template engine of phplib or the other ones available, does not impose > that danger. It's really just a different way to lay out presentation, > and it requires no learning of a new syntax, plus it doesn't give you the > ability to write your logic using a completely different syntax.

Here is an example for this template engine:

template -------- <HTML> <HEAD> <TITLE>{$title}</TITLE> </HEAD>

PHP script ---------- $id = tmpl_load("template.tpl"); tmpl_assign($id, array("title" => "My Page", "bgcolor" => "#458830")); print tmpl_fetch($id);

That is as simple as it gets. This is exactly what FastTemplate and phplib's template system do. What's wrong with this?

> Is it powerful enough? I would say it is, knowing the underlying engine > between some very big and complex web sites, the zend.com web site > included.

That may be. For our company, it wasn't powerful enough. I suppose others may agree with me.

> If your designers love the ability to write conditionals in their > templates, which essentially means they're coding, they should truly learn > the PHP syntax. Introducing a whole new syntax inside PHP just because > your designers don't like PHP's syntax is a bad thing, regardless of > whether that syntax goes directly to the scripting engine (which as you > said, we don't want to change) or to a slightly higher level position.

It's not a matter of just learning PHP syntax. It means that we would have to pollute PHP's namespace with template variables and all that if we want to do something like:

<? if ($TPLVARS["baskettotal"] > 10): ?>

as oppposed to

{ if $baskettotal > 10 }

That's just one example.

I'm glad people are coming out of the woods now and letting their opinions be known. I wish they did it sooner. Perhaps, some of the language syntax is getting to be not so obvious, but it's tough to balance ease-of-use and flexibility for both designers and programmers. I'm trying to do the best that I can under the circumstances and, hopefully, we can all settle on an agreeable solution.

-Andrei

"Claiming Java is easier than C++ is like saying that K2 is shorter than Everest." -- Larry O'Brien (editor, Software Development)

attached mail follows:

On Tue, 21 Mar 2000, Zeev Suraski wrote:

> I'll try to say why I think it's actually very bad for PHP to have a > powerful template engine, and why it's not harmless. > > The way I see it, if the templates engine actually gets implemented > successfully, then people would see it as an integral part of the > language. Now, some would think it's better to use, and some won't. The > thing is, you would now have two very very different ways to implement > your logic. Essentially, two different languages in the same package. >

<snip>

> I would really like to hear from people whether they think I'm just being > 'paranoid' about introducing a complete new syntax set for PHP being a bad > thing. If my thoughts are correct, then this discussion does belong here, > because as I said, in a year's time or so, it'll affect every single PHP > developer out there. > > Zeev >

Hi, I've watched this spec grow with mixed feelings too. I'm developing a rather complex system in PHP. I want people to be able to have a big influence on how parts of this system behave and display, but I don't want them to be able to read my password file, or access the database via generic php functions. So I really need something like a template system, only there were no systems powerfull enough. The solution I've chosen right now is to create a script which rewrites normal php code so that 'dangerous' (not in the list of 'safe' functions) functions are mapped to an object. If the function is available there, it will run, if not, it will fail. It does the same with variables. Now, the current implementation of this translater is not very pretty, and I would like to use something cleaner, but I agree with Zeev that the spec as I've seen it now only serves to let people learn yet another language. If you need this power, it is in my opinion much better to familiarize people with the php way of coding. This way you will have the added bonus of introducing people to PHP programming, instead of <insert template language here>. Still, in my case it would be nice if there was a foolproof way of creating a sort of sandbox in php.

Auke van Slooten http://www.muze.nl/

PS. the translator is available at http://www.muze.nl/software/tools/pinp.html

attached mail follows:

Yup yup, I'm completely with you, good stuff. There have been situations where I have handed over sites to clients who wish to maintain it after I've finished with it. More often than not they've returned to me after realising they've jumped in a little out of their depth. While this is not a bad thing for my wallet, it's not good for my workload. Being able to hand them off to a template engine would be a great asset in this situation.

I would use it myself too, since I build my sites from templates. You know, the whole idea sorta reminds me of sgml in a funny sorta way ;)

As far as saying "PHP already does what we need..." is not an argument. Adding a template engine bears no effect on those who choose not to use it.

Cliff Rowley

- while (!asleep) { code(); }

attached mail follows:

On Tue, 21 Mar 2000, Andrei Zmievski wrote:

> On Tue, 21 Mar 2000, Zeev Suraski wrote: > > If it can be sophisticated, it means that people who want to read it would > > have to be familiar with this spec, thoroughly, even if they're already > > quite fluent in PHP. That's the bad thing. Having the ability to decide > > whether it's simple or complicated is not a plus, it should be simple by > > definition. > > Being fluent in more than one language is not a bad idea, I think. Don't > limit your options.

But requiring a user of PHP to be fluent in more than one language - is. If he wants to learn another language, so be it, but PHP itself should not feature two 'competing' languages.

> 'if' was an easy example. Compare this: > > {section} > Headline: {headline} > {if #LAST} > <hr> > {/if} > {/section} > > with this: > > <? for ($i=0; $i<count($headlines); $i++): ?> > Headline: <? echo $headlines[$i]; ?> > <? if ($i == count($headlines)-1): ?> > <hr> > <? endif; ?> > <? endfor; ?> > > No contest for me.

Well, no contest for me either. Undoubtfully, the different syntax does not call for adding a whole new language on top of the existing language. You're essentially saying that you don't like PHP's syntax - it's your, or your designers' right, obviously. But if they don't like it, they shouldn't use it; We shouldn't add a new syntax to PHP to make them happy. The JSP/VB example applies here.

Zeev

-- 
Zeev Suraski <zeevzend.com>
http://www.zend.com/

attached mail follows:

On Tue, 21 Mar 2000, Cliff Rowley wrote:

> As far as saying "PHP already does what we need..." is not an > argument. Adding a template engine bears no effect on those who choose > not to use it.

But it does! Imagine that the template engine goes live, in say, two months. After a month, or two months, or half a year - sooner or later - people will start using it. They may be 0.1% of the PHP users, they may be 20% of the PHP users. They will write code based on this whole new language. Some of them will release some of that code in the various code exchanges. And wham - someone that until now was quite capable of understanding PHP scripts that he downloaded, will now bump into something that doesn't even reminds him of PHP, but for some odd reason, is also considered PHP code. Time to look for the spec to figure out what it's all about.

In my opinion, that's bad. It has nothing to do with the language Andrei suggested. He may argue that it's better, I may argue that it's not. It doesn't matter. The point is that PHP should not feature two completely different syntaxes to do the same thing. It's bad for the users.

Zeev

-- 
Zeev Suraski <zeevzend.com>
http://www.zend.com/

attached mail follows:

On Tue, 21 Mar 2000, Zeev Suraski wrote: > Either you didn't understand me, or that's a very big 'if'. Your template > syntax lets people take foo.php, which is full of logic, and convert it > almost as a whole to foo.tmpl, with (almost) all of the logic inside the > template. This means that you would have two files, foo.php and foo.tmpl, > that look completely different, are essentially written in two completely > different languages, but do the same thing. You can't say that foo.tmpl > would be easier to develop/maintain, because that's just a matter of > opinion (whether someone thinks that {if} {/if} is more intuitive than > if() { } is very subjective). > > You're introducing a whole new language, with LOTS of power that overlaps > the existing PHP power, only with completely different syntax. That's > bad.

I think it's you who totally misunderstands what I was talking about. I am not saying that foo.php gets converted into foo.tmpl with all the logic inside the template. That's insane! Never once did I mention something like that! The template logic is meant to be used only for some of the layout stuff, nothing more. I don't know where you came up with foo.php -> foo.tmpl idea.

> Please, people do not want to learn new things if they don't have to, > especially if it gives them nothing! The template logic is NOT easier > than PHP logic, it's just different. Enforcing people to study yet > another language is pure overhead, and has no reason at all. Again, this > is in contrast to standard, plain&simple templates, which have a flat > learning curve, and require no programming skills to master.

Exactly, the template logic is different! It has a different purpose.

Oh, and "a flat curve"? That's an oxymoron.

> I would have to see the final 'product', but if it grows up to match that > spec (which would probably get even more complex as time goes by), I for > one, would oppose adding it as a standard to PHP. If I'm the only one > that thinks it's a bad idea, than I guess you can ignore me, but I think > that there would be many others that think that as well. Just because the > designers in your company don't like PHP's syntax and prefer a totally > different syntax to do the same thing, doesn't mean PHP should have a > whole new syntax introduced, something that would cause lots of pain for > lots of people in the future.

Why do you twist my words? No one is introducing a whole new syntax to PHP. Even if I wanted to do that, I still wouldn't be able to due to your de facto ownership of the Zend code.

I also object to your argument that PHP programmers wouldn't understand PHP scripts that use templates. I'm sorry but that's a little ridiculous. You can apply the same argument to PHP scripts that use XML or classes or regular expressions. What if someone doesn't know OOP or regular expressions? Maybe we should make life easy for them as well, eh?

You seem that think that there should be one or two rigid ways of writing PHP scripts. One of the big advantages of Open Source movement is that it gives you _choice_. What a nice word.

> I'd be all in favour of implementing a fast > plain&simple template engine at the PHP level, after receiving positive > feedback about the need for templates (without logic) from many people, > both in Zend and in ApacheCon.

Funny I received lots of positive feedback on the current spec as well.

> If you recall, the 'should we have > built-in template support in PHP' argument at the PDM ended the second you > said there should be if constructs in there - everyone said 'no way', but > I don't firmly object the concept of templates, despite the fact I > wouldn't use them myself.

So, if you don't use PHP yourself to build things, how can you say that PHP syntax is more applicable for the templates than the template language syntax?

> At the PDM we decided not to add templates at all, and you decided to > pursuit this project yourself, which you have every right to, obviously.

Thanks for acknowledging that, at least.

> But I think the spec got completely carried away, and poses a significant > problem to the uniformity of PHP as a simple and easy to use language. At > any rate I wouldn't want the template engine to be at the language-parser > level, but I wouldn't want to introduce a whole new syntax in whatever > level. Much like I wouldn't want to add a Visual Basic parser on top of > the PHP parser to let people mix VB with PHP, I don't want the template > engine to be powerful enough to replace PHP logic. If it can do it, it > means it's too powerful.

Whoah, hold on. There it goes again. Who ever said that template engine is going to replace PHP logic? It is not a programming language. It's a layout language. Closer to CSS if anything.

I still don't understand why you feel that PHP is threatened by this template engine. Its use is optional. Just because we have XML extension or PCRE extension doesn't mean that you are obligated to use it.

> Nothing, but that's a trivial template, that you can do with the other > template engines available (which is fine by me). In your spec, you have > loops, if constructs, and whatnot. This is wrong, since it can be done > using equivalent PHP logic.

It may be a trivial template, but that's exactly what you propose having as PHP's template system. Obviously, the template engine can do this, but also other things, if you choose to take advantage of that.

> It needs to be mixed with PHP logic. The only reason for not doing this > is that your designers seem to prefer another logic syntax over PHP's > logic syntax, which in my opinion, is not a valid reason. If they were > used to VB, or JSP templates, you would write new VB/JSP parsers that > would let them mix code from different languages? That's horrible IMHO, > because it would mean that every PHP programmer would have to know these > languages before he can understand PHP scripts he finds on the net (sooner > or later, people would begin using it, and scripts that use it will be > published on the net). The template spec is just another language, just > like VB/JSP (except it's a whole new language on its own, and not a > duplicate of an existing language).

How many times do I have to say it? It's not a programming language. It's nothing like VB/JSP. Enough of this FUD.

> I think that in this case, it's a great example of why you shouldn't > implement all this logic in the template level. You would also have > { if #baskettotal > 10 } > and > { if %baskettotal > 10 } > and God knows what else, each would mean something different, and a > possible reader would have to be familiar with the details of this spec in > order to understand it. True, the PHP version is slightly longer since it > requires you to explicitly say you're referencing a template variable (the > rest of the different is just syntax), but the fact that people will not > have to learn a whole new language is definitely worth it.

Ok. Then let's stop adding new extensions to PHP completely, because a possible reader would have to be familiar with Perl-style regular expressions, or sockets, or, God forbid, SQL syntax. The horror.

> Well, today was the first time I actually read through the spec, and I was > quite surprised to see a full-featured language laid out in there, instead > of something that implements something similar to the template engines > I've seen before. If logic, written in PHP can be rewritten in your > template syntax, with completely different syntax, I think the spec lost > it's path somewhere along the way.

The template logic is not meant to replace PHP logic. See above.

If everyone subscribed to your philosophy, Zeev, we'd still be using awk and sed as our scripting languages instead of PHP, Perl, and Python. Three whole new languages. What an idea.

Regards,

-Andrei * Programming is an art form that fights back. *

attached mail follows:

On Tue, 21 Mar 2000, Tom wrote: > I too had been following the growth of the Template Engine specification > but it seemed to be adding layer upon layer of complexity which IMO is > way beyond what any designer I've worked with could ever manage.

See example in my reply to Zeev. Once again, it can be as simple or as sophisticated as you want it to be. Assuming the designers are dumb is, in my opinion, a real faux pas. And then again, it's not like the designers will code up a template from scratch. The programmers will probably set up the skeleton first and then hand it off to the designer.

> My _recent_ experiences with "Design Firms" is that, with the advent of the > sophisticated WYSIWYG platforms, they literally are not even aware that > they are creating Javascript laden pages that break on some browser versions.

True, I think that HTML should be hand-coded.

> IMO the various attempts at developing _templates_ to separate content > management from processing logic have only gotten more complex (for > designers) and my hope was for the opposite. > > But more important to me now is Zeev's argument that "layering" of > another language/syntax to perform the same functions as the base language > is not a good thing. Reflecting on the recent debate from that perspective > sheds new light on some of my queasy feelings about it.

Well, I'll be frank. What Zeev and you are doing here is not constructive criticism. Complaining about the project without offering any alternatives or solutions is akin to armchair quaterbacking.

As for "layering of another language/syntax", I'll refer you again to my reply to Zeev.

> When I read "This revision addresses quite a few issues related to sections > and multi-valued variables." it now has a whole new meaning ;-) > > Thanks Zeev.

Regards,

-Andrei * On the keyboard of life, always keep one finger on the escape key. *

attached mail follows:

On Tue, 21 Mar 2000, Andrei Zmievski wrote:

> On Tue, 21 Mar 2000, Zeev Suraski wrote: > > I'll try to say why I think it's actually very bad for PHP to have a > > powerful template engine, and why it's not harmless. > > Ghm.

Powerful doesn't necessarily mean it's good, if it's just yet another way to do the same thing as another powerful tool.

> > The way I see it, if the templates engine actually gets implemented > > successfully, then people would see it as an integral part of the > > language. Now, some would think it's better to use, and some won't. The > > thing is, you would now have two very very different ways to implement > > your logic. > > I and many others view it as a strength, not a weakness.

Two completely different ways to implement the same thing is a strength? In what sense? Every PHP developer would now have to know two languages that have nothing to do with each other, if he wants to be sure that he'll be able to understand PHP scripts? It's a bad thing in every aspect. If it was powerful in a sense that it was *adding* functionality, not duplicating functionality, it would be a good thing. Providing a totally different way of doing the same thing, in the language-syntax level, is bad.

> Firstly, if you can make predictions for the future, then you should be > playing on the stock market. :)

In the opensource world, if you release something, someone, somewhere, would use it. And from my experience, lots of people use just about everything. So, my prediction about this, and I don't have to be a prophet for that, is that there'll be lots of people that would use the template syntax, and obviously lots of people that would go on using the PHP syntax. A predicion saying that no-one would use the template engine, or alternately, that everyone would use it, is a predicion you would need a prophet for. Saying that both will be used is just common sense.

> Secondly, I disagree with your opinion > that the same application written in PHP and in PHP+templates will have > _nothing_ to do with each other. If the application is written properly, > then they will have a lot in common.

Either you didn't understand me, or that's a very big 'if'. Your template syntax lets people take foo.php, which is full of logic, and convert it almost as a whole to foo.tmpl, with (almost) all of the logic inside the template. This means that you would have two files, foo.php and foo.tmpl, that look completely different, are essentially written in two completely different languages, but do the same thing. You can't say that foo.tmpl would be easier to develop/maintain, because that's just a matter of opinion (whether someone thinks that {if} {/if} is more intuitive than if() { } is very subjective).

You're introducing a whole new language, with LOTS of power that overlaps the existing PHP power, only with completely different syntax. That's bad.

> Thirdly, you seem to be afraid that > people who already know PHP will be loathe to learn something new that > will empower them. Do not underestimate people's desire for learning.

Please, people do not want to learn new things if they don't have to, especially if it gives them nothing! The template logic is NOT easier than PHP logic, it's just different. Enforcing people to study yet another language is pure overhead, and has no reason at all. Again, this is in contrast to standard, plain&simple templates, which have a flat learning curve, and require no programming skills to master. > I have to stress once again that, perhaps, a wide range of developers > will not even have a need for a template engine. They can happily go on > developing the way they've been doing it now. But then there are those > of us who have work day in and day out with the designers. We tried > writing applications with HTML embedded PHP code. Our designers > screamed and said they'll never touch something like that again. PHP, > while a greatly generalized language, is not a good choice for > templates because of its C/Java/Perl legacy and other issues. That's why > we want a template language and, yes, it has its own syntax and rules.

I would have to see the final 'product', but if it grows up to match that spec (which would probably get even more complex as time goes by), I for one, would oppose adding it as a standard to PHP. If I'm the only one that thinks it's a bad idea, than I guess you can ignore me, but I think that there would be many others that think that as well. Just because the designers in your company don't like PHP's syntax and prefer a totally different syntax to do the same thing, doesn't mean PHP should have a whole new syntax introduced, something that would cause lots of pain for lots of people in the future. I'd be all in favour of implementing a fast plain&simple template engine at the PHP level, after receiving positive feedback about the need for templates (without logic) from many people, both in Zend and in ApacheCon. If you recall, the 'should we have built-in template support in PHP' argument at the PDM ended the second you said there should be if constructs in there - everyone said 'no way', but I don't firmly object the concept of templates, despite the fact I wouldn't use them myself.

> > I think that in the way the spec is laid out right now, templates are > > truly a language inside a language, and regardless of their specific > > syntax, it's always bad to have two completely different syntaxes to do > > the same thing, *especially* if you're staying in the scope of the same > > language (I think we would be one of the first examples for this, and it's > > not a very good thing!). > > Yes, they are a language inside a language. But if you remember from the > Developers' meeting, we did not want to touch PHP's parser in order to > accomodate some features of the template engine (like sections, for > example). That's why I decided to write an implementation using its own > syntax that's more geared for layout stuff.

At the PDM we decided not to add templates at all, and you decided to pursuit this project yourself, which you have every right to, obviously. But I think the spec got completely carried away, and poses a significant problem to the uniformity of PHP as a simple and easy to use language. At any rate I wouldn't want the template engine to be at the language-parser level, but I wouldn't want to introduce a whole new syntax in whatever level. Much like I wouldn't want to add a Visual Basic parser on top of the PHP parser to let people mix VB with PHP, I don't want the template engine to be powerful enough to replace PHP logic. If it can do it, it means it's too powerful.

> > As opposed to this, a trivial (in the literal sense) template > > implementation, which would literally have no learning curve, much like > > the template engine of phplib or the other ones available, does not impose > > that danger. It's really just a different way to lay out presentation, > > and it requires no learning of a new syntax, plus it doesn't give you the > > ability to write your logic using a completely different syntax. > > Here is an example for this template engine: > > template > -------- > <HTML> > <HEAD> > <TITLE>{$title}</TITLE> > </HEAD> > > <BODY bgcolor="{$bgcolor}"> > ... > </BODY> > </HTML> > > PHP script > ---------- > $id = tmpl_load("template.tpl"); > tmpl_assign($id, array("title" => "My Page", "bgcolor" => "#458830")); > print tmpl_fetch($id); > > That is as simple as it gets. This is exactly what FastTemplate and > phplib's template system do. What's wrong with this?

Nothing, but that's a trivial template, that you can do with the other template engines available (which is fine by me). In your spec, you have loops, if constructs, and whatnot. This is wrong, since it can be done using equivalent PHP logic.

> > > Is it powerful enough? I would say it is, knowing the underlying engine > > between some very big and complex web sites, the zend.com web site > > included. > > That may be. For our company, it wasn't powerful enough. I suppose > others may agree with me.

It needs to be mixed with PHP logic. The only reason for not doing this is that your designers seem to prefer another logic syntax over PHP's logic syntax, which in my opinion, is not a valid reason. If they were used to VB, or JSP templates, you would write new VB/JSP parsers that would let them mix code from different languages? That's horrible IMHO, because it would mean that every PHP programmer would have to know these languages before he can understand PHP scripts he finds on the net (sooner or later, people would begin using it, and scripts that use it will be published on the net). The template spec is just another language, just like VB/JSP (except it's a whole new language on its own, and not a duplicate of an existing language).

> > If your designers love the ability to write conditionals in their > > templates, which essentially means they're coding, they should truly learn > > the PHP syntax. Introducing a whole new syntax inside PHP just because > > your designers don't like PHP's syntax is a bad thing, regardless of > > whether that syntax goes directly to the scripting engine (which as you > > said, we don't want to change) or to a slightly higher level position. > > It's not a matter of just learning PHP syntax. It means that we would > have to pollute PHP's namespace with template variables and all that if > we want to do something like: > > <? if ($TPLVARS["baskettotal"] > 10): ?> > > as oppposed to > > { if $baskettotal > 10 } > > That's just one example.

I think that in this case, it's a great example of why you shouldn't implement all this logic in the template level. You would also have { if #baskettotal > 10 } and { if %baskettotal > 10 } and God knows what else, each would mean something different, and a possible reader would have to be familiar with the details of this spec in order to understand it. True, the PHP version is slightly longer since it requires you to explicitly say you're referencing a template variable (the rest of the different is just syntax), but the fact that people will not have to learn a whole new language is definitely worth it.

> I'm glad people are coming out of the woods now and letting their > opinions be known. I wish they did it sooner. Perhaps, some of the > language syntax is getting to be not so obvious, but it's tough to > balance ease-of-use and flexibility for both designers and programmers. > I'm trying to do the best that I can under the circumstances and, > hopefully, we can all settle on an agreeable solution.

Well, today was the first time I actually read through the spec, and I was quite surprised to see a full-featured language laid out in there, instead of something that implements something similar to the template engines I've seen before. If logic, written in PHP can be rewritten in your template syntax, with completely different syntax, I think the spec lost it's path somewhere along the way.

Zeev

-- 
Zeev Suraski <zeevzend.com>
http://www.zend.com/

attached mail follows:

On Tue, 21 Mar 2000, Andrei Zmievski wrote:

> > I too had been following the growth of the Template Engine specification > > but it seemed to be adding layer upon layer of complexity which IMO is > > way beyond what any designer I've worked with could ever manage. > > See example in my reply to Zeev. Once again, it can be as simple or as > sophisticated as you want it to be. Assuming the designers are dumb is, > in my opinion, a real faux pas. And then again, it's not like the > designers will code up a template from scratch. The programmers will > probably set up the skeleton first and then hand it off to the designer.

If it can be sophisticated, it means that people who want to read it would have to be familiar with this spec, thoroughly, even if they're already quite fluent in PHP. That's the bad thing. Having the ability to decide whether it's simple or complicated is not a plus, it should be simple by definition.

> > IMO the various attempts at developing _templates_ to separate content > > management from processing logic have only gotten more complex (for > > designers) and my hope was for the opposite. > > > > But more important to me now is Zeev's argument that "layering" of > > another language/syntax to perform the same functions as the base language > > is not a good thing. Reflecting on the recent debate from that perspective > > sheds new light on some of my queasy feelings about it. > > Well, I'll be frank. What Zeev and you are doing here is not > constructive criticism. Complaining about the project without offering > any alternatives or solutions is akin to armchair quaterbacking.

I am providing a solution - you provided it yourself in your example, that compared how to implement the template if in PHP code. Use PHP syntax for logic, use your templates for presentation. I won't suggest using 'for' loops instead of 'while' loops, which you may consider as constructive criticism. I suggest moving logic outside of the templates engine altogether.

Zeev

-- 
Zeev Suraski <zeevzend.com>
http://www.zend.com/

attached mail follows:

On Tue, 21 Mar 2000, Howard Ha wrote: > Though I loved your initial idea for an integrated template system, it has > grown much too cumbersome for my taste, and I agree now more with Zeev's > reasoning than yours.

Umm, I mentioned from the very beginning why template engine needs conditionals, includes, and config variables. It's not like I started out by saying "yes, we'll make it just like FastTemplate" and then piled on the features.

> The point is, I think the BIGGEST benefit from an integrated Template system > in PHP should be purely to streamline the speed of the templates, rather > than enhancing its features to the point of creating a whole new branch of > coding. I say keep the templates as templates, and increase the flexibility > of how those templates are used, but do NOT add too much logic to the > template system. It makes for a weird "sub-PHP" language, IMHO. > > By the way, in defense of current template solutions for PHP, I have seen > many fine examples, and worked on some myself, where ingenuity has overcome > many of the weaknesses in the template systems. The only thing I see > recurring is the issue of speed, so why not have the integrated template > system focus on efficiency rather than complexity?

In some strange way, all this reminds me of the C vs. C++ argument. There too people talk about whole new way of coding, speed, C programmers not knowing what the heck C++ is... But as we've seen there's place for both. The same can be applied here.

-Andrei * The great thing about standards is that there are so many to choose from. *

attached mail follows:

On Tue, 21 Mar 2000, Andrei Zmievski wrote:

> On Tue, 21 Mar 2000, Zeev Suraski wrote: > > Either you didn't understand me, or that's a very big 'if'. Your template > > syntax lets people take foo.php, which is full of logic, and convert it > > almost as a whole to foo.tmpl, with (almost) all of the logic inside the > > template. This means that you would have two files, foo.php and foo.tmpl, > > that look completely different, are essentially written in two completely > > different languages, but do the same thing. You can't say that foo.tmpl > > would be easier to develop/maintain, because that's just a matter of > > opinion (whether someone thinks that {if} {/if} is more intuitive than > > if() { } is very subjective). > > > > You're introducing a whole new language, with LOTS of power that overlaps > > the existing PHP power, only with completely different syntax. That's > > bad. > > I think it's you who totally misunderstands what I was talking about. I > am not saying that foo.php gets converted into foo.tmpl with all the > logic inside the template. That's insane! Never once did I mention > something like that! The template logic is meant to be used only for > some of the layout stuff, nothing more. I don't know where you came up > with foo.php -> foo.tmpl idea.

No, I understand that's not your intent. But your engine *allows* that. And if there's one thing I learned in the last 3 years, is that if it's possible - people will do it. It should not be possible.

> Exactly, the template logic is different! It has a different purpose.

It's not really different, it's just a different way to write it.

> Oh, and "a flat curve"? That's an oxymoron.

It makes a point. You have no learning curve for the simple templates, you know them inside out in anywhere between 0 to 5 minutes, depending on how much programming experience you have.

> Why do you twist my words? No one is introducing a whole new syntax to > PHP. Even if I wanted to do that, I still wouldn't be able to due to > your de facto ownership of the Zend code.

It has nothing to do with ownership of the Zend code; You are introducing a whole new syntax. De-facto, a .php script, could be converted to a couple of lines of .php and an equivalent .tmpl file, that would look completely different. Of course it's not intermixed with the PHP syntax in the low level, but essentially, it is.

> I also object to your argument that PHP programmers wouldn't understand > PHP scripts that use templates. I'm sorry but that's a little > ridiculous. You can apply the same argument to PHP scripts that use XML > or classes or regular expressions. What if someone doesn't know OOP or > regular expressions? Maybe we should make life easy for them as well, > eh?

None of your example is similar to the template issue, except for, perhaps, the OOP. XML/regular expression don't replace PHP's syntax. At best, they give you different ways of doing the same thing, but they're all under the same umbrella. Your template engine gives a complete, or perhaps not complete but way-too-comprehensive alternative to PHP's own syntax, within PHP. About whether or not we should have added OO support to PHP? I don't know. Many people liked it, but undoubtfully, it did cause problems to people that did not. It's not a very good example in the sense that I would have definitely not introduced something similar to a whole new programming paradigm into PHP today, and the template engine is exactly that.

> You seem that think that there should be one or two rigid > ways of writing PHP scripts. One of the big advantages of Open Source > movement is that it gives you _choice_. What a nice word.

That's marketing. You can choose between languages, between products. It's bad when you can choose between two completely different approaches within the same language. It only means the product/program is inconsistent.

> I'd be all in favour of implementing a fast > > plain&simple template engine at the PHP level, after receiving positive > > feedback about the need for templates (without logic) from many people, > > both in Zend and in ApacheCon. > > Funny I received lots of positive feedback on the current spec as well.

It's not funny, and I'm not surprised that you did. It's powerful, and people who like templates will probably like it. It doesn't change a thing from what I said, though. It's bad to have a template engine that's powerful enough to replace PHP logic. Not everything people like is a good idea to add to the language; I'm sure I could find dozens of people that would appreciate adding VB constructs to PHP. It doesn't mean it's good or responsible.

> > If you recall, the 'should we have > > built-in template support in PHP' argument at the PDM ended the second you > > said there should be if constructs in there - everyone said 'no way', but > > I don't firmly object the concept of templates, despite the fact I > > wouldn't use them myself. > > So, if you don't use PHP yourself to build things, how can you say that > PHP syntax is more applicable for the templates than the template > language syntax?

Because there are 1.78 million domains on the net using it, with, at best, a plain&simple template engine.

> > But I think the spec got completely carried away, and poses a significant > > problem to the uniformity of PHP as a simple and easy to use language. At > > any rate I wouldn't want the template engine to be at the language-parser > > level, but I wouldn't want to introduce a whole new syntax in whatever > > level. Much like I wouldn't want to add a Visual Basic parser on top of > > the PHP parser to let people mix VB with PHP, I don't want the template > > engine to be powerful enough to replace PHP logic. If it can do it, it > > means it's too powerful. > > Whoah, hold on. There it goes again. Who ever said that template engine > is going to replace PHP logic? It is not a programming language. It's a > layout language. Closer to CSS if anything.

It can replace PHP logic, therefore, for some unknown amount of people, it will. If it's just 10 people around the world by year 2005 - no problem. In my experience, it'll be lots of people and much sooner, even though you didn't intend for that to happen. > I still don't understand why you feel that PHP is threatened by this > template engine. Its use is optional. Just because we have XML extension > or PCRE extension doesn't mean that you are obligated to use it.

The difference is that it gives you the ability to write the same code in a completely different syntax. XML doesn't do that, neither does PCRE. They give you some sort of functionality, which you can decide you want to use, or not. They don't 'compete' with PHP. Essentially, your template engine is. Your immediate reaction would be to deny that, but think about it - your reasoning for using the template engine are because you think it's better for some things ('no contest'). Who will draw the line on what it's better for and what it's not? I, and many others, don't agree with you that it's even better for the examples you gave earlier. Others in the future, will probably not agree with you that it's NOT good for smoe other things, and would end up writing lots of logic in that template language instead of in PHP. That's competition, and having two syntaxes competing with each other within the same language is a Bad Thing.

> It may be a trivial template, but that's exactly what you propose > having as PHP's template system. Obviously, the template engine can do > this, but also other things, if you choose to take advantage of that.

I think I made my point on why giving the choice of using a whole different syntax isn't a good thing. Choice is indeed a good thing, but between different programs, different languages, different operating systems. Not two syntaxes for doing the same thing within the same language.

> How many times do I have to say it? It's not a programming language. > It's nothing like VB/JSP. Enough of this FUD.

It is. It has control structures - conditionals and loops, it has expressions. It's a programming language for any practical purpose, and the fact you can compare template code snippets to PHP code snippets, which you did, proves that.

> Ok. Then let's stop adding new extensions to PHP completely, because a > possible reader would have to be familiar with Perl-style regular > expressions, or sockets, or, God forbid, SQL syntax. The horror.

Functions are one thing, a whole new language syntax is another. I really think you're lacking some vision here, in realizing that as soon as this template engine is available, people would use it for all sorts of things you did not intend them to use it for, and it would bring small to medium chaos.

> > Well, today was the first time I actually read through the spec, and I was > > quite surprised to see a full-featured language laid out in there, instead > > of something that implements something similar to the template engines > > I've seen before. If logic, written in PHP can be rewritten in your > > template syntax, with completely different syntax, I think the spec lost > > it's path somewhere along the way. > > The template logic is not meant to replace PHP logic. See above.

But it *CAN*. That's the problem.

> If everyone subscribed to your philosophy, Zeev, we'd still be using awk > and sed as our scripting languages instead of PHP, Perl, and Python. > Three whole new languages. What an idea.

I actually don't think this is worthy of a reply, and you're in no position to throw mud at me like that. Anyway, I think what you're missing over and over again is that this is not a new language, but rather, a new syntax to an existing language, that duplicates large portions of its functionality.

Zeev

-- 
Zeev Suraski <zeevzend.com>
http://www.zend.com/

attached mail follows:

On Tue, 21 Mar 2000, Andrei Zmievski wrote:

> > The point is, I think the BIGGEST benefit from an integrated Template system > > in PHP should be purely to streamline the speed of the templates, rather > > than enhancing its features to the point of creating a whole new branch of > > coding. I say keep the templates as templates, and increase the flexibility > > of how those templates are used, but do NOT add too much logic to the > > template system. It makes for a weird "sub-PHP" language, IMHO. > > > > By the way, in defense of current template solutions for PHP, I have seen > > many fine examples, and worked on some myself, where ingenuity has overcome > > many of the weaknesses in the template systems. The only thing I see > > recurring is the issue of speed, so why not have the integrated template > > system focus on efficiency rather than complexity? > > In some strange way, all this reminds me of the C vs. C++ argument. > There too people talk about whole new way of coding, speed, C > programmers not knowing what the heck C++ is... But as we've seen > there's place for both. The same can be applied here.

I rest my case. You finally acknowledged that templates actually let you write the same logic differently, much like C++ lets you write your C logic differently. The only difference is that C++ is a superset of C, whereas your template engine doesn't even resemble PHP.

You didn't convince me, and many others, that the new template syntax is better than the existing PHP syntax for implementing logic (and you won't either, since it's a matter of personal taste; Some would think it is, others would think it's not). If you compare it to C++ vs. C, I, for one, would object adding it to the standard distribution. There's no room for the C<->C++ headache in the PHP world, especially when the motivation is unclear and unagreed upon.

Zeev

attached mail follows:

> I am providing a solution - you provided it yourself in your example, that > compared how to implement the template if in PHP code. Use PHP syntax for > logic, use your templates for presentation. I won't suggest using 'for' > loops instead of 'while' loops, which you may consider as constructive > criticism. I suggest moving logic outside of the templates engine > altogether.

I tend to agree with Zeev here... I see no purpose for templates if they go byeond this:

<HTML> <HEAD><TITLE>{TITLE}</TITLE></HEAD> <BODY><TABLE>  <TR> <TD>{CONTENT}</TD> <TD>{CONTENT_TWO}</TD> </TR>  </TABLE> </BODY> </HTML>

... I'll be the first one to admit that I would *really* like at times to have a <?php if($this): ?> statement in my template... it'd be great.... but I can acccomplish the same thing like this... take, for example... if I want to include a piece of javascript or not based on the $HTTP_USER_AGENT variable.

// {CONTENT} represents a link (pseudo-code)

$link = "<A HREF='".$URL."'";

if($browserver >= 4) $link .= " onMouseover='dojavascript();' ";

$link .= ">".$LINKNAME."</A>";

SetVar("CONTENT", $link);

Volia... I've included HTML (err.. javascript) code based on a conditional... My point is this... although it might not be as absolutely cut-and-dry to use

{CONTENT}

instead of

<A HREF="{URL}" {IF BROWSERVER >=4}onMouseOver='dojavascript();'</IF>>{LINKNAME}</A>

you actually have a LOT more realibility with the former...

besides.... not only do I *NOT* want to learn another lanaguge if I want templates... I wouldn't trust the lanaguage to function as expected... my sites need to work, a PHP3 has earned my trust as-is.

John

attached mail follows:

Most people, myself included, seem to start out in php doing lots of print "All my html stuff"; And then you realize that every (or ever php/phtml file) passes throught th parser. If something is not inside a <?php ?> block it is, for all intent, 'print'ed so there is no need to be redundant. This is what I like best about PHP over perl where everything (unless you use <<__END__ ) has to be explicitly printed.

So, long answer made short. Instead of doing this:

print "<table width='$tabwid>'";

just do this <table width='<? echo $tabwid ?>'>

It really is, in my opinion, the way a preprocessor (ala PHP) is designed to work, not by processing every piece of information, but by processing the stuff it needs.

The one that got me for a while is that you can do this.

<? for ($i=0; $i<10; $i++){ ?> <p>This is line number <? echo $i ?></p> <? } ?>

Just so long as your curly brackets around the block of code are inside the processing tag, that code gets executed every loop.

On Mon, Mar 20, 2000 at 11:20:40PM -0800, Art Center wrote: > Hi, okey, i got a php file = 23KB with like 50 lines of PHP code and all the > other are simply print ("HTML"); > > i dont want this, i wanna lower this down and take all the HTML code > out..... i know i can do include and all but then again what would be the > best way to "print" HTML code? > > i have 2 things i am thinking of > either include("some.php3"); > where some.php3 has print("LOTS OF HTML"); > > or > > include("some.php3"); > where some.php3 is just plain raw HTML code without print, i guess that also > works right? but IS IT FASTER than print command? > > any more is welcome... thanx a lot guys u always help me out > peace > > > -- > PHP 3 Mailing List <http://www.php.net/> > To unsubscribe, send an empty message to php3-unsubscribelists.php.net > To subscribe to the digest, e-mail: php3-digest-subscribelists.php.net > To search the mailing list archive, go to: http://www.php.net/mailsearch.php3 > To contact the list administrators, e-mail: php-list-adminlists.php.net >

-- Chris Moewes-Bystrom christophermoewes.com http://www.moewes.com http://www.linuxnovice.org

Looking for a PHP User Group in your area? Check http://www.moewes.com/phpug.php3

attached mail follows:

So, long answer made short. Instead of doing this:

print "<table width='$tabwid>'";

just do this <table width='<? echo $tabwid ?>'>

It really is, in my opinion, the way a preprocessor (ala PHP) is designed to work, not by processing every piece of information, but by processing the stuff it needs.

The one that got me for a while is that you can do this.

<? for ($i=0; $i<10; $i++){ ?> <p>This is line number <? echo $i ?></p> <? } ?>

Just so long as your curly brackets around the block of code are inside the processing tag, that code gets executed every loop.

-- Chris Moewes-Bystrom christophermoewes.com http://www.moewes.com http://www.linuxnovice.org

Looking for a PHP User Group in your area? Check http://www.moewes.com/phpug.php3

attached mail follows:

While you could separate everything like you did in your examples, I would highly recommend that you DO NOT do it. I believe this to be a bad programming practice because it makes your code much more unreadable. Yes it is more efficient, but if anyone else ever needs to alter the code, they will spend a much longer time deciphering it than if do not do it that way. Where I am at, readability is probably more important than server efficiency. This is probably the case with most people.

Jason Stechschulte jpstechnc.edu

So, long answer made short. Instead of doing this:

print "<table width='$tabwid>'";

just do this <table width='<? echo $tabwid ?>'>

It really is, in my opinion, the way a preprocessor (ala PHP) is designed to work, not by processing every piece of information, but by processing the stuff it needs.

The one that got me for a while is that you can do this.

<? for ($i=0; $i<10; $i++){ ?> <p>This is line number <? echo $i ?></p> <? } ?>

Just so long as your curly brackets around the block of code are inside the processing tag, that code gets executed every loop.

-- Chris Moewes-Bystrom christophermoewes.com http://www.moewes.com http://www.linuxnovice.org

Looking for a PHP User Group in your area? Check http://www.moewes.com/phpug.php3

-- PHP 3 Mailing List <http://www.php.net/> To unsubscribe, send an empty message to php3-unsubscribelists.php.net To subscribe to the digest, e-mail: php3-digest-subscribelists.php.net To search the mailing list archive, go to: http://www.php.net/mailsearch.php3 To contact the list administrators, e-mail: php-list-adminlists.php.net

attached mail follows:

Hi,

Does anybody know if there is a version of libphp3.so for PHP2, ie a libphp2.so, for Apache 1.3.6? Or, is there any way to compile the existing PHP2.0.1 package to achieve this exact end?

Or, is there a more straightforward way of running PHP2 scripts in an Apache 1.3.6 environment configured for Dynamic Shared Objects and running libphp3.so?

Any help will be greatly appreciated.

Thanks in advance.

--
==========================
World Careers Network
www.wcn.co.uk
==========================
Regards,
Benoit Grigaut

text/x-vcard attachment: Card for Benoit Grigaut

attached mail follows:

> Yeah. I realized this still wasn't what I wanted. Instead i took a look at > libphp. It rocks! > > As a side question(unfortunately mostly non php so perhaps private replies > would be best), does anyone know if there is a way to get the crypted > versions of unix passwords from the /etc/shadow file without a setuid root > script? I'm trying to authenticate users based on the unix password but I > need the crypted version of the unix pass in order to check it versus the > user supplied uname and pass. Suggestions?

See the posix_getpwnam() function. I don't think the Posix stuff is very well documented yet, but if you do a 'man getpwnam' on your UNIX box you should get a good idea of how it works.

-Rasmus

attached mail follows:

Hi all,

I've been playing with phplib with my php3 distrobution and it worked great until I tried to use a mysql database lookup inside the local.inc file in a custom auth function. The problem is this: The code works great if I don't make a database connection in local.inc and authenticate based on other criteria, but if I try to make a dbconn in local.inc, my php script complains with the following errors:

Warning: 3 is not a MySQL link index in db_mysql.inc on line 118 Warning: 3 is not a MySQL link index in db_mysql.inc on line 119 Warning: $user is not an object in page.inc on line 68 Fatal error: Member function used on a non-object in page.inc on line 68

I did not use any new global variables and I didn't blow away any variable names that may have already existed. Any ideas?

Thanks!

-Marc- #/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\# #Marc Swanson | \|||/ # #MSwanson Consulting | /o o\ # #Phone: (603)868-1721 |-ooo----O----ooo-# #Fax: (603)868-1730 | Solutions in: # #marcswansonmediaone.net| 'PHP 'Perl # # | 'SQL 'C++ # # | 'HTML 'Sh/Csh# #/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\#

attached mail follows:

> Warning: 3 is not a MySQL link index in db_mysql.inc on line 118 > Warning: 3 is not a MySQL link index in db_mysql.inc on line 119 > Warning: $user is not an object in page.inc on line 68 > Fatal error: Member function used on a non-object in page.inc on line 68

You may be accessing a instance of a object ($user object) before it is created... you have to create the object with a new User(); statment before you can use it..

maybe I'm way off tho

John

attached mail follows:

Hello,

I'm working with the PHPGem program which generates PHP code for displaying SQL table, viewing and editing records.

I'm not able to get the parent-child feature of the generator working and was wondering if anyone has worked with PHPGem to possibly help me with understanding how it works (or can be made to work).

In particular, I am able to define child tables linked to a parent table, but I'm not able to view or edit the child fields correctly.

Thanks in advance for any help on this.

Sue

__________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

attached mail follows:

On Mon, 20 Mar 2000, Erik Mathy wrote: > A simple templating system is cool. To be honest, I have not > looked at the template engine spec. Nor, I suspect, would I > understand it much if I did. And I'm sure the template engine > folks have their hearts in the right place, as well. I just want > to make sure that, in the rush to make PHP more popular, we don't > shoot ourselves in the foot. PHP is plenty easy, plenty powerful > and very popular. It's ever increasing server, mind and publicity > share back that up.

Umm, no one is rushing to make PHP more popular. It being popular is a consequence of its design and flexibility. Look, my goal is not to write this tremendous template engine and then somehow insidiously lure everyone into using it for _every single script_. I can get my thrills in many other ways. All I want to do is have another tool that helps different people do things a bit differently, if they want to.

Cheers,

-Andrei

"Everything should be made as simple as possible, but not simpler." -- Albert Einstein

attached mail follows:

Hi,

I'm using Redhat linux 6.1 and would like to connect to a remote MS SQL Server 7 db.

What is the best path; the Sybase or Openlink products?

Also has anybody any experience of this with PHP4?

Thanks,

attached mail follows:

There's any function that works as the C times function? I'd like to know how many time waste my MySQL query's to complete, and how much time it lasts to parse and send the page.

I know I can implement that with two calls to microtime() and substract them, but I'd like to use a times() like function, does it exists?

attached mail follows:

Thanks to all that replied. It seems the passwords are save. Although I suppose it is only relative.

However, the UNIX chmod is not doing what I was expecting. I have tried chmod 311, 611, 711 on the INCLUDE folder.

The folder is http://xxxx.com/include has a FORBIDDEN access However, if you know the name of the files like http://xxxx.com/include/password.inc, they can be called, parsed by PHP, and if there is content, they can be viewed. Is this how chmod works? Shouldn't they be FORBIDDEN also?

Andrew Sheh

> -----Original Message----- > From: ronabopchina.alphagraphics.com > [mailto:ronabopchina.alphagraphics.com]On Behalf Of Ron Chmara > Sent: Monday, March 20, 2000 11:42 AM > To: Andrew Sheh (DME) > Cc: php3lists.php.net > Subject: Re: [PHP3] Appears in View Source > > "Andrew Sheh (DME)" wrote: > > > > Very simple question to give me some ease of mind and not give my > > passwords away. I want to make sure to know what appears in the VIEW > > SOURCE of a HTML page after it is processed by PHP. > > > > Am I right to make these assumptions? > > > > SHOWS ** CODE > > in View > > Source > > ** <? > > no ** $password = "xxxx"; > > YES/NO ** require ('../include/password.inc'); > > no ** if ( $x =1; $x<1; $x++ ) > > no ** { echo '****'; } > > YES ** echo '<br>THIS WILL > > ** APPEAR IN VIEW SOURCE<br>'; > > ?> > > > > in ../include/password.inc all data between <? ?> then NO, > > otherwise if no <? ?>, then it is simple HTML code > > Those assumptions are good.... provided password.inc isn't accessable > (as in, http://www.dmetechnologies.com/include/password.inc), and you > don't allow users to echo back the variables, and password.inc is also > php parsed. > > -Bop > > > >

attached mail follows:

hello,

The function Ora_bind refuse to work.

I've read that variables must be global, but the problem is unchanged.

I've test the example of the php manuel but it doesn't work.

Could you help me? Did these files work whit you? Where the error if it exist? how I can use ora_bind?

Here the simple file essai.php3

<html> <head> </head> <body> <?php function t (){ //line 6 global $result; global $input; global $output; $cnx=ora_logon("gesteveBASE1","guilh"); //line 10 $curs=ora_open($cnx); ora_parse($curs, "declare tmp INTEGER; begin tmp := :in; :out := tmp; :x := 7.77; end;"); ora_bind($curs, "result", ":x", $len, 2); ora_bind($curs, "input", ":in", 5, 1); //line 15 ora_bind($curs, "output", ":out", 5, 2); $input = 765; ora_exec($curs); //line 18 echo "Result: $result<BR>Out: $output<BR>In: $input"; }

t(); ?>

</body> </html>

And here the result, whit netscape :

Warning: Ora_Exec failed (ORA-06502: PL/SQL: numeric or value error ORA-06512: at line 1 -- while processing OCI function OEXEC/OEXN) in /u2/tbi/gesteve/bd_html/essai.php3 on line 18 Result: Out: In: 765

-- ******************************************* * Guilhem ESTEVE * * gesteve

info-ufr.univ-montp2.fr * * DESS TNI - Université de Montpellier II * *******************************************

attached mail follows:

Does anyone know the best way to remove duplicate entries from and array?

Thanks, Keith Vance keithvbzlninc.com (206) 436-3874

attached mail follows:

Hi Keith,

Tobias Ratschiller posted a tip about this on the Zend website. The URL is:

http://www.zend.com/tips/tips.php?id=18&single=1

That one worked good for me. - Dave

On Tue, 21 Mar 2000, you wrote: > Does anyone know the best way to remove duplicate entries from and > array? >

-------------------------------------------------- David Nagel - University of Regina Students' Union Director of Communications & Information Services Regina, Sk., Canada, S4S-0A2, (306) - 586 - 8811 --------------------------------------------------

attached mail follows:

Does anyone else sometimes get the digest with a horrible color combination? For instance, I just got the latest digest and the background color was white, while the text color was bright yellow. I almost went blind. Besides turning off HTML, is there way to fix this?

Thanks, CT

attached mail follows:

Sorry... just haven't recieved any mail from the list in almost 24 hours, so I got worried

attached mail follows:

From: "=?ks_c_5601-1987?B?WXVsLWhvLCBTZW9uZ1wovLq/rcijXCk=?=" <yhseong

inouttech.co.kr> To: <php3

lists.php.net> Date: Tue, 21 Mar 2000 22:18:13 +0900 Message-ID: <CIEPIFLNONIIHDPIJINMCEKPCCAA.yhseong

inouttech.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 Subject: Help me?...

SSBhbSB1c2luZyBBcGFjaGUxLjMuOSAmIHBocDMuMC4xNSAmIG9yYWNsZTguMC41LiBUaGVyZSBp cyBubyBwcm9ibGVtIHRvIHVzZSBwaHAzLg0KSSdkIGxpa2UgdG8gdXNlIHNubXAgZnVuY3Rpb24g b2YgJ3VjZC1zbm1wIDMuNi4yJyBpbiBwaHAzDQpzbywgSSd2ZSBpbnN0YWxsZWQgdWNkLXNubXAz LjYuMiBhbmQgIGZpbmlzaGVkIGFsbCBjb25maWd1cmUgYXMgeW91ciBpbnN0cnVjdGlvbiBpbiBp bnN0YWxsIG1hbnVhbC4NCg0KSXMgdGhlcmUgYW55IG90aGVyIHRoaW5ncyB0byBkbz8/DQoNClRo aXMgaXMgZXJyb3IgbWVzc2FnZS49Pg0KRmF0YWwgZXJyb3I6IENhbGwgdG8gdW5zdXBwb3J0ZWQg b3IgdW5kZWZpbmVkIGZ1bmN0aW9uIHNubXBnZXQoKSBpbiAvTk1TL1NlcnZlcnMvZG9jcy9zbm1w LnBocDMgb24gbGluZSAzDQoNCnBocCBzb3VyY2U9Pg0KDQo8cHJlPg0KDQo8P3BocA0KJGI9IHNu bXBnZXQoIjIxMS40NS45MS4yMDMiLCJwdWJsaWMiLCJzeXN0ZW0uc3lzTmFtZS4wIik7DQplY2hv ICRiOw0KJGEgPSBzbm1wd2FsaygiMjExLjQ1LjkxLjIwMyIsInB1YmxpYyIsIiIpOw0KDQpmb3Ig KCRpPTA7ICRpPGNvdW50KCRhKTsgJGkrKykgew0KICAgIGVjaG8gJGFbJGldOw0KfQ0KPz4NCg0K PC9wcmU+DQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KSU5PVVQgVGVjaG5vbG9neSBSJkQgVGVhbQ0KUHJvamVjdCBNYW5hZ2VyIFku SC4gU0VPTkcgKHloc2VvbmdAaW5vdXR0ZWNoLmNvLmtyKQ0KVGVsOiArODItMzQzLTM4Mi03ODQ0 LCBGYXggOiArODItMzQzLTM4Mi03ODQ1DQpDZWxsdWxhcjogKzgyLTE3LTMzNC0yNjkyDQpDSVRZ IEhBTEwgIzcwNCwgMTU5MCwgQnVyaW0sIERvbmdhbiwgQW55YW5nLCBLb3JlYSA0MzEtMDY1DQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0

attached mail follows:

Aloha Dean,

> From: Dean James [mailto:sacramonemediaone.net]

> I need the info formatted with each value > (from the name value pairs) to be printed at certain spaces. this way > all entries align up left on each column.. > > name: Dean|email: deandean.com|city: Los Angeles > > If I need it like this: > > Dean Los Angeles deandean.com > > Meaning: If I need "Dean" to start printing on the 20th space, "los > Angeles" to start printing at the 60th space and the > "deandean.com" to > start at the 150th place.

As usual, TIMTOWTDI (There is more than one way to do it)...

A straightforward way:

Split the input lines on the pipe symbols:

($name, $email, $city) = split '|', $inputline;

Remove the words ending in ':' at the beginning of each item:

for ($name, $email, $city) { s/^\w+:\s*//; }

Format the output line:

$outputline = ' 'x19.sprintf '%-40.40s%-90.90s%s', $name, $city, $email;

In the sprintf format, %-40.40s means - left align (-) - using at least 40 positions (the first 40 of the two) - using at most 40 positions (the .40) - a string (s) Precede the name by 19 spaces (' 'x19) in order to start at position 20.

HTH, Arjen Bax

CMG Noord-Nederland B.V. Sector Telecommunications & Utilities Postbus 70237, 9704 AE Groningen Tel. (050)52 19 500, Fax (050)52 19 503

Press Ctrl-Alt-Del for free IQ-test

> -----Original Message----- > From: Dean James [mailto:sacramonemediaone.net] > Sent: Tuesday, March 21, 2000 8:08 AM > To: cgi-listjann.com; php3lists.php.net > Subject: [CGI] formatting text question:PERL > > > Hello, > > I have a question regarding formatting entries from a > flatfile database > that is pipe deliminated. I need the info formatted with each value > (from the name value pairs) to be printed at certain spaces. this way > all entries align up left on each column.. > > name: Dean|email: deandean.com|city: Los Angeles > > If I need it like this: > > Dean Los Angeles deandean.com > > Meaning: If I need "Dean" to start printing on the 20th space, "los > Angeles" to start printing at the 60th space and the > "deandean.com" to > start at the 150th place. > The data will be pretty spread out. I only want the value > printed, not > names((name, email, city etc..))..HOW WOULD I DO THIS. I AM VERY > CONFUSED AS TO STRING HANDLING WITH PERL > > thanks in advance. > dean > > ----------------------------------------------------------------- > To unsubscribe, send mail to "majordomojann.com" with > "unsubscribe cgi-list" > in the body. > > CalendarPlus v3.0 with JavaPlus is available NOW! > http://www.calendarplus.com/ > > The CGI Tips & Tricks website (and archive of the list) is located > at http://perl.jann.com/ > ----------------------------------------------------------------- >

attached mail follows:

Hi folks,

Our odbc_sv agent, as opposed to a databsae specific ones (sql6_sv for example) allow an ODBC bridge across machine boundries, and allow one to connect to a third party DSN. This is most useful when trying to connect to a database that Openlink doesn't support (Lotus Notes) and you do not have a driver for you client machine (linux) but you do for your database server (MS Windows)

Folks most commonly use this odbc_sv database agent to connect from linux to Access, FoxPro, etc., running on Windows, but it will allow _any_ third party or native driver on the server side. These include native communication protocols such as SQL*Net, etc.

Here is a breif architecture sketch:

Client box, Openlink Driver ------> Server, Openlink Request Broker ------> Openlink odbc_sv agent -----> Third party or Native driver ---> Database.

It is an additional layer, and not recommended if you can use a specific agent directly, but you still get the flexibilty, reporting and rules-based security that our drivers give you. In addition, this is a way of enforcing some SQL92 compliance on the back end system.

HTH!

Best regards, Andrew ---------------------------------------------------- Andrew Hill Technical Support Consultant OpenLink Software http://www.openlinksw.com Universal Database Connectivity Technology Providers

-----Original Message----- From: Deirdre Saoirse [mailto:deirdredeirdre.net] Sent: Monday, March 20, 2000 6:41 PM To: Michael P. Korpics Cc: php3lists.php.net Subject: Re: [PHP3] Remote ODBC

On Mon, 20 Mar 2000, Michael P. Korpics wrote:

> Is it possible for make an ODBC connection from a linux box running php > with apache to an NT machine running Lotus Notes?

Yes, via a driver like OpenLinkSW's ODBC driver for Linux. I've done it to Sql Server, not sure about support for Lotus Notes, but I don't think that'll be a problem.

-- _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "In /dev/null, no one can hear you scream"

attached mail follows:

I have a "VARCHAR" column in MYSQL table that is queried to fill in a pull down menu in a form, which works fine.

***CODE***works if ($row = mysql_fetch_array($results)) { do

echo ('<option value=' . $row["TECHNOLOGY"] . '>' . $row["TECHNOLOGY"] . '</option>' ); } while($row = mysql_fetch_array($results)); ***CODE***

However, some of the values have a space ("LCD Display", "TFT Display"). These show up fine in the form, but are the value Inserted into the Database is only "LCD", and "TFT".

If I change the columns to "LCD_Display", "TFT_Display", the Database receives correct values, otherwise, they are short. In this case, the PULL DOWN menu looks "abnormal" as the options have the "_".

The other solution I found is to have 2 columns like "TFT Displays" for the Pull Down name, "TFT_Displays" for the VALUE, but it would be many extra keystrokes for a larger project I am writing.

Any ideas.

Thanks Andrew Sheh

attached mail follows:

Just noticed this today.

jump.altavista.com is using PHP.

Don't believe me? Read the HTTP response headers yourself.

http://homepages.maxnet.co.nz/kimihia/projects/sockhead/demo.php3?chk_uri=ht tp://jump.altavista.com/

---- Stephen D C -- Auckland, New Zealand ---- kimihia*writeme.com // http://surf.to/stephenc ===-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=== Because of lamb tariffs the Unabomber will be sending nuclear warheads from Oklahoma to Iraq

attached mail follows:

: run. Problem being, any way you sort a set of links means that someone's at : a disadvantage. If they're sorted ascending, then the people in the second

That's the one.

How about you serve up maybe three randomly selected links.

Weigh the links (weight = n_clicks * 1.5 + n_shows * 0.8), then show the lightest five adverts.

The only problem with that is you'll end up consistantly showing boring / unwanted links.

For example, if you have three sites:

* The most interesting site.com * Mediocre.com * Totally boring.com

On about the third weighing, Totally boring.com will be the lightest and will get shown along with Mediocre.com.

Over time Totally boring.com will have secured its place at the top of the list (1 click through compared with 80 click throughs on the others) and people will see your links list as a useless resource (due to the way the most frequently shown link will be a bad one).

So, you'll have to implement / modify an algorithm that works out how useful a resource is based on the click through ratio.

For example n_clicks = n_clicks ? n_clicks : 1; // div by 0 protection weight = (n_clicks * 2) + ( (n_shows / n_clicks) * 4);

Through a bit of tuning (in an artificial intelligence method) you will be able to get links people are interested in.

attached mail follows:

On Mon, 20 Mar 2000 23:41:42 +0100, "Jesper Hess Nielsen" <jespergraffen.dk> said:

Jesper> I tried changing the permissions on /root but get the same Jesper> error... Information like "You shouldn't use xxx - use yyy Jesper> instead" are useless to me. I'm running qmail and that's Jesper> that. And PHP should be able to function with Qmail - so Jesper> that's what I'm looking for.

Well, it's been workingfine for me. In php.ini I use:

sendmail_path = /usr/lib/sendmail -t ; actually a qmail wrapper

or now in httpd.conf (I use mod_php) I use:

# Interaction with QMAIL: # We want the HEADER From: to be the service sender user's address so # recipients can reply to them, but we want the ENVELOPE From to be # Postmaster|ErrorsMyService.com so bounces get handled properly. # The qmail-inject docs indicate QMAILSUSER/QMAILSHOST set envelope info, and # that if Return-Path is in the Headers it sets the envelope sender address.

php_value sendmail_path "/usr/lib/sendmail -t"

I haven't done it yet but there's no reason you can't use qmail-inject directly, with the right flags set.

attached mail follows:

Hi,

I have a php3 script that reads a text file that contains quotation marks. This works fine on my test bed (Win98/Apache/php3). When I upload it to my ISP however, the quotation marks are escaped (\").

What I apparently need to do is set magic_quotes_runtime to true on my ISP. The ISP, Mindspring, is pretty picky about what I can do. I have no chance of getting a change made to the php.ini file. I try to set_magic_quotes_runtime() in code and it produces "Fatal error: Call to unsupported or undefined function set_magic_quotes_runtime()..."

Does anyone have any suggestions? I would really like to *not* parse the slashes back out myself.

Thanks, ------------------------------------------------- Jason Brackins King of Monsters

Next message: php3-digest-helplists.php.net: "php3 Digest 22 Mar 2000 06:00:00 -0000 Issue 1553"
Previous message: php3-digest-helplists.php.net: "php3 Digest 21 Mar 2000 18:25:21 -0000 Issue 1551"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]