phpwebsite-developers — For our development team.

[Phpwebsite-developers] New phpWebSite Site

[Alain F. <al...@va...>]

Hi !

Slightly off-topic, but I thought you might be interested anyway...
http://pulsar.webnet.fr/tt-hardware

It's still using the old version while waiting for the new translations to
get ready, and there might still be some bugs and other ugly things, but it
looks pretty nice so far anyway :)

RE: [Phpwebsite-developers] OO vs. Procedural Programing

[Alain F. <al...@va...>]

Hello !

>
> For example:
>
> > later versions of PHP (post 4.04pl1) have the following syntax
> > $myObject =& $thatObject;
> >
> > $newObject =& new Widget;
> >
> > to deal with this issue
>
> does not really create a "true" reference because they don't
> point to the memory
> the other variable is occupying; PHP only interprets these variables as
> references and acts differently.  The copy syntax is still being used.

What is, in your eyes, a "true" reference, and how does PHP not provide it?
Also, "references" is not a strictly OO related topic, you can/could have
the same problems when using procedurial programming :).

> Something I *must*
> consider is that the
> students that participate in this program often come to us as
> Juniors, and their
> understanding of OOP is not necessarily strong.  Ultimately, I
> must make use of
> these students and do not wish to have the project's complexity
> grow beyond what
> they can offer.
>

I can understand your point of view here. We have two possibilities here:
1. Define the system, and try to find the people who can program it.
2. Look at the people who will program, and try to find a project that fits
them.

Re: [Phpwebsite-developers] OO vs. Procedural Programing

[Brian W. B. <br...@ap...>]

Some clarification regarding the OOP vs. Procedural section of the Road Map:

I did not intend to have this be a "closed" issue, and apologize if it appeared
that way.  I would not say that PHP's handling of classes needs to be "carefully
considered" if I did not think it needed to *be considered*.

I very much respect the opinions of our developers and would like this to be
openly discussed. I do, however, want to ensure that everyone (including myself)
has a good understanding of potential pitfalls with PHP's support for OOP:

For example:

> later versions of PHP (post 4.04pl1) have the following syntax
> $myObject =& $thatObject;
>
> $newObject =& new Widget;
>
> to deal with this issue

does not really create a "true" reference because they don't point to the memory
the other variable is occupying; PHP only interprets these variables as
references and acts differently.  The copy syntax is still being used.

On the procedural side, I wanted to underscore that procedural code is a viable
option that should also be considered.  Something I *must* consider is that the
students that participate in this program often come to us as Juniors, and their
understanding of OOP is not necessarily strong.  Ultimately, I must make use of
these students and do not wish to have the project's complexity grow beyond what
they can offer.

Once again, this debate is not closed.  All I ask is that everyone consider the
the technical details, the *entire* project, and all participants involved.

Thank You and Kind Regards,

Brian W. Brown
--
Brian W. Brown
Internet Systems Architect, ESS
Student Development
Room 269, John Thomas Hall
Appalachian State University
Boone, NC 28608

vox: 828-262-7124
fax: 828-262-2585

[Phpwebsite-developers] xml-rpc

[Todd O. <to...@da...>]

Clayton,

http://www.xmlrpc.org is a great resource.  This site links to many xml-rpc
sites that act as tutorials.

--Todd

Re: [Phpwebsite-developers] phpWebSite Road Map

[clayton c. <cc...@ca...>]

> If I remember well, that is exactly as OO languages like C++ work are
> designed to work, hence the need in C++, for instance, for a "Copy
> Constructor". If you need a reference, you just don't use $myObj =
$thatObj
> because that, by -definition-, will create a copy of the original object,
> and not a reference.... :)

IIANM,
  later versions of PHP (post 4.04pl1) have the following syntax

$myObject =& $thatObject;

$newObject =& new Widget;

to deal with this issue

Re: [Phpwebsite-developers] phpWebSite Road Map

[clayton c. <cc...@ca...>]

