phplib-users — A list for users of phplib to talk / discuss phplib

[Phplib-users] CVS ??

[Lindsay H. <fm...@fm...>]

What's the situation with the phplib CVS repository?  I can't get to it from
either the web interface or from my CVS directory which used to work.

-- 
Lindsay Haisley       | "Everything works    |     PGP public key
FMP Computer Services |       if you let it" |      available at
512-259-1190          |    (The Roadie)      | <http://www.fmp.com/pubkeys>
http://www.fmp.com    |                      |

RE: [Phplib-users] fetch_array

[Layne W. <la...@of...>]

> > $db->query("SELECT sid FROM active_sessions LIMIT 1");
> > $db->next_record();
> >
> > echo $db->Record["sid"];
> >
> > next_record() puts the array in $db->Record.
>
> Is that "legal"?  I had avoided doing that because I was 
> afraid that it might break in future releases, sticking
> instead only to the documented API.

I suppose it isn't proper OOP - I've seen other people's code that does the
same, so I hadn't thought too much about it.  

If I'm only going to use the data once or twice, I'll use $db->f(), but when
I use the data many times over I want to save the function call and access
an array directly. I've modified my own next_record() to optionally return
the record array:
    $db->query("...");
    while($record = $db->next_record(true)) { ... }

Is this a shortcut that is useful and worthy of inclusion in the standard
distribution?


Layne Weathers
Ifworld Inc. 

Re: [Phplib-users] fetch_array

[Aric C. <gre...@pe...>]

Is that "legal"?  I had avoided doing that because I was afraid that it
might break in future releases, sticking instead only to the documented API.


----- Original Message -----
From: "Layne Weathers" <la...@of...>
To: "'Serghej Petrov'" <sp...@ti...>
Cc: <php...@li...>
Sent: Wednesday, January 15, 2003 9:38 AM
Subject: RE: [Phplib-users] fetch_array


> > Is there function in phplib equal to mysql_fetch_array() ????
>
> $db->query("SELECT sid FROM active_sessions LIMIT 1");
> $db->next_record();
>
> echo $db->Record["sid"];
>
> next_record() puts the array in $db->Record.
>
>
> Layne Weathers
> Ifworld Inc.
>

Re: [Phplib-users] template extensions

[Fred Y. <fr...@on...>]

Since this thread has been discussing strict separation of HTML and
PHP code using phpLib templates, I'd like to point to a short how-to
on one way to accomplish that via current phpLib templates:

   http://ontosys.com/phplib/examples.php

As Steve Krug says, "It ain't rocket surgery!".

-- 
Fred Yankowski      fr...@on...           tel: +1.630.879.1312
OntoSys, Inc	    PGP keyID: 7B449345        fax: +1.630.879.1370
www.ontosys.com     38W242 Deerpath Rd, Batavia, IL 60510-9461, USA

RE: [Phplib-users] fetch_array

[Layne W. <la...@of...>]

> Is there function in phplib equal to mysql_fetch_array() ????

$db->query("SELECT sid FROM active_sessions LIMIT 1");
$db->next_record();

echo $db->Record["sid"];

next_record() puts the array in $db->Record.


Layne Weathers
Ifworld Inc. 

[Phplib-users] fetch_array

[Serghej P. <sp...@ti...>]

Hello everybody,
Is there function in phplib equal to mysql_fetch_array() ????


Thank all

Serghej

RE: [Phplib-users] template extensions

[Rob H. <rob...@ws...>]

I uses the module extension along with a minor tweak to the template class.
The module extension is attached.  The tweak was that there is an
inconsistant use of finish within the template class itself between get and
print I believe (it's been a while).  It is attached also.

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271


> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Aric Caley
> Sent: Tuesday, January 14, 2003 5:39 PM
> To: php...@li...
> Subject: Re: [Phplib-users] template extensions
>
>
>
> ----- Original Message -----
> From: "Layne Weathers" <la...@of...>
> To: <php...@li...>
> Sent: Tuesday, January 14, 2003 1:24 PM
> Subject: RE: [Phplib-users] template extensions
>
>
> > Before I reply to any particular statements, it appears to me that some
> > people on this list might be dealing with some internal project issues.
> > There have been several comments about not trusting the programmers and
> not
> > knowing what the final outcome of the project is going to be. You cannot
> > expect to solve your development problems, whether from communication or
> > incompetence in your team, by a clever software hack. If you cannot
> > coordinate programmers and graphic designers it is time to evaluate your
> > culture/environment and personnel.
>
> No argument there. :)
>
> > Quoth Evan Hughes:
> > >   I'll be the first to admit that this isn't a huge saving.
> > > All it gives us is:
> > >   a) Faster runtime (there's no risk of unused variables
> > > being created)
> >
> > This simply is not true. The current template implementation has the
> > following basic steps:
> >
> > 1. set variables in an array
> > 2. preg_replace the variable names with the variable content
> > 3. if unknowns is not set to "keep", replace all variable matches with
> empty
> > string or comment
> >
> > The proposed change would add the following steps:
> >
> > 3. find each remaining variable (or function or whatever) match
> > 4. loop through the result set
> >    a. find associated function, if it exists
> >    b. run function and replace in template with output
> >
> > The problem is that the current implementation doesn't have to look at
> each
> > undefined variable - your implementation would.
>
> I could be wrong, but looking at the template class you find a
> method called
> finish() which in fact looks at every variable (well, the
> preg_replace does,
> anyway) that's left and decides what to do with them.  You could
> easily add
> a new type "callback" to the existing "keep, remove, comment" and
> have that
> one do a preg_replace_callback().
>
> That would be very generic and optional, adding no real  overhead
> if its not
> used.
>
> Then he could make a subclass of template, define his callback function to
> take the variable name and include a file/run a function based on that,
> returning the data to be used in the template.
>
> > >   As a side note: Consider the implications of (b) and (c)
> > > from above. If we
> > > take the whole variable backing thing to an extreme, we can
> > > move all of the
> > > dynamically generated content out of php scripts and stick
> > > them into files.
> > > This means we don't need any php between the templates and
> > > the outside world.
> > > If we use .htaccess to prevent download of .tpl files, and
> > > catch requests for
> > > them with an error_document handler (which would evaluate the
> > > named template),
> > > we can essentially provide an interface where we're just
> > > serving raw templates.
> >
> >
> > Stop! What problem are you trying to solve here? Now you're
> talking about
> > content caching, which is completely different from variable layouts.
> >
> > Also, you've mentioned in a couple messages that you would like
> to remove
> > PHP from the public site. If that is your true gain, you cannot rely on
> the
> > Template class - it's PHP!
>
> That one doesnt make sense to me either.. :)
>
> >
> > Layne Weathers
> > Ifworld Inc.
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by: Take your first step towards giving
> > your online business a competitive advantage. Test-drive a Thawte SSL
> > certificate - our easy online guide will show you how. Click here to get
> > started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
> > _______________________________________________
> > Phplib-users mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phplib-users
> >
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Take your first step towards giving
> your online business a competitive advantage. Test-drive a Thawte SSL
> certificate - our easy online guide will show you how. Click here to get
> started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

