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

Re: [Phplib-users] backtrace logout

[Nathaniel P. <np...@te...>]

PHPlib, by default, automatically logs out anybody who's been idle for more
than a specified number of minutes. You can tune this parameter in your
local.inc file (look for a $lifetime setting in your Auth class). If users
complain that they get logged out too often, set this to something higher.
In my experience (for non-critical applications) 30 minutes provides about
the right balance. If you need your app to be more secure, you may want to
keep it at a fairly low setting.

If that's not your problem, I don't know what to tell you. A 'random' logout
could be caused by a number of different problems (like a user not accepting
cookies with the session fallback mode not implemented correctly), most of
which are somewhat difficult to track, unless you can recreate the user's
movements through the site.

As for the other question, in order to backtrace any automatic logout, you'd
have to alter or extend auth.inc (and possibly parts of local.inc, depending
on your configuration). If I were implementing it, I'd look at extending the
unauth() and logout() methods to add some logging/reporting capabilities
there, possibly incliding a dump of the cookies and the $auth->auth array...
whatever info you feel would be important.

Hope this helps.

_________________________________
Nathaniel Price <np...@te...>
Webmaster

----- Original Message ----- 
From: "Daniel Bondurant" <bo...@io...>
To: <php...@li...>
Sent: Wednesday, May 07, 2003 11:01 AM
Subject: [Phplib-users] backtrace logout


> I am getting users complain of random logouts.
> I've been trying to track down a pattern to them, but have been
unsucessfull.
>
> Has anyone extended the classes and put to put in a backtrace for logouts?
Or have a good idea on how to impliment a small trivial one?  An email from
the server with __LINE__ and __FILE__ should be good enough.

[Phplib-users] backtrace logout

[Daniel B. <bo...@io...>]

I am getting users complain of random logouts.
I've been trying to track down a pattern to them, but have been =
unsucessfull.

Has anyone extended the classes and put to put in a backtrace for =
logouts?  Or have a good idea on how to impliment a small trivial one?  =
An email from the server with __LINE__ and __FILE__ should be good =
enough.

thanks
- daniel

Re: [Phplib-users] Wierd problems with fallback mode in Session

[Nathaniel P. <np...@te...>]

----- Original Message ----- 
From: "Kevin Fredrick" <fre...@ip...>
To: <php...@li...>
Sent: Tuesday, May 06, 2003 4:15 PM
Subject: Re: [Phplib-users] Wierd problems with fallback mode inSession


>
> See: http://www.php.net/manual/en/reserved.variables.php
>
> >
> > This is a 'superglobal', or automatic global, variable. This simply
> means
> > that it is available in all scopes throughout a script. You don't
> need to do
> > a global $_SERVER; to access it within functions or methods, as you
> do
> > with $HTTP_SERVER_VARS.
> >
> > $HTTP_SERVER_VARS contains the same initial information, but is not
> an
> > autoglobal. (Note that $HTTP_SERVER_VARS and $_SERVER are different
> > variables and that PHP handles them as such)
> >
>
> This might be a bug, or a "global $HTTP_SERVER_VARS" is missing from
> the function.

Well, it must be a bug, since session.inc always has the "global
$HTTP_SERVER_VARS" statement in its functions. In any case, I tested for
$HTTP_SERVER_VARS in the global variable space, and it still was empty. I
did find, however, that PHP3 (on my server, anyway) registered the SERVER
variables as normal global variables, like $HTTP_HOST. So I wrote a little
helper function that I call from prepend.php3 to get it working again, and
it seems to work as expected. Here it is, for those of you that are curious
(this should work for PHP4 as well, if you're having problems there):

function import_server_vars() {
 global $HTTP_SERVER_VARS;
 $keys = array("QUERY_STRING", "PHP_SELF", "HTTPS", "HTTP_HOST");

 while (list(,$key) = each($keys)) {
  if (!$HTTP_SERVER_VARS[$key]) {
   #get it from the server autoglobal first
   if (!$HTTP_SERVER_VARS[$key] = $_SERVER[$key]) {
    $HTTP_SERVER_VARS[$key] = $GLOBALS[$key];
   }
  }
 }
}

_________________________________
Nathaniel Price <np...@te...>
Webmaster

Re: [Phplib-users] Template reverse transformation

[Tim M. <tw...@al...>]

Hello Nathan,

Thanks for your response.

I had considered just putting comments at the beginning and end of
templates as you suggested - that may still be an option.  It would seem
that is an easy thing to automate, though, and could provide a great
deal of benefit.  Having to put comments in each template is a bit of an
inconvenience and opens the door for inconsistency problems if you ever
want to rename your templates, whereas an automated solution would
require no additional effort and would always be up-to-date in the
markers that it prints.

Let me offer an analogy to demonstrate why you would want this.  Say you
have a C program that crashes when you run it.  How do you fix it?  You
recompile with "gcc -g" and re-run the program in a debugger.  What if
there was no debug mode?  Well, you could put printf statements at the
start and end of every function call so that you know where it crashes,
but that is substantially less convenient and not necessarily as
accurate.

I should also clarify that it's not essential that the whole process be
automated - the Dreamweaver scenario was more of an example than a plan
for how I will use this in practice (I still use Emacs when I edit
HTML).  While it would be nice to have a system which automatically
modifies templates based upon modifications to output from those
templates, I think it might be a sufficient first step to have a tool
which takes as input the original HTML page (which was the result of
combining templates) and the modified HTML page (edited in Dreamweaver,
Emacs, or whatever) and prints out a list of what templates you need to
modify and what the diffs are between the original output and the
modified output for each template (ala Gtkdiff).

When you say that the goal of the PHPLIB template system is to do one
thing well, is that one thing forward template transformations?  I guess
what I'm looking for would fall under the umbrella of a template
management which would cover both forward and reverse transformations
(or at least aid in reverse transformations).

Thanks,
- Tim Macinta



"nathan r. hruby" wrote:
> 
> On Tue, 6 May 2003, Tim Macinta wrote:
> 
> >
> > I consider ease of use by designers to be extremely important in a
> > templating system.  Ideally, this would mean that there is seamless
> > WYSIWYG support so that designers who use things like Dreamweaver can
> > edit a *single* HTML file with *real* data on it and have the changes
> > reflected in the templates that were used to build that page.  I know
> > there is a temptation to ask what's so hard about editing Template1,
> > Template2, etc by hand, but for designers that only know Dreamweaver and
> > don't know HTML, it's a moot point - regardless of how hard it is, it's
> > not an option in a lot of cases.
> >
> 
> Coddling lazy, stupid or incompetent designers doesn't make them better
> and only makes matters worse.  That said, I'm all for making things simple
> for everyone and not making people have to jump through hoops just to get
> their job done.  There is a fine line though, and it requires both side to
> give a little.  If your designers can't use HTML fragments at all, then
> they need to try just a little bit harder at what they do, or you need to
> try a little bit harder at teaching them what they need to know in order
> to be comfortable.  I personally think you're trying to bend over
> backwards for something that really isn't worth the time, energy or effort.
> 
> Additional personal rant:  Dreamweaver blows big fat chunks and lowers the
> IQ of it's users by 10 points every time they upgrade :-P
> 
> >
> > Below is how this could be achieved in a system that would be
> > implemented from scratch.  The basic gist is that you can put the
> > templating system in "debug" mode, which would then result in pages
> > being generated with <span> tags wrapping template fragments and
> > variables so as to identify them later.  The designer would edit the
> > single, exported page (which contains real data instead of variable
> > names) in a WYSWIG editor and then upload the modified page to the
> > template system.  The template system would then use the <span> tags to
> > figure out which templates created which pieces of the page and then
> > modify those templates accordingly.
> >
> 
> Why?  You're not talking about breaking apart a single file into discrete
> templates, you're talking about taking discreet templates, gluing them
> into a valid page, editing them, and then taking them apart again.
> Different things, which is a subtle difference.  If you have discrete
> teplates already in a phplib tempalte system, just add comment lines at
> the top and bottom of each template 'nugget' indicating what it is, then
> in post processing, jsut rip the edited page back into components with
> miltiline regexps and process those.  You can do that outside the phplib
> templating engine.
> 
> > That's the Reader's Digest summary - see below for *much* more detail.
> > My question again is whether something similar could be built into
> > PHPLIB and what this would take?  I know this would be extremely
> > difficult to make work correctly with probably the majority of PHPLIB's
> > features, but I'd still be happy even if getting a reverse
> > transformation feature necessitated that I use a certain sub-set of
> > PHPLIB features in my templates.
> >
> 
> phplib's tempalte.inc does not meet most of the needs you cite, nor do I
> think it should out of the box.  It's goal is to do one thing well and
> fast, which it does.  If you need additional features it's up to you to
> implement them for your own specific needs using tempalte.inc as a
> reference or as the core for your projects.
> 
> [snip thesis]
> 
> -n
> --
> ------
> nathan hruby
> na...@ds...
> ------
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

[Phplib-users] Re: [Phplib-core] [LIST ADMIN] This list is now member_posting_only

[Chris J. <ch...@ch...>]

On Tue, May 06, 2003 at 03:33:51PM -0700, nathan r. hruby wrote:
> 
> Hi,
> 
> In light of the recent spam issues passing to the list, the list has been
> changed to member_posting_only, which requires posters to be list members.

Thank you!

-- 
    ..chris

Re: [Phplib-users] Template reverse transformation

[Tim M. <tw...@al...>]

Hi Tarique,

Thanks for your response.

I should clarify my original post to say that Dreamweaver was just an
example of one editor that might be used.  I actually use Emacs myself. 
So, the design goals for what I need would preclude a template system
that is editor specific.  Thanks for filling me in on what's available,
though.

- Tim



Dr Tarique Sani wrote:
> 
> On Tue, 6 May 2003, Tim Macinta wrote:
> 
> > The feature that I want is this:
> >
> >                                 --> Template1
> >                                /
> >   HTML --> Reverse-Transform -----> Template2
> >                                \
> >                                 --> Template3
> >
> >
> > Before anybody tells me that this is insanely difficult, I will say that
> 
> I did not read thru your insanely long message BUT here is what I would
> suggest
> 
> 1) Dreamweaver MX offers a good templating system with nesting, repeating
> blocks and conditional blocks.
> 
> 2) With help of some prefilters these templates can be directly used by
> SMARTY
> 
> Pros: Offers a 100% WYSIWYG environment for templates
> 
> Cons: If a parent template is changed then it automatically updates all
> the child templates - Implying that for the change to be applicable you
> have to upload the parent as well as children to your site.
> 
> If you find SMARTY to complex to use then you can use the class
> phplib2smarty which is a drop-in replacement for phplib template class to
> use smarty.
> 
> Also there is a downloadable PDF of Dreamweaver MX template chapter on one
> of the book sites
> 
> HTH
> 
> Tarique
> 
> --
> ===================================================================
> PHP Applications for E-Biz: http://www.sanisoft.com            -o)
>                                                                /\\
> Indian PHP User Group: http://groups.yahoo.com/group/in-phpug _\_v
> ===================================================================
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] Template reverse transformation