Todd,
> I haven't seen any discussion about inter-module communication in the
> Roadmap or otherwise.  Did anyone like my xml-rpc proposal?  I think the
> "alert" model (Clayton's term) or trigger model (sql term) should be
handled
> by xml-rpc.  The receiving module would then handle it's own activities,
> such as queing email for nightly transfer.  The sending module would get
> confirmation that the receiver model got the message and would proceed
> accordingly.  This keeps the responsibility of sending emails (let's say)
in
> the email module.
>
i think the thing im having a mental block with (not having looked at PHP
XML-RPC implementations), is how the "triggering" works. is there a daemon
running that handles the incoming requests, or are they handled pretty much
like standard page requests ?

-- clayton

Re: [Phpwebsite-developers] phpWebSite Road Map

[Todd O. <to...@da...>]

See http://www.datadx.com/phpwebsite/ for the eZsession class file and sql
files.  Brian's roadmap has us using native sessions, so consider the above
an educational experience.  Database sessions are a must IF we consider
webserver clusters where server_A will handle client request 1, but server_B
will handle the link to request 2.  I don't forsee a NEED for database
sessions at this precise moment, but I would like to abstract the session
management so they could be added in the future without a rewrite.  On this
same topic, the authentication management should also be similarly
abstracted to allow LDAP at some point in the future too.

The mmbase permissions aren't that easy to explain because they're not in
one place like most of the other projects I listed.  I vote for the ACS
style permissions as translated by Clayton.

I agree with Alain that the object functionality Brian mentioned was the way
I expected.  Does anyone have a link to a PHP discussion of the proposed
change?

I haven't seen any discussion about inter-module communication in the
Roadmap or otherwise.  Did anyone like my xml-rpc proposal?  I think the
"alert" model (Clayton's term) or trigger model (sql term) should be handled
by xml-rpc.  The receiving module would then handle it's own activities,
such as queing email for nightly transfer.  The sending module would get
confirmation that the receiver model got the message and would proceed
accordingly.  This keeps the responsibility of sending emails (let's say) in
the email module.

--Todd

[Phpwebsite-developers] Daily CVS tarball

[Jeremy A. <ja...@tu...>]

OK here is the daily cvs tarball processed in English.  It will be updated
at 4:00AM EST.  If you forget the link you can find it under the downloads
section under CVS on the phpwebsite homepage.

http://152.10.194.1/downloads/phpWebSite-dailyCVS.tar.gz

RE: [Phpwebsite-developers] phpWebSite Road Map

[Alain F. <al...@va...>]

Hi,

Very good work. I have just noted this :

"
...
PHP has created a copy (a new instance) of my_class instead of just a new
reference.
"

If I remember well, that is exactly as OO languages like C++ work are
designed to work, hence the need in C++, for instance, for a "Copy
Constructor". If you need a reference, you just don't use $myObj = $thatObj
because that, by -definition-, will create a copy of the original object,
and not a reference.... :)

> -----Message d'origine-----
> De : php...@li...
> [mailto:php...@li...]De la part de
> Brian W. Brown
> Envoyé : jeudi 12 avril 2001 16:59
> À : php...@li...
> Objet : [Phpwebsite-developers] phpWebSite Road Map
>
>
[snip]

[Phpwebsite-developers] phpWebSite Road Map

[Brian W. B. <br...@ap...>]

phpWebSite Road Map

12 April 2001

###############################################################################
# Coding Standards                                                            #
###############################################################################

As the number of developers working on phpWebSite grows the need for a
formalized set of coding standards becomes increasingly important.  As
recommended by many of the developers involved in phpWebSite, we will be
adopting the PEAR PHP coding standards with a few addendums regarding HTML/XHTML
markup, file headers, comment styles, etc.

The PEAR Standards can be found at:
http://php.net/manual/en/pear.standards.php

Exceptions to the PEAR standards:

Comment Style as per PHPdoc.  See the following for the phpWebSite Developer
docs, and well as rules for comments (thanks to Karsten Dambekalns):
http://www.k-fish.de/krabutzig/phpwebsite/devdoc.html

Addendum to PEAR Standards Regarding Markup (Adapted from the BinaryCloud
Standards):

* Use echo statements for markup where appropriate. Template files (to be
introduced with the re-write of phpWebSite) should *never* contain echo or print
statements as using them obscures the markup.  On the other hand, jumping in and
out of php within complex logic can obscure the logic.

* Do not include complex logic in template files. Conditionals are the most
complex logic allowed in templates. If you need to loop through an array, do it
in the module, and call the template function recursively.

* Declare all of your variables at the top, right under the function. Don't get
globals, etc inside the code. In other words, do all of your setup at the top of
the file.

* It is nice if comments are wrapped to 80 chars, you'll probably get in the
habit anyway - but it is not necessary. Tags cannot and should not be wrapped to
80 chars. Note that this standard applies to *all markup: html, xhtml, wml, xml,
etc.*

* Keep Template files light on php code. People who only know html should feel
comfortable editing these files

* Place an html comment at the bottom of the html with a path to the file.

* Use html comments _ONLY_ when you are printing html. If the comment is about
PHP code, use PHP comments. The purpose of the html comments is to allow html
authors to locate code embedded in complex pages, so they can fix it easily.
Diagnostic information is the only exception.

###############################################################################
# Current Version                                                             #
###############################################################################

phpWebSite v0.7.6 is the current stable release. Development will continue with
this version but will be limited to the following:

1. Release of the calendar as a plug-in. Detailed documentation for plug-in
development will be released at this time. Consider this an open call for help
with this documentation.

2. Bug-Fixes as needed. Current developers should actively try to close all bugs
on SF.  Do not hesitate to assign yourself to a bug if you think you can close
it.

3. Minor functionality fixes.

4. XHTML fixes. Again, don't be shy. CVS is waiting.

5. Security fixes.

We are imposing a feature freeze on the current state of phpWebSite.  Additional
features, and major re-structuring will be reserved for the re-write project
described below.

Current development will continue until 1.0 is reached. Version  1.0 will be
defined by:

1. Stable, secure, "bug-free" operation.

2. Valid XHTML for all generated client output.

###############################################################################
# phpWebSite Re-Write                                                         #
###############################################################################

As phpWebSite has evolved, many limitations in its current design have become
apparent.  As opposed to attempting to patch the existing code, we have decided
to re-write phpWebSite.  The re-write will allow for intelligent structuring of
the application and provide an opportunity to remove inefficient legacy code
from the application. In order to differentiate between the current phpWebSite
and the re-write, the re-written code should be referred to as phpWebSiteII.

Design Philosophy
Efficiency, modularity, and ease of use are the goals of phpWebSiteII. A
minimalistic core will provide basic functionality and services.  Features will
be provided on an as needed basis by external plug-ins. Site authoring should be
easy and intuitive for the user possessing even minimal computer skills. Site
administration should also be easily managed, allowing for multiple instances
using a single database and code base (Geoff Staples has done some good work
toward this goal).  phpWebSiteII should scale to support a *large* number of
virtual sites.

Core Modules
All core modules should have some sort of "scoping/relation-node" inter-module
relationship as in mmbase and ACS Digital. Clayton Collie and Todd Owen have a
good start on this discussion, and I would like see one (or both) of them take
the lead role in developing this for phpWebSiteII. The following modules will
define the core:

Authorization Module
The authorization module should handle all authorization (user and admin) and
permissions for the system. MD5 encryption should become the standard.
Permissions/access control will be granular as opposed to tiered. Todd Owen has
put forth good ideas based on Zope. LDAP support should be an option for those
who wish to use it.  Plug-ins should be able to leverage both basic
authorization and granular permissions.

Template Module
A custom templating schema will be developed.  Although products such as SMARTY
or PHPLib provide a great deal of functionality, we are hesitant to lean too
heavily on a third party project. By developing our own templating methods, we
can keep installation requirements minimal and provide tighter integration with
other core services.  Templates should be simple, light or void of php code, and
flexible enough to allow html designers to easily create new themes using tools
of their choice. Adam Morton and Matt McNaney are currently working on some
"proof of concept" approaches to templating.  Existing themes will not be
backwards compatible, but re-creating them should be much easier.

Administration Module
The administration module will provide access to all administrative functions
for the core and any installed plug-ins. Inter-module relationship with the
authorization module will define rights for these functions.

Announcements Module (formally "articles/stories")
Current functionality is good. Relationship with the authorization module should
provide display of a given announcement or class of announcements based on
permissions.

Comment Module
Current functionality is OK. Some users have expressed the need for Slashdot
style comments. More choices here would be welcome.

Email Module
The email module will go beyond the simple email functions currently in
phpWebSite.  Mailing lists, forum and comment monitoring via email should be
available options to users.

Help/User Documentation Module
Will be implemented in the next release of phpWebSite.  For phpWebSiteII
inter-module relationships should open module to be plug-in aware.
Context-sensitive help should be available throughout the site.

Menu Module
Menu module should handle both administrative and user side menu function.
Current menu system works but lacks flexibility.

Plug-In Module
The plug module should handle all plug-in registration, and provide a gateway
for plug-in communication with other modules.  Current plug-in API needs to be
enhanced, but backwards compatibility of existing plug-ins needs to be
preserved.

Search Module
Search engine needs re-design.  Should be more modular and flexible.

Other Core System Specifications:

Database Abstraction
phpWebSiteII will support multiple databases via the PEAR DB.php that ships with
PHP4.x.

Session Management
PHP4's native session management will be utilized in phpWebSiteII.

Registered User Customization
Greater flexibility for registered users is desired.  Ability to choose custom
news feeds, personal "quick links", etc.  Please note, however, that this does
not include features such as block re-ordering - while this is "cool", we remain
unconvinced as to any real functionality this provides.

Error Checking
Sanity checks on submitted data, graceful recovery for user preference conflicts
(theme removal, etc.) needs to be implemented.

What is not in the core
Polls, stats, web links, calendar, etc. will be re-written as plug-ins.

phpWebSite -> phpWebSiteII
A clear upgrade path must exist.

###############################################################################
# Architecture/Modeling of phpWebSiteII                                       #
###############################################################################

This document has attempted to define phpWebSiteII using relatively broad brush
strokes. Where possible we have specified key components that will achieve
various ends, most notably, database abstraction and templating.  A detailed
architectural design is needed before implementation can begin. Those developers
who have extensive experience with software engineering are asked to please step
forward and avail your skills to the project.  I would like to form a *small*
team to model/design the re-write based on this document.

Object Oriented vs. Procedural Programing
Some have suggested an OOP approach to the re-write.  Unfortunately, the PHP
handles classes in a weird way due to variable handling of the interpreter:

class my_class
{
var $var1, $var2, $var3;
}

$my_object = new my_class;

$my_object->var1 = 1;
$my_object->var2 = 2;
$my_object->var3 = 3;

$new_object = $my_object;

$new_object->var1 = 3;
$new_object->var2 = 2;
$new_object->var3 = 1;

print("My Object goes $my_object->var1, $my_object->var2, $my_object->var3 !");

print("New Object goes $new_object->var1, $new_object->var2, $new_object->var3
!");

This produces the following output:

My Object goes 1, 2, 3 !
New Object goes 3, 2, 1 !

:-/

PHP has created a copy (a new instance) of my_class instead of just a new
reference.

To complicate matters further, this will be changed in an upcoming version of
PHP, causing a loss of backward compatibility. While this does not sink an OOP
approach, it certainly is something to carefully consider. Additionally, an OOP
approach would most likely impose greater overhead in development.

On the other hand, the current code takes a procedural approach, and coupled
with a good design, a procedurally oriented re-write should be as effective, as
maintainable and as extensible as an object-oriented one.

###############################################################################
# Development Team Organization/Management                                    #
###############################################################################

I would like to organize the developers into small teams, each with a module (or
two) on which to focus.  Each of these small teams will have a lead developer
that will have decision making authority for the module(s) that he or she
manages.  This should help the overall efficiency of the re-write, since it is
simply easier to communicate with a smaller number of people than a large
number.  Module team leaders will report to a design/engineering team, and would
be responsible for sharing information that impacts work outside of the
particular module. Those working on a given team, report to the team leader. We
need volunteers for the following:

Design/Engineering Team
This team should be composed of developers who have the most experience with
software engineering. This team will provide the blueprints for the re-write to
the other teams. If you would like to be the lead on this team, please indicate
so.

Module Teams
Teams for each module discussed above need to be established. Again, if you
would like to lead a team, please indicate so.

Graphics/Theme Team
This team will focus on theme creation and graphic design (we *really* need some
custom icons, etc.). This team will be for developers with Gimp/Photoshop
experience and/or XHTML/HTML design experience.  A lead will be needed here as
well.


Communication Tools

SF Developers List
We will limit communication to the SF developers list. If any given team feels
it needs a separate list, let Jeremy Agee know and he will set it up.

IRC
Someone once made the offer to setup IRC for phpWebSite.  Please do so, this
will provide a good secondary method for teams to plan/discuss in real time,
augmenting, but not replacing the developers list.

phpWebSite Name Change
For now we are going to keep the name phpWebSite. It is widely recognized, and
we feel that we can get phpwebsite.org without too much trouble using the new
ICANN rules regarding "squatting".  Jermey Agee is working on that little
project.  It is possible that phpWebSiteII could use a name change that would
offer an opportunity to capture a good domain name.  We should have some time,
so if you have an idea for a brilliant name, let everyone know.

Thanks again to all are developers.

Kind Regards,
Brian Brown
phpWebSite Project Manager


--
Brian W. Brown
Internet Systems Architect, ESS
Student Development
Room 269, John Thomas Hall
Appalachian State University
Boone, NC 28608

vox: 828-262-7124
fax: 828-262-2585

Re: [Phpwebsite-developers] Session Management

[Karsten D. <k.d...@tu...>]

On Wed, Apr 11, 2001 at 05:33:49PM -0400, Todd Owen wrote:

> What opinions do you have about placing the sessions in the database inst=
ead
> of files in /tmp?  ezPublish uses the database approach.  We already use =
the
> database for referral data instead of Apache.

What about PHP4 natvive sessions? If we use these (and they are very
efficient, as to what I have heard - I still have to try them myself during
the next days) - and give a lot of flexibility to the coder when it comes to
"how and where do I store session data".

Just my 2c,
Karsten
--=20
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w=B3: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

RE: [Phpwebsite-developers] RE: Another point of view about templates...

[Geoff S. <Ge...@Ho...>]

Sablotron is a big no-no. We don't run it on our servers because the tech
guys tell me it has security problems.

But, the bigger issue is this: The more it takes to make phpWebSite work,
the less it will be used.

Geoff

Geoff Staples,
214.599.0260
Hostricity Web Hosting <http://www.hostricity.com/>

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of
> W.D.Sumilang
> Sent: Wednesday, April 11, 2001 8:31 PM
> To: php...@li...
> Subject: [Phpwebsite-developers] RE: Another point of view about
> templates...
>
>
> REF:
> http://www.geocrawler.com/lists/3/SourceForge/9885/0/5532502/
>
> I'll agree w/ KK, but this also requires Sablotron compiled in and some
> hosts just don't do it... so until its in by default... what to do?
>
> also see...
> http://www.oreillynet.com/pub/a/onlamp/2001/03/16/sablotron.html
>
> __________________________________________________
> FREE voicemail, email, and fax...all in one place.
> Sign Up Now! http://www.onebox.com
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>

[Phpwebsite-developers] RE: Another point of view about templates...

[W.D.Sumilang <wa...@on...>]

REF:
http://www.geocrawler.com/lists/3/SourceForge/9885/0/5532502/

I'll agree w/ KK, but this also requires Sablotron compiled in and some
hosts just don't do it... so until its in by default... what to do?

also see...
http://www.oreillynet.com/pub/a/onlamp/2001/03/16/sablotron.html

__________________________________________________
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com

[Phpwebsite-developers] RE: Session Management

[W.D.Sumilang <wa...@on...>]

> I vote for the database. i hate the proliferation of all those files.
> BTW - Todd, did you see my questions r.e. mmbase permissions ? i wasnt
> able to find a reference ...

Yes, can Todd clarify... it seems that permissions for mmbase is still
under scrutiny... currently (i believe) mmbase gives "editor" capabilities
by creating relations with the a respective editor object which i don't
think applies directly to phpWS... or maybe i'm way off here ;)

__________________________________________________
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com

[Phpwebsite-developers] phpBB Hack for phpWebSite released!

[Jason C. <cam...@xp...>]

I've released the phpBB hack for phpWebSite.  Right now I have it on my 
website but I plan on getting it up on the main phpWebSite soon!  But I 
wanted to get it out to everyone right now.

Jason Campbell
Xplozive Media Technologies
www.xplozivemedia.com

[Phpwebsite-developers] Phpbb version 2 specs

[<Tra...@ao...>]

In case some didn't know about this site
it is the official phpbb2 info center 

http://area51.phpbb.com/

also if you want to see the stripped down code in action you can find it here

http://forums.starstreak.net

Just figured I keep peeps up-to-date on their progress

Trajick
Phpwewsite Developer

[Phpwebsite-developers] Phpbb version 2 specs

[<Tra...@ao...>]

In case some didn't know about this site
it is the official phpbb2 info center 

http://area51.phpbb.com/

also if you want to see the stripped down code in action you can find it here

http://forums.starstreak.net

Just figured I keep peeps up-to-date on their progress

Trajick
Phpwewsite Developer

Re: [Phpwebsite-developers] Update

[Jason C. <cam...@xp...>]

I'm going to start bug testing features and even have a bug testing site up 
for everyone to mess with once Jeremy gets the daily snapshots of the CVS 
code in tarballs then I can throw up a site with the CVS version.

Do you know if anyone has started on changeing the poll system and other 
features of the system as plugins or modules yet??  Brain mentioned it and 
didn't say if anyone was working on that now.  I would be willing to take 
any of the internal parts of the system and making them plugins.  I just 
want to make sure no one else is already doing it before I'd start work on 
it.

Jason Campbell
Xplozive Media Technologies

> Brian Brown is close to finishing the roadmap. I can't say when it will
> be  done because often something comes up that needs discussion before
> putting  it on paper. We don't want to rush the roadmap for the same
> reasons you  wouldn't want a literal roadmap to be hurried... it causes
> people to get  lost.
> 
> In the meantime we are certain about two things 1)their will be a
> rewrite  and 2) we need to secure the currrent version. I know bug
> smashing isn't as  interesting as writing new code but we would
> appreciate any developers to  hit sourceforge then CVS to fix what is
> broken.
> 
> As to why it has been quiet, we are all discussing the rewrite, I am
> coding  the calendar upgrade/plugin, Brian is researching almost
> everything you are  suggesting, Jeremy is maintaining the servers, Adam
> is researching and  working on template formats and Brian L. is
> completing a help system. Don't  mistake our occasional silence as a
> lack of interest. We are listening and  are excited about the future =)
> 
> Thanks again to everyone for their time and devotion. Have a great
> holiday.  Matthew McNaney
> 
> Systems Administrator
> Career Development Center
> Ph: 828-262-2180
> Fax:828-262-2834
> 
> 
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Session Management

[clayton c. <cc...@ca...>]

I vote for the database. i hate the proliferation of all those files.
BTW - Todd, did you see my questions r.e. mmbase permissions ? i wasnt able
to find a reference ...

[Phpwebsite-developers] Session Management

[Todd O. <to...@da...>]

What opinions do you have about placing the sessions in the database instead
of files in /tmp?  ezPublish uses the database approach.  We already use the
database for referral data instead of Apache.

--Todd

[Phpwebsite-developers] Update

[Matthew M. <mcn...@tu...>]

Brian Brown is close to finishing the roadmap. I can't say when it will be 
done because often something comes up that needs discussion before putting 
it on paper. We don't want to rush the roadmap for the same reasons you 
wouldn't want a literal roadmap to be hurried... it causes people to get 
lost.

In the meantime we are certain about two things 1)their will be a rewrite 
and 2) we need to secure the currrent version. I know bug smashing isn't as 
interesting as writing new code but we would appreciate any developers to 
hit sourceforge then CVS to fix what is broken.