Re: [Phplib-users] template extensions

[Aric C. <gre...@pe...>]

----- Original Message -----
From: "Layne Weathers" <la...@of...>
To: <php...@li...>
Sent: Tuesday, January 14, 2003 1:24 PM
Subject: RE: [Phplib-users] template extensions


> Before I reply to any particular statements, it appears to me that some
> people on this list might be dealing with some internal project issues.
> There have been several comments about not trusting the programmers and
not
> knowing what the final outcome of the project is going to be. You cannot
> expect to solve your development problems, whether from communication or
> incompetence in your team, by a clever software hack. If you cannot
> coordinate programmers and graphic designers it is time to evaluate your
> culture/environment and personnel.

No argument there. :)

> Quoth Evan Hughes:
> >   I'll be the first to admit that this isn't a huge saving.
> > All it gives us is:
> >   a) Faster runtime (there's no risk of unused variables
> > being created)
>
> This simply is not true. The current template implementation has the
> following basic steps:
>
> 1. set variables in an array
> 2. preg_replace the variable names with the variable content
> 3. if unknowns is not set to "keep", replace all variable matches with
empty
> string or comment
>
> The proposed change would add the following steps:
>
> 3. find each remaining variable (or function or whatever) match
> 4. loop through the result set
>    a. find associated function, if it exists
>    b. run function and replace in template with output
>
> The problem is that the current implementation doesn't have to look at
each
> undefined variable - your implementation would.

I could be wrong, but looking at the template class you find a method called
finish() which in fact looks at every variable (well, the preg_replace does,
anyway) that's left and decides what to do with them.  You could easily add
a new type "callback" to the existing "keep, remove, comment" and have that
one do a preg_replace_callback().

That would be very generic and optional, adding no real  overhead if its not
used.

Then he could make a subclass of template, define his callback function to
take the variable name and include a file/run a function based on that,
returning the data to be used in the template.

> >   As a side note: Consider the implications of (b) and (c)
> > from above. If we
> > take the whole variable backing thing to an extreme, we can
> > move all of the
> > dynamically generated content out of php scripts and stick
> > them into files.
> > This means we don't need any php between the templates and
> > the outside world.
> > If we use .htaccess to prevent download of .tpl files, and
> > catch requests for
> > them with an error_document handler (which would evaluate the
> > named template),
> > we can essentially provide an interface where we're just
> > serving raw templates.
>
>
> Stop! What problem are you trying to solve here? Now you're talking about
> content caching, which is completely different from variable layouts.
>
> Also, you've mentioned in a couple messages that you would like to remove
> PHP from the public site. If that is your true gain, you cannot rely on
the
> Template class - it's PHP!

That one doesnt make sense to me either.. :)

>
> Layne Weathers
> Ifworld Inc.
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Take your first step towards giving
> your online business a competitive advantage. Test-drive a Thawte SSL
> certificate - our easy online guide will show you how. Click here to get
> started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

RE: [Phplib-users] template extensions

[Layne W. <la...@of...>]

Before I reply to any particular statements, it appears to me that some
people on this list might be dealing with some internal project issues.
There have been several comments about not trusting the programmers and not
knowing what the final outcome of the project is going to be. You cannot
expect to solve your development problems, whether from communication or
incompetence in your team, by a clever software hack. If you cannot
coordinate programmers and graphic designers it is time to evaluate your
culture/environment and personnel.

On the other hand, I could be reading my previous experiences into your
emails. If so, please ignore the previous sentences.