[nathan r. h. <na...@ds...>]

On Tue, 6 May 2003, Tim Macinta wrote:

>
> I consider ease of use by designers to be extremely important in a
> templating system.  Ideally, this would mean that there is seamless
> WYSIWYG support so that designers who use things like Dreamweaver can
> edit a *single* HTML file with *real* data on it and have the changes
> reflected in the templates that were used to build that page.  I know
> there is a temptation to ask what's so hard about editing Template1,
> Template2, etc by hand, but for designers that only know Dreamweaver and
> don't know HTML, it's a moot point - regardless of how hard it is, it's
> not an option in a lot of cases.
>

Coddling lazy, stupid or incompetent designers doesn't make them better
and only makes matters worse.  That said, I'm all for making things simple
for everyone and not making people have to jump through hoops just to get
their job done.  There is a fine line though, and it requires both side to
give a little.  If your designers can't use HTML fragments at all, then
they need to try just a little bit harder at what they do, or you need to
try a little bit harder at teaching them what they need to know in order
to be comfortable.  I personally think you're trying to bend over
backwards for something that really isn't worth the time, energy or effort.

Additional personal rant:  Dreamweaver blows big fat chunks and lowers the
IQ of it's users by 10 points every time they upgrade :-P

>
> Below is how this could be achieved in a system that would be
> implemented from scratch.  The basic gist is that you can put the
> templating system in "debug" mode, which would then result in pages
> being generated with <span> tags wrapping template fragments and
> variables so as to identify them later.  The designer would edit the
> single, exported page (which contains real data instead of variable
> names) in a WYSWIG editor and then upload the modified page to the
> template system.  The template system would then use the <span> tags to
> figure out which templates created which pieces of the page and then
> modify those templates accordingly.
>

Why?  You're not talking about breaking apart a single file into discrete
templates, you're talking about taking discreet templates, gluing them
into a valid page, editing them, and then taking them apart again.
Different things, which is a subtle difference.  If you have discrete
teplates already in a phplib tempalte system, just add comment lines at
the top and bottom of each template 'nugget' indicating what it is, then
in post processing, jsut rip the edited page back into components with
miltiline regexps and process those.  You can do that outside the phplib
templating engine.

> That's the Reader's Digest summary - see below for *much* more detail.
> My question again is whether something similar could be built into
> PHPLIB and what this would take?  I know this would be extremely
> difficult to make work correctly with probably the majority of PHPLIB's
> features, but I'd still be happy even if getting a reverse
> transformation feature necessitated that I use a certain sub-set of
> PHPLIB features in my templates.
>

phplib's tempalte.inc does not meet most of the needs you cite, nor do I
think it should out of the box.  It's goal is to do one thing well and
fast, which it does.  If you need additional features it's up to you to
implement them for your own specific needs using tempalte.inc as a
reference or as the core for your projects.

[snip thesis]

-n
-- 
------
nathan hruby
na...@ds...
------

Re: [Phplib-users] Template reverse transformation

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

On Tue, 6 May 2003, Tim Macinta wrote:

> The feature that I want is this:
> 
>                                 --> Template1
>                                /
>   HTML --> Reverse-Transform -----> Template2
>                                \
>                                 --> Template3
> 
> 
> Before anybody tells me that this is insanely difficult, I will say that

I did not read thru your insanely long message BUT here is what I would
suggest

1) Dreamweaver MX offers a good templating system with nesting, repeating
blocks and conditional blocks. 

2) With help of some prefilters these templates can be directly used by
SMARTY