As to why it has been quiet, we are all discussing the rewrite, I am coding 
the calendar upgrade/plugin, Brian is researching almost everything you are 
suggesting, Jeremy is maintaining the servers, Adam is researching and 
working on template formats and Brian L. is completing a help system. Don't 
mistake our occasional silence as a lack of interest. We are listening and 
are excited about the future =)

Thanks again to everyone for their time and devotion. Have a great holiday. 
Matthew McNaney

Systems Administrator
Career Development Center
Ph: 828-262-2180
Fax:828-262-2834

[Phpwebsite-developers] Another point of view about templates...

[Karsten D. <k.d...@fi...>]

Hi all!

You might want to read this

http://www.geocrawler.com/lists/3/Web/195/125/4988613/

It has some words about templates vs. XSL which might be worth reading. It
is an email from Kristian K=F6hntopp, the ever popular phplib coder :-)

Reagards,
Karsten
--=20
fishfarm - Karsten Dambekalns
Echternstr. 73 - 38100 Braunschweig

Tel. +49 531 1232902  mailto:k.d...@fi...
Fax. +49 531 1232906  http://www.fishfarm.de/
-----------------------------------------------------

Re: [Phpwebsite-developers] Daily snapshots of CVS

[Jason C. <cam...@xp...>]

I can't believe that simple message would cause 4 posts :)  I already sent 
him a private message about it because I thought he'd get it quicker that 
way....