Quoth Evan Hughes:
>   I'll be the first to admit that this isn't a huge saving. 
> All it gives us is:
>   a) Faster runtime (there's no risk of unused variables 
> being created)


This simply is not true. The current template implementation has the
following basic steps:

1. set variables in an array
2. preg_replace the variable names with the variable content
3. if unknowns is not set to "keep", replace all variable matches with empty
string or comment

The proposed change would add the following steps:

3. find each remaining variable (or function or whatever) match
4. loop through the result set
   a. find associated function, if it exists
   b. run function and replace in template with output

The problem is that the current implementation doesn't have to look at each
undefined variable - your implementation would.


>   b) Enforced encapsulation of variable definition into 
> separate files. Notice that this really encourages reuse.


What you should really consider doing here is separating the parts of the
page (header, footer, navigation, auxiliary content modules {e.g. calendar,
poll}, etc.) into their own templates. Write a function and/or class for
generating each piece and a function/class for building a dynamic layout
(this would then call the individual piece display code).


>   c) Greater decoupling of templates and their defining code.
> 
>   But it comes at virtually no cost. The only change to the 
> API that I see
> would be a "set_backing_dir(path)" which would set the path 
> to the directory
> that contains the files that would back the variables. 


API change does not equate performance cost.


>   As a side note: Consider the implications of (b) and (c) 
> from above. If we
> take the whole variable backing thing to an extreme, we can 
> move all of the
> dynamically generated content out of php scripts and stick 
> them into files. 
> This means we don't need any php between the templates and 
> the outside world. 
> If we use .htaccess to prevent download of .tpl files, and 
> catch requests for 
> them with an error_document handler (which would evaluate the 
> named template), 
> we can essentially provide an interface where we're just 
> serving raw templates.


Stop! What problem are you trying to solve here? Now you're talking about
content caching, which is completely different from variable layouts.

Also, you've mentioned in a couple messages that you would like to remove
PHP from the public site. If that is your true gain, you cannot rely on the
Template class - it's PHP!


> > Instead of putting those functions in the template, 
> couldn't you just put 
> > template variables in the template and have the PHP code 
> filling in the 
> > template perform the functions for those variables?
> 
>   You could. What Mike and I are suggesting is essentially 
> just a lazy linker: 
> instead of exhaustively defining all possible variables 
> before the script 
> is run (or worse, sculpting code that will conform to the templates), 
> simply move the resolution of variables to a just-in-time 
> model where they're 
> defined as needed. 


Hmmm. You don't want to have the code and the templates work together. Why
not? Do yourself a favor and put a bit of planning and thought into your
project before you build it.


> > Or, if there is some reason I am missing to want to do 
> this, why use 
> > templates at all?  Why not just use straight PHP and use 
> <?php include 
> > your_function.php; ?> or <?php your_function(n); ?> in 
> place of your 
> > curly-bracketed functions?
> 
>   Because that mixes presentation with logic. As soon as it's 
> in vanilla php,
> we lose the ability to use templates (unless we're calling 
> out to other files,
> etc). 


I have found it useful to combine the techniques - I have built sites that
use includes to build portions of dynamic content with the Template class.


Layne Weathers
Ifworld Inc. 

Re: [Phplib-users] template extensions

[Aric C. <gre...@pe...>]

>
>   The proposed approach would sever that connection. Instead of a
hand-crafted
> script sitting in front of each template defining variables (in a
> coder-dependant manner that may or may not encourage reuse), there would
be a
> standard location where dynamically generated content would live. As a
> template is evaluated, and reference to that content are detected, it
would
> be imported and generated.
>
>   Notice that lovingly hand-crafted scripts (made by italian monks to the
> highest standards, using a secret process handed down from their celebate
> forefathers) are no longer necessary. All templates can be treated the
same.
>
>   Notice that all dynamically generated content in a site is now put into
a
> single location and forced to be encapsulated (there are arguments against
> wholesale encapsulation, but that's where php's 'include' statement comes
into
> play).

Another aspect of this is that if the designer wants something that hasnt
been coded yet, he can just put some dummy html data into a file where the
function would be, and the programmer can come along later and turn it into
proper php code.

> --
> Evan Hughes
> OpenConcept Consulting
(openconcept.ca)
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Take your first step towards giving
> your online business a competitive advantage. Test-drive a Thawte SSL
> certificate - our easy online guide will show you how. Click here to get
> started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

Re: [Phplib-users] template extensions

[Aric C. <gre...@pe...>]

Seems like this could be done very genericaly.  Simply change the template
class to have a callback option for unknown variables in the template.  Then
you could easily have a subclassed template object that defines that
callback method to do what you are describing.

You could also do other things, like for instance use it to look up language
translations automaticaly for variables that are just going to be strings,
instead of doing a big set_var() with your own "get_string()" or whatever
for each variable.

----- Original Message -----
From: "Evan Hughes" <hu...@bi...>
To: <php...@li...>
Sent: Tuesday, January 14, 2003 11:27 AM
Subject: [Phplib-users] template extensions