Pros: Offers a 100% WYSIWYG environment for templates

Cons: If a parent template is changed then it automatically updates all
the child templates - Implying that for the change to be applicable you
have to upload the parent as well as children to your site.

If you find SMARTY to complex to use then you can use the class
phplib2smarty which is a drop-in replacement for phplib template class to
use smarty.

Also there is a downloadable PDF of Dreamweaver MX template chapter on one
of the book sites

HTH

Tarique



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

[Phplib-users] Template reverse transformation

[Tim M. <tw...@al...>]

Hello,

I've been charged with either finding or making a template system for a
large-ish website that uses PHP and I have a question about a feature
that doesn't appear to be in PHPLIB or any other template system that I
know of.  I'd like to know if anybody could give me some feedback on 1)
what it would take to retro-fit PHPLIB with this feature;  2) whether
somebody has suggestions that would achieve the same goals and would be
simpler to retro-fit PHPLIB for;  and/or 3) whether anybody has ever
seen such a feature before in a template system?

Typically, a templating system works like this:

  Template1 ---
               \
  Template2 ------> Transform --> HTML
               /
  Template3 ---


The feature that I want is this:

                                --> Template1
                               /
  HTML --> Reverse-Transform -----> Template2
                               \
                                --> Template3


Before anybody tells me that this is insanely difficult, I will say that
the "how" is coming below and seeing this idea (which wasn't my idea
originally, incidentally) might make it worth your while you read
through this very long message.  First, the why...

I consider ease of use by designers to be extremely important in a
templating system.  Ideally, this would mean that there is seamless
WYSIWYG support so that designers who use things like Dreamweaver can
edit a *single* HTML file with *real* data on it and have the changes
reflected in the templates that were used to build that page.  I know
there is a temptation to ask what's so hard about editing Template1,
Template2, etc by hand, but for designers that only know Dreamweaver and
don't know HTML, it's a moot point - regardless of how hard it is, it's
not an option in a lot of cases.

I a huge fan of DOM manipulation templating solutions like XMLC and
HTML_tree for this reason.  They allow designers to work with valid HTML
and realistic sample data which generates a fully realistic mockup. 
They don't, however, support a reverse transformation so there is still
a degree of having to figure out which template to edit to effect which
change.

Below is how this could be achieved in a system that would be
implemented from scratch.  The basic gist is that you can put the
templating system in "debug" mode, which would then result in pages
being generated with <span> tags wrapping template fragments and
variables so as to identify them later.  The designer would edit the
single, exported page (which contains real data instead of variable
names) in a WYSWIG editor and then upload the modified page to the
template system.  The template system would then use the <span> tags to
figure out which templates created which pieces of the page and then
modify those templates accordingly.

That's the Reader's Digest summary - see below for *much* more detail. 
My question again is whether something similar could be built into
PHPLIB and what this would take?  I know this would be extremely
difficult to make work correctly with probably the majority of PHPLIB's
features, but I'd still be happy even if getting a reverse
transformation feature necessitated that I use a certain sub-set of
PHPLIB features in my templates.

Enabling the reverse transformation and importation by utilizing <span>
tags was originally Benjamin 'Quincy' Cabell V's idea, by the way, to
give credit where credit is due.  His summary of how he would design
such a system from scratch is below.

Thanks,
- Tim Macinta


From: Quincy <Tem...@be...>
-----------------------------------

The features which I believe are critical to a good templating system
are the following:

- Multi-language
- Multi-style
- Caching
- Variable AND constant substitution
- Easy variable insertion (in template, no coding, per se)
- Significant separation of html and code
- Edit Once, Edit Everywhere

In my opinion all of the templating systems I have seen fail on these
last two points.  On the issue of separating HTML and code, they succeed
only to the degree that they eradicate HTML from inside PHP files.  They
separate HTML from code by spreading one page's HTML (final rendered
page the user will see) into dozens of template pieces which are then
merged together in a way that makes editing the GUI at a later time
difficult because of the need to a) read the code (or some a document
about the code/templates) to understand which template contains which
"piece" of the layout and b) modify each individual template (of dozens
or more) in a coordinated fashion to modify the design.  These two
failures/weaknesses make templating systems much less effective than
they could be.

But, before talking about a solution to that, let me first cover the
other issues.

Multi-language and mult-style.  This is really one feature, but looks
like two.  The idea is that you have parallel template sets for style
and within those parallel template sets for language.  So, each template
has a name, a style, and a language setting.  To find the template you
would look in the database for the appropriate template of the
appropriate style, then the appropriate language.  If you fail to find
the template of the appropriate language you fall back to the default
style with the appropriate language.  If you fail to find that you fall
back to the appropriate style with the default langauge.  If you fail to
find that you fall back to the default style and default language (which
will always exist).  The setting of the style/language is optional
(otherwise default), and the setting of it could occur in the
initializer to the template class, or at any point, or specifically in a
template inclusion call.

Caching is somewhat obvious, somewhat not.  The ability to store the
processed template (post variable/constant substitution) for X seconds
and have this get used instead of "creating" a new one.  The bit that's
a bit awkward is that you are not caching to prevent the variable
substitution, which is pretty simple and efficient, you are caching to
prevent the PHP that would get the data ready to be laid out in a
template.  So, the actual PHP code (business logic) would essentially
check with the template cache manager code to see if the content is in
cache (according to hash info and the rules of that template) and if it
is it returns it and bypasses the PHP code which would have done the SQL
calls/computations/etc. to create whatever data/templates the template
might have required.  It's the generic object cache I had Tim Macinta
build, in the setting of a template manager.

Variable and constant substitution.  The variable substitution part is
just that.  It's the thing every template system does most
fundamentally.  Replace a marker in the template with the value of some
variable.  The "constant" substitution is a bit of a misnomer.  It's
actually a style/language-specific constant substitution.  Meaning that
you could define page_bg_color to be #0000cc in the "Cool Blue" style,
and #cc0000 in the "Hot Red" style.  And, you could substitute other
things such as key strings on a language-by-language basis.  So, the
constants are NOT constants in the true PHP sense (and they are not
defined as constants in the PHP code), but items which are small-ish
fragments of text you want to put in your pages, which will not change
based on page execution, and which get placed into templates. (This
variable/constant is functionally identical to vBulletin's template
system.)

Easy variable insertion is just an awkward way of saying that when
you're editing a template it shouldn't be painful, requiring code-like
things, require many more keystrokes than simply referring to the
variable/constant you're substituting by a name.  Most systems do this
reasonably well.