> On Wed, Apr 11, 2001 at 10:21:10AM +0200, Alain Fontaine wrote:
> 
>> function does not work; you have to address the variables through
>> $HTTP_SERVER_VARS, for instance. So it would definitely make sense to
>> have one version that can be manually set to work on both platforms.
> 
> BTW: We should always use HTTP_(POST|SERVER|GET|...)_VARS, since it
> makes things safer (I don't have the time to explain that right now),
> works even if track_vars is off and is (as noted) sometimes more
> compatible.
> 
> Brian: Maybe this should go into the roadmap as well?
> 
> Karsten
> -- 
> fishfarm - Karsten Dambekalns
> Echternstr. 73 - 38100 Braunschweig
> 
> Tel. +49 531 1232902  mailto:k.d...@fi...
> Fax. +49 531 1232906  http://www.fishfarm.de/
> -----------------------------------------------------

Re: [Phpwebsite-developers] Daily snapshots of CVS

[Karsten D. <k.d...@fi...>]

On Wed, Apr 11, 2001 at 10:21:10AM +0200, Alain Fontaine wrote:

> function does not work; you have to address the variables through
> $HTTP_SERVER_VARS, for instance. So it would definitely make sense to have
> one version that can be manually set to work on both platforms.

BTW: We should always use HTTP_(POST|SERVER|GET|...)_VARS, since it makes
things safer (I don't have the time to explain that right now), works even
if track_vars is off and is (as noted) sometimes more compatible.

Brian: Maybe this should go into the roadmap as well?

Karsten
--=20
fishfarm - Karsten Dambekalns
Echternstr. 73 - 38100 Braunschweig

Tel. +49 531 1232902  mailto:k.d...@fi...
Fax. +49 531 1232906  http://www.fishfarm.de/
-----------------------------------------------------

RE: [Phpwebsite-developers] Daily snapshots of CVS

[Alain F. <al...@va...>]

Hi,

Anyway, Windows platforms understand tarballs, too :).

On the other hand, although I agree it won't make sense to make a special
windows version, it would surely make sense to allow switching from "linux"
to "windows" using a config parameter. A small example of a quite annoying
incompatibility : if you are using the PHP ISAPI module on IIS, the getenv()
function does not work; you have to address the variables through
$HTTP_SERVER_VARS, for instance. So it would definitely make sense to have
one version that can be manually set to work on both platforms.

> -----Message d'origine-----
> De : php...@li...
> [mailto:php...@li...]De la part de
> Geoff Staples
> Envoye : mercredi 11 avril 2001 07:31
> A : php...@li...
> Objet : RE: [Phpwebsite-developers] Daily snapshots of CVS
>
>
> I agree. Forget the zip file and just do a tarball.
>
> The only time a zip file would be needed is if we had a different
> version of
> phpWebsite for Windows. Since we don't, no need for a zip!
>
> Geoff
>