> Andrew Crawford wrote:
> ...
> > Maybe I'm not understanding something.  That just seems backwards to
> > me.  Normally, the PHP file is being evaluated and pulls formatting
> > information from the template.  So, now, the template would be evaluated
> > and pull code from another file?  Why?
>
>   To abstract the presentation away from the code. Currently, if I want to
add
> a dynamic block of html (one that's backed by code instead of static data
from
> a file), I have to:
>   1. write a bunch of code to create the dynamic content
>   2. modify the php script that will be including the template (to add the
>      set_var())
>   3. modify the template to include the named variable
>
>   In a situation where variables are backed by functions, step two can be
> dropped. This lessens the coupling between the php script in 2 and the
template
> in 3.
>
>   I'll be the first to admit that this isn't a huge saving. All it gives
us is:
>   a) Faster runtime (there's no risk of unused variables being created)
>   b) Enforced encapsulation of variable definition into separate files.
Notice
> that this really encourages reuse.
>   c) Greater decoupling of templates and their defining code.
>
>   But it comes at virtually no cost. The only change to the API that I see
> would be a "set_backing_dir(path)" which would set the path to the
directory
> that contains the files that would back the variables.
>
>   As a side note: Consider the implications of (b) and (c) from above. If
we
> take the whole variable backing thing to an extreme, we can move all of
the
> dynamically generated content out of php scripts and stick them into
files.
> This means we don't need any php between the templates and the outside
world.
> If we use .htaccess to prevent download of .tpl files, and catch requests
for
> them with an error_document handler (which would evaluate the named
template),
> we can essentially provide an interface where we're just serving raw
templates.
>
>
> > Instead of putting those functions in the template, couldn't you just
put
> > template variables in the template and have the PHP code filling in the
> > template perform the functions for those variables?
>
>   You could. What Mike and I are suggesting is essentially just a lazy
linker:
> instead of exhaustively defining all possible variables before the script
> is run (or worse, sculpting code that will conform to the templates),
> simply move the resolution of variables to a just-in-time model where
they're
> defined as needed.
>
> > Or, if there is some reason I am missing to want to do this, why use
> > templates at all?  Why not just use straight PHP and use <?php include
> > your_function.php; ?> or <?php your_function(n); ?> in place of your
> > curly-bracketed functions?
>
>   Because that mixes presentation with logic. As soon as it's in vanilla
php,
> we lose the ability to use templates (unless we're calling out to other
files,
> etc).
>
> --
> Evan Hughes
> OpenConcept Consulting
(openconcept.ca)
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Take your first step towards giving
> your online business a competitive advantage. Test-drive a Thawte SSL
> certificate - our easy online guide will show you how. Click here to get
> started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

[Phplib-users] template extensions

[Evan H. <hu...@bi...>]

Richard Archer wrote:
> The philosophy of the template class is to separate the data
> presentation from the application logic. template.inc does this, and
> does it very well (and with good performance into the bargain).

  The approach that Mike and I are suggesting improves that separation, without
any negative impact on performance (I'm speaking from a theoretical
perspective: I haven't implemented this, so I can't be certain). 

  Currently there is a tight coupling between code and templates because 
variables corresponding to dynamic content must be defined explicitly in php. 
This means that there is either a hand crafted php script sitting in front 
of every template, or there are more variables being defined than are 
necessary. 

  The proposed approach would sever that connection. Instead of a hand-crafted
script sitting in front of each template defining variables (in a
coder-dependant manner that may or may not encourage reuse), there would be a 
standard location where dynamically generated content would live. As a 
template is evaluated, and reference to that content are detected, it would 
be imported and generated. 

  Notice that lovingly hand-crafted scripts (made by italian monks to the
highest standards, using a secret process handed down from their celebate
forefathers) are no longer necessary. All templates can be treated the same. 

  Notice that all dynamically generated content in a site is now put into a
single location and forced to be encapsulated (there are arguments against
wholesale encapsulation, but that's where php's 'include' statement comes into
play).

> Once you start adding scripting to a template class, where do you stop.

  These would not be scripting components. They would be references to files to
run and include (a la server-side-includes, php's include, and a plethora of
inclusion tools). There would be no logic stored in the templates: no control
structures, no variables, no operators, no expressions. 

  All we are suggesting is late binding. Instead of doing all of the
variable/value binding up front (before the template is evaluated), we would
allow it to be done later in the run cycle (on demand). 

> You finish up re-implementing PHP within PHP. And you open up a whole
> lot of security concerns which designers shouldn't need to worry about.

  Again: no. There would be no difference between this mechanism and the 
existing include mechanism. 

> And you kill your performance.

  Not according to the architecture we have suggested. 
 
--
Evan Hughes
OpenConcept Consulting                                       (openconcept.ca)

[Phplib-users] Release: phplib 7.4-pre2

[Joe S. <joe...@us...>]

----------------------------------------------------------------------------
phplib-7.4-pre2
----------------------------------------------------------------------------
Some features and improvements include:

php4 session support ( prepend.php)
register_globals can be off for most classes
Template class has many improvements and bugfixes.

THIS IS A PRE-RELEASE BETA!  This is for testing only, this release may 
eat your website or break everything!  Please test it and report any 
problems to the phplib-users list or to the SourceForge Bug trackers at 
http://sf.net/projects/phplib/

----------------------------------------------------------------------------
---------------------------------------------------------------------------
Where to get phplib 7.4-pre2: 
---------------------------------------------------------------------------
http://sourceforge.net/projects/phplib/

This release has been tagged as PHPLIB_7_4_PRE2 

---------------------------------------------------------------------------
Other general info:
---------------------------------------------------------------------------
- Support can be found on php...@li... 
- File bugs at http://sourceforge.net/projects/phplib/