Back to the thorny and significant problem of separation of html and
code.  The other features are relatively common and relatively easy to
achieve (caching is a bit complicated, but it's a pretty "well
understood" problem).  This item, though, is a a bit of a bitch.  And I
don't think it has to be, and I think I know a way out of this maze.
Personally I've found templating systems hideous to use.  Again, you
just can't edit things easily when you use them.  You have to trace back
the building of the page, see all the templates used, discern from their
names or their order of execution what they do, edit the one or many
templates you need to (and the numbers can be truly staggering, see
vBulletin with its dozens and dozens of templates for one viewed page),
then hope to god you didn't miss a closing tag and have to journey into
a nightmarish world to find which template has one too many or too few
tags.  On some level, this "cure" becomes worse than the original
"disease".  So, what to do?

I'll present part of a possible solution.  It's one I worked on a bit a
year or two ago, and started thinking again a bit when I was asking Tim
Macinta to look into templating systems for our site.  From his initial
research it seems the state of templating systems still hadn't improved
(enough) to meet what I perceived as my/our needs.  I'll present a
possible solution.  It's one I worked on a bit a year or two ago, and
started thinking about again after the renewed look at templating
systems.  If anyone reads this and responds, "Oh, I've seen that before,
it's in Foo Bar Inc.'s Fubaramatic Templating System."  please forgive
me and let me know where it's to be found!

The goal is simply this:  

Let's say I decide to clean up the look of our new "search system".  I
open up a browser to my site, load up the search form, execute a search,
get a bunch of results, now that I'm looking at a page on the site that
contains all the content areas/items I want to edit I then I add a
"&templatex=1" to the URL (or set a cookie named templatex), the page
reloads, looks exactly like it did a moment ago (but has invisible
differences in hidden meta markup), I save the page with IE.  This is a
"real" page, it has real results on it, not bogus sample data, but real
results I got from the real page.  I open up Macromedia's Dreamweaver,
change the order of the cells in the result table, change the background
colors in the cells from alternating light and dark grey to alternating
light blue and light red, edit some copyright text, replace a few
graphics, and save.  I go to the "TemplateX" management page, go the
"import" form, browse to and upload the HTML page I just edited (just
the HTML file, no graphics).  I hit "submit".  And the system
automagically makes the required changes to ALL the required templates
and constants (the style/language ones).  No more trying to understand
how the templates fit together, or which has what, no more editing
multiple template files.

Now...  I think it's possible to achieve all of that goal, relatively
easily, within certain limits.  Here is some info on how such a system
could be achieved, and some of the limitations.

Achieving this goal goes a little like this.  Every substitution (from a
variable or constant) is wrapped in a <span></span> wrapper.  The
wrapper includes addition info in attributes about what did the
substitution (variable or constant, and the variable name).  Each
template is wrapped in <span> telling with attributes which template it
is, and what language and style it is.  And, for tag attributes, for
every "real" attribute where a substitution occurred, a paired fake
attribute exists which tells what variable/constant did the substitution
(could also do all this in one fake attribute per tag).  There's a bit
more to how this would work, but these are the key points.

Now for some limitations.  The templates cannot be "anything"; they must
be HTML fragments (text which can contain HTML tags, but no <table (with
no closing>) and attributes cannot be "partially" replaced by variables
(such as bgcolor=#cc$foo), an attribute may have a value of a variable,
or a constant (and perhaps even another template (which in turn could be
created by part of a variable) but maybe not I haven't thought this
out).  But, a tag could not be like <table $border_attribute>, though it
could have <table border=$border_width>.  If a template is included
multiple times only modifications to the first instance (presumably)
would be processed (the others would cause no harm, but the changes
there would be ignored, and would in fact be wrapped with span tags
indicating the data there was just sample data, not related to a
template).  The page you edit contains the substituted variables, so it
renders as a real page, with real data.  As these items are wrapped in
<span> tags with vital identifiers in the tags, the designer cannot
corrupt the wrapping when the move/alter the "text"
(<font><span>foo</span></font> would be very different than
<span><font>foo</font></span>).  Similarly, as the HTML tags may contain
"false" attributes used to identify tag attribute substitutions, those
"false" attributes must also be unaltered by the designer.

The parser would read the document, identify the templates involved for
each region, reconstructing the variables/constants that were
substituted, and re-create the various template files (and alter
constants that had changed).

So, that's it.  It should work, and I believe it would be a great
advancement over anything I've seen/used.

We could start with some core features, initially supporting no
"constants" and no tag attribute substitution.  The parsing of the
document I do not believe should be too difficult, as the logic would be
pretty simple and the <span> tags we're using would be assumed to be
very exactly defined and should thus be easy to parse/locate via regex.
The true benefit of this "Edit Once, Edit Everywhere" design may not be
perfect.  Dreamweaver or other applications may insist on putting <font>
tags on the inside of a <span> when you format text, and so true WYSIWYG
may not come.  We may find we need to constuct our templates differently
than we might with other template systems, such as defining a <table>
header twice (with different attributes) rather than do variable
substitutions dynamically to add attributes in one template on the fly.
And so on.  Nonetheless, this system would still be better and easier to
use than any current templating system out there.  Assuming that it is
this major step forward in templating systems we could/should release it
GPL or LGPL to the open source community and allow others to develop it
further, which is likely to occur.



Import/Export Tool
------------------
In addition to the system mentioned above, where a designer can make
changes to one HTML file then automagically update all the appropriate
templates based on the changes made in that one file, another useful
method for doing large volumes of template changes, an import/export
tool would be useful.  While the templates are stored in the database,
there would be great benefit in having a tool to import/export template
files to/from a file system for ease in making large scale template
changes/edits.  In this situation, I would type in "templatex --export
/home/quincy" and it creates a directory structure roughly as I outlined
(with langauge directories, and style sub-directories), you can then
edit the files with Dreamweaver/TextPad32/Homesite/Emacs/etc. and then
run "templatex --import /home/quincy" and it imports them, creating
template entries for 'new' files and over-writing entries for edited
ones.  My primary reason for believing this feature is needed is because
of my experience in doing lots of vBulletin changes, and feeling pretty
limited/frustrated by needing to do all edits within their limited
template editing system, instead of being able to use whatever tools I
like, leveraging their power, for syntax highlighting, HTML
preview/editing, doing global search and replaces, global finds, etc.  


Automating Template Determination/Fetching
------------------------------------------
There are many lessons we can learn from experience with vBulletin and
seeing how they have implemented their system.  Within each vBulletin
page they call a function which pre-fetches the templates that the page
expects it will need, saving on DB calls; and with my hack that caches
fetched templates to the filesystem bypassing the DB altogether.  We
should (probably) try to create a system which automagically knows which
templates will be required for which scripts, based on previous runs of
the script (it would "learn"), as well as being able to manually control
which templates are pre-fetched.  Of course we can start with manually
setting it, and later do it automagically.  I just mention this feature
because with vB it gets very taxing to manually maintain the list, when
sometimes you've got 20 or 30 templates in the list, and you need to
remember which you've added/removed/etc.  And if you forget a couple
then of course it needs to separately fetch them as needed, which is
(probably) less efficient than the overhead of automagically fetching
too many.  


Parsing of Updated HTML File
----------------------------
The reverse transformation which occurs when the parser is asked to
process a final document that you modified (with a text editor or
Dreamweaver) back into the mods to the individual templates 
is easy because it has been purposely "dumbed down" with only one
"branch" to follow, ever.  That branch is the one that was used in the
actual page generation that you edit.  Originally my goal when I started
thinking about this last year was to try to handle all the
cases/branches when you edit one page, but it's clearly a nightmare and
forces the templates or the editing of them to contain "code"
(code-suggestive markups, at least).  So, I think the solution is to
bypass the issue entirely, and go with the simlpe one branch approach.
So, if I want to change the entire look of the search page, that does
mean I need to run through all of the possible variations of the search
page (showing 0 results, showing X results, in this mode, that mode,
etc.).  And I don't think that's a bad thing, actually.  Every time you
make a change that will show up in the other variations, it will show up
there when you check them, so it's not that you'll be doing extra work.
Now, the one danger is of course that you could forget about one of the
application's variations.  But, I would say that risk is probably
acceptable, and with most applications, the sorts of changes you're
doing are few enough that it's unlikely you'd foget, and if the change
is big enough, you'd better be sure you do know all the variations.


Flexibility in Design through Proper Programming Decisions
----------------------------------------------------------
The page designer's/editor's flexibility is dictated by the coding
decisions the programmer makes.  It is the programmer's responsibility
to build in this flexibility by breaking the pages up into appropriate
template fragments.  The template manager has two primary template
processing functions, build_fragment() and show_fragment().
Build_fragment() processes the fragment but does not echo/print it,
instead it places it in a 'variable' in the template manager which will
then use that as a variable for substitution in other templates.
Show_fragment() is identical to build_fragment() except that it outputs
(echos/prints) the results of the template processing.  So, here is one
example of how you might build a form processing page:

  build_fragment("header");
  if (count($errors) == 0) {
     build_fragment("abc_success");
  } else {
     build_fragment("abc_errors");
  }
  build_fragment("abc_form");
  
  build_document("abc_form_body");

  build_fragment("footer");

  show_fragment("standard_document");

In this design, abc_errors, abc_success, and abc_form are "positioned"
by abc_form_body.  Header, footer, and abc_form_body are then positioned
by standard_document.

So, the designer could alter all these things, assuming of course that
the code is properly designed with this in mind, and (a very important
limitation) that no template changes its relationship with its parent;
technically they may not absolutely need to observe that but it would be
somewhat at their peril not to.  In the above example, by editing the
output of a succesful form submission, they could move the placement of
the abc_success fragment directly into the standard_document and it
would "work" (that is, the rendering would all layout okay, since the
template abc_success is still being evaluated in the same place in the
code, it's just being told to appear in standard_document NOT in
abc_form_body.  But, every other page that uses standard_document will
attempt to do the same (this may not cause problems since the variable
that abc_success fills would NOT be set for other pages, and thus
nothing would be output).  But, the point is, it's a corruption of the
intended structure, and such things should be strongly guarded against
because they will cause problems.

Just to repeat for clarity, the idea of build_fragment is to build
variables like this from templates, as opposed to just setting template
variables from code (execution).  One point to note is that in the above
example I don't make clear what the variable name should be for the
storage of the built template.  The logic should probably be that it can
be "assumed" to be the template name, OR, it can be set, specifically.
In the above example, the abc_form_body should *NOT* use the default
name of the template as the variable name for the template manager,
because the standard_document would be using a generic name like
'body_variable' or something as a placeholder for the body, and that is
what should be holding the abc_form_body.  So, the call to build
fragment for abc_form_body would need to specify this.  In this way each
template has a clearly defined set of inputs.



How the Meta Markup Exists in the Document to be Edited
-------------------------------------------------------
The design of span tags used in this system should be something like:

<span id="template:en|default|standard_document">
 <span id="variable_from_template:en|default|header">Top of the
page</span>  <span id="variable:body_variable">
   <span
id="variable_from_template:default|default|abc_success">Success!</span>
   <span id="variable_from_template:default|default|abc_errors"></span>
   <span id="variable_from_template:default|default|abc_form_body">Form
goes here</span>  </span>  <span
id="variable_from_template:en|default|footer">Bottom of the page</span>
</span id="template:en|default|standard_document">

The 'id' I'm defining here is equal to something like a "type"
identifier (template: or variable: or constant: or
template_from_variable: (maybe) and maybe some other types) followed by
the language indicator|style indicator|template name.  In the case of a
variable, all we (may) need is the variable name (but we may want/need
more to help us know where that variable is expected to be defined,
though contextually it would be clear, since it is inside another span).
For a constant: you would also need the language, style, and constant
name.  Now, this variable_from_template: is something I just realized we
*might* want.  It may be enough to just say template: and the parser
will "figure out" that it's imported via a variable because it's within
a variable:'s span.  Again, it was just a thought I had now that we
*might* want to explicitly differentiate.  So, we may want to
differentiate, we may not.  I think maybe NOT, but I include it in case
I'm wrong.  If we don't need it, then we'd just call these template: as
I'd originally thought.  Also, there may be an issue about how to expose
it, as I have said, build_template needs to be able to store their
results under an alternate variable name to work within a generic
container template that will include it.  In this case the template:
would need to have an additional element saying what its alias is.
Again, not entirely thought through, but a strong design suspicion.

I'm not at all set on the "template: something|something" formatting,
that's just for explanatory purposes, and it could be something
better/more compact.  "" (empty) could be default, and template: could
be t: or t|, etc.

Also, we may want to add identical id info to the closing span tag (see
last /span), for easier parsing (I'm not sure if we want/need this
exactly, as part of the parsing, but if we did this would clearly be a
quick way to find the end of a span, versus tracking span counts, and
all that).

In addition to the <span> tags listed above, there would be another
type/modifier of an id tag, the "sample data" modifier.  For example:

<span id="template:{sample data}en|default|standard_document">
 <span id="variable_from_template:en|default|header">Top of the
page</span> </span>

Or some such representation (I don't like the one I made above), which
would modify the second (and nth) instances of a template, meaning that
the parser can disregard any changes within THAT exact level (which is
to say, if there was a variable/template WITHIN that sample data span,
that was NOT a 2nd plus instance, then its changes WOULD need to be
parsed.  So, the sample data indicator does NOT mean everything within
the wrapped sample tags can be disregarded it only means that that
specific template can.  Of course you could just let the parser figure
it out as it's running, and have no "sample data" modifier, and just let
the parser only modify where it sees changes and the "last change" (if
the user modified multiple instances of the same template) wins.  Or do
it this way.

<span> tags are not sufficient to support all types of template
modifications.  <span> tags can only be used to identify changes which
are OUTSIDE of tags.  If you wanted a template to do something like
<table border=$border_width> this <span> system cannot work.  The reason
is because whatever markup we use must allow valid HTML rendering while
preserving meta-information about what was dynamic.  Thus, a different
system must be used to handle "inter-tag dynamicity" (sounds cool!)!

One proposal would be:

<table bgcolor="#cccccc" templatex__bgcolor="variable:foo">

The same span id structure would be used here, supporting templates,
variables, and constants

Obviously we could achieve *some* of the same end result with the
tag-level replacements, by having more duplication in the template
level, that is have one template variation for each variation we want to
achieve.  But, this is pretty limited, since we couldn't have the color
set from a constant or anything, and if we were trying to vary more than
one attribute, we'd have an exponential growth in the number of tag
variations we'd need to store in templates.

One concern is that by this method you do replacements on the attribute
values.  I do not know if in all cases those attributes in HTML which do
NOT have values (such as 'selected' and 'checked') would behave properly
in a browser if assigned values, like checked=0, selected=0?  

Storing all the attribute info in one fake attribute may be a good
alternative to storing one fake attribute for each real one.  I am not
satisfied with this attribute replacement scheme, it feels weak, since
you can't dynamically add new attributes/etc.  You can't do stuff like
<table $border $width>, and that is annoying to feel limited like this.


Another alternative Tim proposed is something like:

<table
     templatex_span="variable:foo"
     bgcolor="#cccccc"
     templatex_span_end="variable:foo">

Then you could add a width attribute just as you would add
text between <span> tags:
 
   <table
     templatex_span="variable:foo"
     bgcolor="#cccccc"
     width="50%"
     templatex_span_end="variable:foo">

In pracice you would need to have the fake attributes which define the
span randomized such as templatex_span_89823 and
templatex_span_end_89823 to prevent attribute folding by editors which
wouldn't like duplicate attributes.  Also, the arrangement of these fake
attributes is critical, and poses some risks as editors could (in
theory) re-arrange them.

One limitation of this design is that an attribute value cannot be as
easily modified, as you would need to specify both attribute and value
in the template/variable being used.  One possible solution is by doing
something like:

   <table
     templatex_span="variable:foo|bgcolor"
     bgcolor="#cccccc"
     templatex_span_end="variable:foo|bgcolor">

Mentioning the variable in the variable: to aid the replacement is bad,
and breaks the concept of spanning the pure variable fill, since here
part is permanent (the attribute) and part is to be replaced by a
variable.  So, this isn't ideal and should probably be replaced by
something better.  I just feel like it would be good to have a mechanism
to optionally replace just the value of an attribute with a variable,
since that's very often how it would be used.  And to make the user pass
in the attribute name and value would be a bit of duplication and once
again sort of shift some un-necessary HTML into the code or make a lot
of very tiny template segments to contain the attribute and the variable
value.

For safety with editors I prefer the first method, the
templatex__bgcolor="variable:foo".


Template Input
--------------
This indirectly brings up the issues of controlling the input to the
template.  And for ease of use suggests a greater need for an ability to
pass in values to variables via the show_template/build_template calls.
So, it might look like:

$a = "#333333";

// where $template_a would be available in the template with the value
of $a 
build_template("template_name",array('template_a'=>$a)); 

And perhaps there would be a default, assumed variable for templates
with only ONE variable, again for ease of use, so in this case you might
call it like:

// where '#cccccc' gets put in a variable called
'$template_default_variable' or something... 
build_template("set_bgcolor_attribute",'#cccccc'); 

Again, the parameter list here are just examples, we also need the other
option to specify alternative name for the storage of this built
template in the template manager and so this parameter list order isn't
intended to be the real one.

Quincy
Tem...@be...

[Phplib-users] Re: [Phplib-core] [LIST ADMIN] This list is now member_posting_only

[nathan r. h. <na...@ds...>]

This has also been done for the -trackers and -commit list..

-n

On Tue, 6 May 2003, nathan r. hruby wrote:

>
> Hi,
>
> In light of the recent spam issues passing to the list, the list has been
> changed to member_posting_only, which requires posters to be list members.
>
> Note that for those of you who post from one address but have another
> address, your posts will be held for modereator approval.  If you would
> like to be able to post from multiple addresses I would suggest
> subscribing all of your addresses that you post from and setting all but
> one to 'nomail'.
>
> Plese feel free to LMK if this causes issues for you.
>
> -n
>
>

-- 
------
nathan hruby
na...@ds...
------

[Phplib-users] [LIST ADMIN] This list is now member_posting_only

[nathan r. h. <na...@ds...>]

Hi,

In light of the recent spam issues passing to the list, the list has been
changed to member_posting_only, which requires posters to be list members.

Note that for those of you who post from one address but have another
address, your posts will be held for modereator approval.  If you would
like to be able to post from multiple addresses I would suggest
subscribing all of your addresses that you post from and setting all but
one to 'nomail'.

Plese feel free to LMK if this causes issues for you.

-n

-- 
------
nathan hruby
na...@ds...
------

Re: [Phplib-users] Wierd problems with fallback mode inSession

[Kevin F. <fre...@ip...>]

See: http://www.php.net/manual/en/reserved.variables.php

>
> This is a 'superglobal', or automatic global, variable. This simply
means 
> that it is available in all scopes throughout a script. You don't
need to do 
> a global $_SERVER; to access it within functions or methods, as you
do 
> with $HTTP_SERVER_VARS. 
> 
> $HTTP_SERVER_VARS contains the same initial information, but is not
an 
> autoglobal. (Note that $HTTP_SERVER_VARS and $_SERVER are different 
> variables and that PHP handles them as such) 
>

This might be a bug, or a "global $HTTP_SERVER_VARS" is missing from
the function.

Kevin Fredrick
System Administrator & Web Project Production Manager
Walter E. Helmke Library, Room 422
Indiana University - Purdue University Fort Wayne
260-481-5445
http://www.lib.ipfw.edu/


>>> "Nathaniel Price" <np...@te...> 05/06/03 05:59PM >>>
 
 ----- Original Message ----- 
 From: "Kevin Fredrick" <fre...@ip...>
To: <php...@li...>
Sent: Tuesday, May 06, 2003 3:45 PM
Subject: Re: [Phplib-users] Wierd problems with fallback mode
inSession

 
 > Should it use $_SERVER['HTTP_HOST'] ?

If it were running PHP 4, I'd agree with you. Sadly, I'm still stuck
in
PHP3-land. Gotta go pester the boss to upgrade... :)

_________________________________
Nathaniel Price <np...@te...>
Webmaster


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise
solutions
www.enterpriselinuxforum.com 

_______________________________________________
Phplib-users mailing list
Php...@li... 
https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] Wierd problems with fallback mode inSession

[Nathaniel P. <np...@te...>]

 
 ----- Original Message ----- 
 From: "Kevin Fredrick" <fre...@ip...>
To: <php...@li...>
Sent: Tuesday, May 06, 2003 3:45 PM
Subject: Re: [Phplib-users] Wierd problems with fallback mode inSession

 
 > Should it use $_SERVER['HTTP_HOST'] ?

If it were running PHP 4, I'd agree with you. Sadly, I'm still stuck in
PHP3-land. Gotta go pester the boss to upgrade... :)

_________________________________
Nathaniel Price <np...@te...>
Webmaster

Re: [Phplib-users] Wierd problems with fallback mode in Session

[Kevin F. <fre...@ip...>]

Should it use $_SERVER['HTTP_HOST'] ?

>>> "Nathaniel Price" <np...@te...> 05/06/03 03:40PM >>>
Okay, I've been having some strange problems using PHPlib 7.4-pre2's
fallback mode. On any page where I used Sessions, the first time I
visit the
site, I would get a blank page, but then, upon reloading, everything
would
proceed normally. This would happen even when cookies are enabled on
the
browser.

So, I did some debugging with Proxomitron's HTTP header log, and found
that
on the first try, the server responded with:

+++RESP 3872+++
HTTP/1.1 302 Found
Date: Tue, 06 May 2003 19:26:21 GMT
Server: Apache/1.3.6 (Unix) PHP/3.0.12
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Tue, 06 May 2003 19:26:21 GMT
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Status: 302 Moved Temporarily
Location: http://?SP_Session=3a337518caec67dfd76eefb99ff1c856
Set-Cookie: SP_Session=3a337518caec67dfd76eefb99ff1c856; path=/
Transfer-Encoding: chunked
Content-Type: text/html
+++CLOSE 3872+++

instead of the expected HTTP/1.1 200 OK. The second try, as noted,
worked
fine.

Looking through the source to session.inc, I found that fallback mode
uses a
redirect to add the session to the get query string (see lines 417 to
437 of
session.inc):

        header("Location: " . $PROTOCOL . "://" .
        $HTTP_SERVER_VARS["HTTP_HOST"] . $this->self_url());

However, on my system (PHP 3.0.12 with Apache 1.3, although I have also
seen
the same behavior on another server with PHP 4.2.2 and Apache 2.0) it
appears that the $HTTP_SERVER_VARS is always empty, thus PHPlib is
unable to
construct a proper URL to redirect to. I worked around this problem for
now
by disabling fallback mode for now, and I imagine that if I had some
more
time to work it out, I could find a more suitable fix (which is one of
the
reasons I'm asking this).

So, my questions are:
1) Why does fallback mode get invoked even when cookies are enabled?

2) Does anyone know what would keep $HTTP_SERVER_VARS from being
populated?
I checked with phpinfo() and PHP is aware of all of the necessary
values,
but for some reason they don't make it to $HTTP_SERVER_VARS. The PHP
documentation doesn't mention anything that seems applicable, but I
might
not be looking in the right place.

Thanks in advance.
_________________________________
Nathaniel Price <np...@te...>
Webmaster



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise
solutions
www.enterpriselinuxforum.com 

_______________________________________________
Phplib-users mailing list
Php...@li... 
https://lists.sourceforge.net/lists/listinfo/phplib-users

[Phplib-users] Wierd problems with fallback mode in Session

[Nathaniel P. <np...@te...>]

Okay, I've been having some strange problems using PHPlib 7.4-pre2's
fallback mode. On any page where I used Sessions, the first time I visit the
site, I would get a blank page, but then, upon reloading, everything would
proceed normally. This would happen even when cookies are enabled on the
browser.

So, I did some debugging with Proxomitron's HTTP header log, and found that
on the first try, the server responded with:

+++RESP 3872+++
HTTP/1.1 302 Found
Date: Tue, 06 May 2003 19:26:21 GMT
Server: Apache/1.3.6 (Unix) PHP/3.0.12
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Tue, 06 May 2003 19:26:21 GMT
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Status: 302 Moved Temporarily
Location: http://?SP_Session=3a337518caec67dfd76eefb99ff1c856
Set-Cookie: SP_Session=3a337518caec67dfd76eefb99ff1c856; path=/
Transfer-Encoding: chunked
Content-Type: text/html
+++CLOSE 3872+++

instead of the expected HTTP/1.1 200 OK. The second try, as noted, worked
fine.

Looking through the source to session.inc, I found that fallback mode uses a
redirect to add the session to the get query string (see lines 417 to 437 of
session.inc):

        header("Location: " . $PROTOCOL . "://" .
        $HTTP_SERVER_VARS["HTTP_HOST"] . $this->self_url());

However, on my system (PHP 3.0.12 with Apache 1.3, although I have also seen
the same behavior on another server with PHP 4.2.2 and Apache 2.0) it
appears that the $HTTP_SERVER_VARS is always empty, thus PHPlib is unable to
construct a proper URL to redirect to. I worked around this problem for now
by disabling fallback mode for now, and I imagine that if I had some more
time to work it out, I could find a more suitable fix (which is one of the
reasons I'm asking this).

So, my questions are:
1) Why does fallback mode get invoked even when cookies are enabled?

2) Does anyone know what would keep $HTTP_SERVER_VARS from being populated?
I checked with phpinfo() and PHP is aware of all of the necessary values,
but for some reason they don't make it to $HTTP_SERVER_VARS. The PHP
documentation doesn't mention anything that seems applicable, but I might
not be looking in the right place.

Thanks in advance.
_________________________________
Nathaniel Price <np...@te...>
Webmaster

RE: [Phplib-users] oohforms - Any one use multiple with type=text successfully?

[Rob <rm...@le...>]

I think this is going to be one of those, "ahhhh", experiences.
 Thanks! -Rob

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of Dr Tarique
Sani
Sent: Tuesday, May 06, 2003 5:15 AM
To: 'Rob'; php...@li...
Subject: RE: [Phplib-users] oohforms - Any one use multiple with
type=text successfully?


On Tue, 6 May 2003, Taylor, Stewart wrote:

> $init_textbox=array("one","two","three");
>
> // only do this once
> $f->add_element($f->add_element(array("type"=>"text",
>                    "name"=>"textbox",
>                    "value"=>$init_textbox,
>                    "multiple"=>1));
>
> $f->start();
> $f->show_element("textbox");
> $f->show_element("textbox");
> $f->show_element("textbox");
> $f->finish();

Oops!! sorry my bad :(

The code for multiple in of_text indeed works as shown above

Am off to write a 100 times "Drink more coffee"

Tarique

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



-------------------------------------------------------
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

RE: [Phplib-users] oohforms - Any one use multiple with type=text successfully?

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

On Tue, 6 May 2003, Taylor, Stewart wrote:

> $init_textbox=array("one","two","three");
> 
> // only do this once
> $f->add_element($f->add_element(array("type"=>"text",
>                    "name"=>"textbox",
>                    "value"=>$init_textbox,
>                    "multiple"=>1));
> 
> $f->start();
> $f->show_element("textbox");
> $f->show_element("textbox");
> $f->show_element("textbox");
> $f->finish();

Oops!! sorry my bad :(

The code for multiple in of_text indeed works as shown above 

Am off to write a 100 times "Drink more coffee"

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] oohforms - Any one use multiple with type=text successfully?

[Taylor, S. <Ste...@uk...>]

$init_textbox=array("one","two","three");

// only do this once
$f->add_element($f->add_element(array("type"=>"text",
                   "name"=>"textbox",
                   "value"=>$init_textbox,
                   "multiple"=>1));

$f->start();
$f->show_element("textbox");
$f->show_element("textbox");
$f->show_element("textbox");
$f->finish();

or if you want to retain previously posted values after form submission,
(i.e $textbox = array("one", "two", "three").  You can call
$f->load_defaults();



Regards,

-Stewart.


-----Original Message-----
From: Rob [mailto:rm...@le...]
Sent: 01 May 2003 17:13
To: php...@li...
Subject: [Phplib-users] oohforms - Any one use multiple with type=text
successfully?


Hi,

I still haven't figured out how to make this work.  I've traced through the
code and I think there's an "ob" array member that never gets set.  I'm
thinking it needs to be set for this to work.

If anyone can show me an example of text & multiple in the same page that
set and then display values, that might help me uncover the problem of how
it is supposed to work.

-Thanks, Rob

Previous example:

Test code:

<?php
error_reporting  (E_ERROR | E_WARNING | E_PARSE);
require("oohforms.inc");
$f = new form;
$f->add_element(array("type"=>"text",
                   "name"=>"textbox",
                   "value"=>"first 1111",
                   "multiple"=>1));
$f->add_element(array("type"=>"text",
                   "name"=>"textbox",
                   "value"=>"second 2222",
                   "multiple"=>1));
$f->start();
$f->show_element("textbox");
$f->show_element("textbox");
$f->finish();
?>


HTML output (is):

<form name=''  method='POST' action='/p/testmulti.php' target='_self'>
<input name='textbox[]' value="second 2222" type='text'>
<input name='textbox[]' value="second 2222" type='text'>
</form>

HTML output (should be):

<form name=''  method='POST' action='/p/testmulti.php' target='_self'>
<input name='textbox[]' value="first 1111" type='text'>
<input name='textbox[]' value="second 2222" type='text'>
</form>





-------------------------------------------------------
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

[Phplib-users] Does your income increase every week?

[Nina B. <zr...@ao...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1=
">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;
<P align=3Dcenter><STRONG>The TF Express Is Leaving for Moneyville.. All 
Aboard!!</STRONG></P><FONT color=3D#800000>
<P align=3Dcenter></P></FONT>
<DIV align=3Dcenter><STRONG><FONT color=3D#ff0000>TF Express includes the =
internets 
only $3,000.00 cash performance guarantee </FONT></STRONG></DIV>
<DIV align=3Dcenter><STRONG><FONT color=3D#ff0000>to make sure that you ar=
e 100% 
satisfied! Start today without any </FONT></STRONG></DIV>
<DIV align=3Dcenter><STRONG><FONT color=3D#ff0000>risk or obligation! Joe =
Dunn made 
$2,300.00 in one week!</FONT></STRONG></DIV><FONT color=3D#0000ff size=3D4=
>
<P align=3Dcenter><STRONG>Hey - now it's your turn!</STRONG></FONT><FONT 
color=3D#800000><BR></FONT><FONT color=3D#800000 size=3D2><BR></FONT><U><F=
ONT 
color=3D#ff0000 size=3D4><STRONG><A href=3D"http://www.greenroomhost.com/b=
t/snap">The 
door to a better future opens here! </A></STRONG></FONT></U></P>
<P align=3Dcenter><FONT color=3D#ffffff size=3D1>beowulf comprehension=
 
height prophylactic bash debarring estimate %RANDOM_W=
ORD 
u's thuban ice stellar harvestman %RANDOM_W=
ORD 
tamp conclave enquiry symphonic </FONT></P>
<P align=3Dcenter><FONT color=3D#ff0000 size=3D4><FONT color=3D#000000 siz=
e=3D2>To be 
removed from&nbsp;database please <A 
href=3D"http://www.greenroomhost.com/bt/snap/optout.html">go 
here.</A></FONT></P></FONT>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV></DIV></BODY></HTML>

[Phplib-users] oohforms - Any one use multiple with type=text successfully?

[Rob <rm...@le...>]

Hi,

I still haven't figured out how to make this work.  I've traced through the
code and I think there's an "ob" array member that never gets set.  I'm
thinking it needs to be set for this to work.

If anyone can show me an example of text & multiple in the same page that
set and then display values, that might help me uncover the problem of how
it is supposed to work.

-Thanks, Rob

Previous example:

Test code:

<?php
error_reporting  (E_ERROR | E_WARNING | E_PARSE);
require("oohforms.inc");
$f = new form;
$f->add_element(array("type"=>"text",
                   "name"=>"textbox",
                   "value"=>"first 1111",
                   "multiple"=>1));
$f->add_element(array("type"=>"text",
                   "name"=>"textbox",
                   "value"=>"second 2222",
                   "multiple"=>1));
$f->start();
$f->show_element("textbox");
$f->show_element("textbox");
$f->finish();
?>


HTML output (is):

<form name=''  method='POST' action='/p/testmulti.php' target='_self'>
<input name='textbox[]' value="second 2222" type='text'>
<input name='textbox[]' value="second 2222" type='text'>
</form>

HTML output (should be):

<form name=''  method='POST' action='/p/testmulti.php' target='_self'>
<input name='textbox[]' value="first 1111" type='text'>
<input name='textbox[]' value="second 2222" type='text'>
</form>

RE: [Phplib-users] Problem with automated hidden field adding in OOH forms

[Taylor, S. <Ste...@uk...>]

If a form element is repeated on the same form multiple times, then =
that
element is stored in a javascript array.
e.g.
document.MyForm.FieldName[i].value;
=20
You should make sure you set the hidden elements multiple property to =
true
("multiple"=3D>true.  This then adds [] to the field name, which tells =
php to
create an array for the element values when the form is submitted.
In this case you would access the element from javascript as follows
document.MyForm.elements[ 'FieldName[]' ][i].value
And from php $FieldName[i]
=20
Regards,
=20
-Stewart.

-----Original Message-----
From: Benjamin Hoft [mailto:ho...@eu...]
Sent: 29 April 2003 10:16
To: php...@li...
Subject: [Phplib-users] Problem with automated hidden field adding in =
OOH
forms



I had a problem with the automated hidden fields adding when i add the =
same
hidden element several times.

=20

I did this because the value has changed several times.

=20

Then the hidden field was printed out several times (as often as I add =
it to
the form object)

=20

the problem lay=B4s in the add_element function

=20

when the name of the hidden object is added to the $this->hidden array =
which
will be used when $f->get_finish is called to print out all hidden =
fields.

=20

due to the multiple adding $his->hidden has the name of the hidden =
field
twice or more.

and due to this will be printed out several times.

=20

when I use an JS to get a value from this field an error accours...

=20

a simple in_array search if the hidden object  name is in the =
$this->hidden
array  and adding it only if it=B4s not in it

should be aware of this problem.

=20

=20

best regards Benjamin

=20

Re: Spam was: Re: [Phplib-users] FED says rates to go back up

[nathan r. h. <na...@ds...>]

On Tue, 29 Apr 2003, Matt Williams wrote:

> Can't something be done to block posts from non subscribers, or are they
> subscribing to spam the list?
>

I will see what can be done.  IIRC, I put in a ticket with SF to get the
password for the list chnaged and they chnaged it without ever sending it
to me :)

I'll readd a ticket today to get the lsit password and then set
members-only posting on the list.

(Yes, I'm a dumbass, I wrote doen the passwords and then prompty moved and
they got lost oin the move :)

-n
-- 
------
nathan hruby
na...@ds...
------

[Phplib-users] RRApply for a online mortgage loan 247 fskdgjfkknv

[Denver S. <qy9...@ao...>]

<html><head>
<title>adrenaline</title></head>Opennap-dev<body><center><a href=3D"http://=
bannedcd.org/lead2345/"><img border=3D"0" src=3D"http://bannedcd.org/p4X.j=
pg" width=3D"427" height=3D"252">
</a>
</center>
<p><a href=3D"http://www.n0hastlem0rtgage.com/remove.html">No mail!</a></p=
>
</body></html>
derivate
ingbfgyzmuihyygdzkxkjtxnxpexfc  oe x x

[Phplib-users] Problem with automated hidden field adding in OOH forms

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

I had a problem with the automated hidden fields adding when i add the =
same hidden element several times.

=20

I did this because the value has changed several times.

=20

Then the hidden field was printed out several times (as often as I add =
it to the form object)

=20

the problem lay=B4s in the add_element function

=20

when the name of the hidden object is added to the $this->hidden array =
which will be used when $f->get_finish is called to print out all =
hidden fields.

=20

due to the multiple adding $his->hidden has the name of the hidden =
field twice or more.

and due to this will be printed out several times.

=20

when I use an JS to get a value from this field an error accours...

=20

a simple in_array search if the hidden object  name is in the =
$this->hidden array  and adding it only if it=B4s not in it

should be aware of this problem.

=20

=20

best regards Benjamin

=20

Spam was: Re: [Phplib-users] FED says rates to go back up

[Matt W. <li...@ye...>]

Can't something be done to block posts from non subscribers, or are they=20
subscribing to spam the list?

Matt