[Phplib-users] template extensions

[Evan H. <hu...@bi...>]

Andrew Crawford wrote:
...
> Maybe I'm not understanding something.  That just seems backwards to 
> me.  Normally, the PHP file is being evaluated and pulls formatting 
> information from the template.  So, now, the template would be evaluated 
> and pull code from another file?  Why?

  To abstract the presentation away from the code. Currently, if I want to add
a dynamic block of html (one that's backed by code instead of static data from 
a file), I have to:
  1. write a bunch of code to create the dynamic content
  2. modify the php script that will be including the template (to add the 
     set_var())
  3. modify the template to include the named variable

  In a situation where variables are backed by functions, step two can be
dropped. This lessens the coupling between the php script in 2 and the template
in 3. 

  I'll be the first to admit that this isn't a huge saving. All it gives us is:
  a) Faster runtime (there's no risk of unused variables being created)
  b) Enforced encapsulation of variable definition into separate files. Notice
that this really encourages reuse. 
  c) Greater decoupling of templates and their defining code.

  But it comes at virtually no cost. The only change to the API that I see
would be a "set_backing_dir(path)" which would set the path to the directory
that contains the files that would back the variables. 

  As a side note: Consider the implications of (b) and (c) from above. If we
take the whole variable backing thing to an extreme, we can move all of the
dynamically generated content out of php scripts and stick them into files. 
This means we don't need any php between the templates and the outside world. 
If we use .htaccess to prevent download of .tpl files, and catch requests for 
them with an error_document handler (which would evaluate the named template), 
we can essentially provide an interface where we're just serving raw templates.


> Instead of putting those functions in the template, couldn't you just put 
> template variables in the template and have the PHP code filling in the 
> template perform the functions for those variables?

  You could. What Mike and I are suggesting is essentially just a lazy linker: 
instead of exhaustively defining all possible variables before the script 
is run (or worse, sculpting code that will conform to the templates), 
simply move the resolution of variables to a just-in-time model where they're 
defined as needed. 

> Or, if there is some reason I am missing to want to do this, why use 
> templates at all?  Why not just use straight PHP and use <?php include 
> your_function.php; ?> or <?php your_function(n); ?> in place of your 
> curly-bracketed functions?

  Because that mixes presentation with logic. As soon as it's in vanilla php,
we lose the ability to use templates (unless we're calling out to other files,
etc). 

--
Evan Hughes
OpenConcept Consulting                                       (openconcept.ca)

[Phplib-users] template extensions

[Evan H. <hu...@bi...>]

  Howdy, 

  I'm the colleague that Mike mentioned. The remainder of this email is 
a more in-depth description of what Mike had mentioned.

Dr Tarique Sani wrote:
> On 13 Jan 2003, Mike Gifford wrote:
> >                 <td><!-- main content -->
> >                         {Article($ArticleId)}
> one question
> How will the $ArticleId be passed to the template?

  'ArticleId' would be used as a key into the globals array. 

  The germ of my idea doesn't rest on variable passing (although that could be 
a Good Thing, it isn't the basis of my idea). What I'm really interested in 
is backing variables with functions -- which would allow static pages to 
reference content that is generated dynamically. This would allow the creation 
of templates that require no intervention from PHP to render content. 

  Consider the following situation:

  I'm building a site where I want all pages to follow a certain format, and
contain a number of elements that are repeated between pages. However,
different elements will appear on different pages (even though at coding time, 
I'm not sure what will appear where). Say that I want my dynamic elements to 
be:

  Poll - Dynamically generated poll
  RDF - RDF listing of the site's content
  Calendar - A calendar of events
  LoggedIn - A listing of who is logged in
  News - A listing of news items

  I know that these are necessary when I'm writing the code that will generate 
the site, but I'm not sure when or where they will be used (I'm not in control 
of final appearance/layout, someone else is). 


  Using the current architecture I would be forced to define all of these 
elements before evaluating the templates, even if they aren't used in the 
page. 
  
  In a function backed variable architecture, I would define a directory that
would contain a listing of renderers that would produce output for a given
variable names. So, for this example, I would have a directory that would
contain a set of files (functions/Poll.php, functions/RDF.php,
functions/Calendar.php, etc). When the parser in template.inc tried to link a 
variable reference that it doesn't know about, it would check this directory - 
if there is a file that matches the name of the variable, it would be 
evaluated and its output linked into that variable. 
  

  The value of backing variables with functions should be apparent outside of
this example: the one-file-per-variable constraint on content forces
encapsulation of functionality into a single file that would have a
well-defined interface. 

e

Re: [Phplib-users] template extensions

[Aric C. <gre...@pe...>]

> At 06:59 PM 1/13/2003 -0800, Aric Caley wrote:
> >It seems to go against the general idea of templates: to separate code
from
> >presentation.
>
> It seems that way to me, too.
>
> >It would also be nice for the templates to be able to use this to tell
the
> >code what to do in certain cases.  For instance, what if the template has
a
> >4 by n grid.  But the designer wants it changed to, say 6 wide.
Currently
> >you'd probably have a nested set of blocks (one for horizontal, one for
> >vertical) and the code would determine how many wide to go, so the
> >programmer would have to go in and change that.  With this you could just
> >have something like this:
> >
> >{setmatrix(4)}
> ><!-- BEGIN matrix -->
> ><img src="block.gif">
> ><!-- END matrix -->
> >
> >And the code would know what to do.
>
> ... or, you could code that as a variable in a configuration file or the
> header section of your PHP file that fills in the template.  Then, the PHP
> file could determine what to do with that information.  Strangely enough,
> I've done exactly that with some of the stuff I have developed.
>
> For example, an image gallery thumbnail page has a configuration file that
> has variables like thumbs_num_rows and thumbs_num_columns.  The designer
> can choose the numbers after the equal signs without even as much brain
> power as required to understand the {setmatrix(4)} syntax.  You can even
> put a more detailed comment right before the settings for the unusually
> obtuse designer.  The PHP code then iterates appropriately when filling in
> the template.  It works great.

And that's what I currently do.

The more interesting aspect of this idea is that the designer could not only
create the cosmetics but could more easily rearrange the whole structure of
the site through the template, where normaly this would require moving
around blocks of code.

Then again, this could be achieved with the current template system and just
using more clever code.

>
> Andrew Crawford
> An...@Ev...
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

[Phplib-users] How can i get a value of a formfield which is generated with oohf orms

[Benjamin H. <ho...@eu...>]

I have a problem how to get a value of a submitted form.

My Problem is that i generating a class obj from an selection of a =
selectfield.

e.g. i have a class news and a class company=20
both are selectable in a option field.
after submit i create an object of the selected class

and use a function in that class to add_elements to the given form =
which i opend in the search.php

but after the submit i could only get to the values of the sumition if =
i new the Form element name like $COMPANYNAME

but if i selected news at the first page to search for a news other =
options to search for are given like $NEWSDATE

how can i make a function in the news / company class which can get the =
submited value of a formelement

$f->elements is the array of the submitted field but they have only the =
default value=20



in the class of_element=20

the function=20
function marshal_dispatch($m,$func) {  =20
    $vname =3D $this->name;
    global $$vname;
    return $this->$func($$vname);
  }

makes the validation and sets the value $$vname;

isn=B4t the a function to get the value of a submited element like =
$f->get_elementvalue("COMPANYNAME")

because i would like to have it in the class and not on serveral pages.

Hope i could be understood what i mean.
Sorry for my bad english

Thanks for tips and helps=20

Benjamin

Re: [Phplib-users] template extensions

[Andrew C. <An...@Ev...>]

At 09:42 PM 1/13/2003 -0500, Mike Gifford wrote:
>Evan's thought was that it would be really, really nice there were hooks
>for calling functions right in the templates, allowing our pages to look
>something like:

>All of those functions (stuff in curlies with '()'s after the name)
>would resolve to a php function that would be called (or maybe a file
>that would be evaluated as php, or something =). That would really clean
>up the content files, and provide really, really nice modularization.

Maybe I'm not understanding something.  That just seems backwards to 
me.  Normally, the PHP file is being evaluated and pulls formatting 
information from the template.  So, now, the template would be evaluated 
and pull code from another file?  Why?

Instead of putting those functions in the template, couldn't you just put 
template variables in the template and have the PHP code filling in the 
template perform the functions for those variables?

Or, if there is some reason I am missing to want to do this, why use 
templates at all?  Why not just use straight PHP and use <?php include 
your_function.php; ?> or <?php your_function(n); ?> in place of your 
curly-bracketed functions?

At 06:59 PM 1/13/2003 -0800, Aric Caley wrote:
>It seems to go against the general idea of templates: to separate code from
>presentation.

It seems that way to me, too.

>It would also be nice for the templates to be able to use this to tell the
>code what to do in certain cases.  For instance, what if the template has a
>4 by n grid.  But the designer wants it changed to, say 6 wide.  Currently
>you'd probably have a nested set of blocks (one for horizontal, one for
>vertical) and the code would determine how many wide to go, so the
>programmer would have to go in and change that.  With this you could just
>have something like this:
>
>{setmatrix(4)}
><!-- BEGIN matrix -->
><img src="block.gif">
><!-- END matrix -->
>
>And the code would know what to do.

... or, you could code that as a variable in a configuration file or the 
header section of your PHP file that fills in the template.  Then, the PHP 
file could determine what to do with that information.  Strangely enough, 
I've done exactly that with some of the stuff I have developed.

For example, an image gallery thumbnail page has a configuration file that 
has variables like thumbs_num_rows and thumbs_num_columns.  The designer 
can choose the numbers after the equal signs without even as much brain 
power as required to understand the {setmatrix(4)} syntax.  You can even 
put a more detailed comment right before the settings for the unusually 
obtuse designer.  The PHP code then iterates appropriately when filling in 
the template.  It works great.

Andrew Crawford
An...@Ev...

Re: [Phplib-users] template extensions

[Richard A. <rh...@ju...>]

At 21:42 -0500 13/1/03, Mike Gifford wrote:

>In reasearching this I noticed that there were a number of other
>extensions to phplib here:
>http://pathtech.mirrors.phpclasses.org/search.html?words=phplib&go_search=1

That web site says:
Please login to access.

Personally I have no intention of signing up for more spam just to see
if the classes are worth including in PHPLIB.

Feel free to download them and post them to PHPLIB's patches tracker on
SourceForge, where I (and other developers) will look at them and merge
them if I think they are nifty enough :)


>Evan's thought was that it would be really, really nice there were hooks
>for calling functions right in the templates, allowing our pages to look
>something like:

There are a couple of patches to template.inc in the Patches tracker.
I have no intention of merging either caching or functions into the
mainline template class, simply because I don't think they belong there.

The philosophy of the template class is to separate the data
presentation from the application logic. template.inc does this, and
does it very well (and with good performance into the bargain).

Once you start adding scripting to a template class, where do you stop.
You finish up re-implementing PHP within PHP. And you open up a whole
lot of security concerns which designers shouldn't need to worry about.
And you kill your performance.

I see three options for someone who wants this level of scripting:

1. drop the template class and use PHP (which is after all just a
very advanced template engine with scripting capabilities). Add a
"<? include("my_functions.inc"); ?>" to the top of the file, and
the rest of it looks like a template with <?, ?> as the template
delimiters.

2. use one of the other scriptable template engines (template.inc is
a standalone component of PHPLIB and can easily be replaced with say
smarty).

3. patch your template.inc with one of the patches from the SF tracker.
This is getting harder to do as time goes by because the patches are
becoming out of sync with the mainline template class. If you merge the
patch into the current template.inc, please repost a new diff to the
patches tracker :)

 ...R.

Re: [Phplib-users] template extensions

[Dr T. S. <ta...@sa...>]

On 13 Jan 2003, Mike Gifford wrote:

>                 <td><!-- main content -->
>                         {Article($ArticleId)}

one question

How will the $ArticleId be passed to the template?

Tarique

-- 
===================================================================
PHP Applications for E-Biz: http://www.sanisoft.com            -o)
                                                               /\\
Indian PHP User Group: http://groups.yahoo.com/group/in-phpug _\_v
===================================================================

Re: [Phplib-users] template extensions

[Aric C. <gre...@pe...>]

It seems to go against the general idea of templates: to separate code from
presentation.

That said, this seems like a really cool idea.

It could make the whole code base merely an API that is called from the
templates, thus letting the templates determine the whole structure of a
page, whereas now the code decides what template goes where, which can be
really limiting to the guy doing the site layout.

It would also be nice for the templates to be able to use this to tell the
code what to do in certain cases.  For instance, what if the template has a
4 by n grid.  But the designer wants it changed to, say 6 wide.  Currently
you'd probably have a nested set of blocks (one for horizontal, one for
vertical) and the code would determine how many wide to go, so the
programmer would have to go in and change that.  With this you could just
have something like this:

{setmatrix(4)}
<!-- BEGIN matrix -->
<img src="block.gif">
<!-- END matrix -->

And the code would know what to do.

----- Original Message -----
From: "Mike Gifford" <mi...@op...>
To: "phplib mailing list" <php...@li...>
Cc: "Evan Hughes" <eh...@ju...>
Sent: Monday, January 13, 2003 6:42 PM
Subject: [Phplib-users] template extensions


> Hello,
>
> A colleague of mine asked me about extending phplib templates so that it
> would be possible to pass functions and variables back through the
> template variables.
>
> I didn't think that this was possible with the current version of the
> code, but wanted to bring forward the idea here to see if someone had
> already done this and if there was interest within the community.
>
> In reasearching this I noticed that there were a number of other
> extensions to phplib here:
>
http://pathtech.mirrors.phpclasses.org/search.html?words=phplib&go_search=1
>
> And I wanted to see if there was any movement to build these extensions
> into the phplib code base.
>
>
> Evan's thought was that it would be really, really nice there were hooks
> for calling functions right in the templates, allowing our pages to look
> something like:
>
> article.tpl:
> -----------------
> {header}
> <body>
> <table>
>         <tr>
>                 <td><!-- leftbar-->
>                         {Poll()}<br>
>                         {MailingListSignup()}<br>
>                         {RSSFeeds()}<br>
>                 </td>
>                 <td><!-- main content -->
>                         {Article($ArticleId)}
>                 </td>
>                 <td><!-- Right bar -->
> ...
> -----------------
>
> All of those functions (stuff in curlies with '()'s after the name)
> would resolve to a php function that would be called (or maybe a file
> that would be evaluated as php, or something =). That would really clean
> up the content files, and provide really, really nice modularization.
>
> An instance that occured to me is that it seems silly to have have
> multiple template variables for something like {BANNER1} ... (BANNERn),
> when you could have a {BANNER(1)} tag to pass along that info to a
> function.
>
> Mike
> --
> Mike Gifford <mi...@op...>
> OpenConcept Consulting http://www.openconcept.ca
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

[Phplib-users] template extensions

[Mike G. <mi...@op...>]

Hello,

A colleague of mine asked me about extending phplib templates so that it
would be possible to pass functions and variables back through the
template variables.

I didn't think that this was possible with the current version of the
code, but wanted to bring forward the idea here to see if someone had
already done this and if there was interest within the community.

In reasearching this I noticed that there were a number of other
extensions to phplib here:
http://pathtech.mirrors.phpclasses.org/search.html?words=phplib&go_search=1

And I wanted to see if there was any movement to build these extensions
into the phplib code base.


Evan's thought was that it would be really, really nice there were hooks
for calling functions right in the templates, allowing our pages to look
something like:

article.tpl:
-----------------
{header}
<body>
<table>
        <tr>
                <td><!-- leftbar-->
                        {Poll()}<br>
                        {MailingListSignup()}<br>
                        {RSSFeeds()}<br>
                </td>
                <td><!-- main content -->
                        {Article($ArticleId)}
                </td>
                <td><!-- Right bar -->
...
-----------------

All of those functions (stuff in curlies with '()'s after the name)
would resolve to a php function that would be called (or maybe a file
that would be evaluated as php, or something =). That would really clean
up the content files, and provide really, really nice modularization. 

An instance that occured to me is that it seems silly to have have
multiple template variables for something like {BANNER1} ... (BANNERn),
when you could have a {BANNER(1)} tag to pass along that info to a
function.

Mike
-- 
Mike Gifford <mi...@op...>
OpenConcept Consulting http://www.openconcept.ca

RE: [Phplib-users] Is it safe to use PHPLIB from CVS?

[Layne W. <la...@if...>]

> Hello, I've been using PHPLIB 7.2d for a long time. I think
> It's time to test the new version. Is it safe to use the CVS
> version?.

Yes. I currently have the CVS version running on my production servers. When
changes are made to CVS I update to my development machine and test, then
the testing server and test, and finally the production servers after all
sites are confirmed to be in working order.

I am NOT recommending that you or anyone else do this, I merely state that I
am comfortable doing so, at this time. If you have any doubts about using
the CVS version, don't use it.

> If so, which branch is more bug free, phplib-stable
> or php-lib?. Which one is older/newer than the packaged
> phplib-7.4-pre1?. It's the best choice to install
> phplib-7.4-pre1? What is your advice to install a new version?

If you use CVS, use php-lib-stable - that is what the releases are built
from. The php-lib package is intended for trying out new concepts before
they were finalized/tested/integrated.

> Also, I have a very very customized localconf.inc including an
> alternative login method (calling external auth commands and
> more) and a permission system based on access control lists
> (ACL) for each user. Should it be much pain to adapt it to the
> newer versions? (all my pages are based on it)

The project leaders have been very clear that they are not changing library
APIs in the 7.x versions. You should be able to upgrade without problems.

> BTW, If you think it could be useful for you, I can give you
> my code for ACL implementation and give it a try.

How about posting it to the Patches tracker?

Layne Weathers
Ifworld Inc.

[Phplib-users] Is it safe to use PHPLIB from CVS?

[Mario J. M. <ma...@ju...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello, I've been using PHPLIB 7.2d for a long time. I think It's time to=20
test the new version. Is it safe to use the CVS version?. If so, which=20
branch is more bug free, phplib-stable or php-lib?. Which one is=20
older/newer than the packaged phplib-7.4-pre1?. It's the best choice to=20
install phplib-7.4-pre1?=20

What is your advice to install a new version? Also, I have a very very=20
customized localconf.inc including an alternative login method (calling=20
external auth commands and more) and a permission system based on=20
access control lists (ACL) for each user. Should it be much pain to=20
adapt it to the newer versions? (all my pages are based on it)

BTW, If you think it could be useful for you, I can give you my code for=20
ACL implementation and give it a try.

Thanks in advance.

=2D --=20
=2D -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-
Mario J. Barch=E9in Molina. Granada (Spain)
mario AT/EN judas.2y.net
=2D -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Ht/r1Cm7FLLA0lcRAkuQAJ4xJokh03zS034xUjAxS6mBDveNYACeL73Y
CDO68iCi9Ja7NZDBTuBJns4=3D
=3DGoyF
=2D----END PGP SIGNATURE-----

Re: [Phplib-users] registering big array ; session.inc error (during thaw)

[Joe J. <joe...@ya...>]

What I wrote at the end of my original email turned out to work.
Using ct_split_sql.inc instead of ct_sql.inc solved this problem.
It splits up any variables stored into chunks of predetermined size,
so that you don't overflow the available space in that field of you
db.

Regards,
Joe

--- Joe Janitor <joe...@ya...> wrote:
> I am using phplib 7.2d (although trying 7.4 didn't seem to make a difference upon
> first glance).
> 
> I register a rather large array variable:
>   $sess->register("resultArray");
> 
> and then on a subsequent page I try to use it, session.inc I get
> 
> Parse error: parse error in /var/httpd/phplib-7.2d/php/session.inc(329) :
> eval()'d code on line 56
> 
> relevant code from session.inc:
> 
> 51:  function thaw() {
> 52:    $this->get_lock();
> 53:
> 54:    $vals = $this->that->ac_get_value($this->id, $this->name);
> 55:
> 56:    eval(sprintf(";%s",$vals));
> 57:  }
> 
> I saw some references to this problem
> in the old archives at MARC:
> 
> http://marc.theaimsgroup.com/?l=phplib&m=96237204126796&w=2
> (specifically this guy says: "If I base64_decode($str) the value 
> manually, I see that the declaration of the array is simply cut 
> off half the way, so ac_get_value can´t do his job...")\
> 
> Also, this thread describes a problem storing large variables
> (not necessarily arrays):
> http://marc.theaimsgroup.com/?l=phplib&m=98599555416912&w=2
> and someone suggests that the problem can be solved by using
> ct_split_sql.inc. This seems a possible workaround, but I haven't
> yet tested. 
> 
> Is there any current solution to the problem of registering
> huge variables with phplib (using the default installation?)
> 
> Thanks,
> Joe
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com