[PHP-DEV] ANNOUNCE: Yet Another Template System (YATS)

[Dan Libby]

Epinions.com has graciously allowed me to open-source another project
I worked on during my employ.

YATS is a templating system for PHP. It enables web developers to
cleanly separate code/logic from display/html. This is useful for
purposes of internationalization, multiple device access, development
process flow, and general maintenance.  Unlike most other such
systems, it is a C extension, and is optimized for speed.  The usage
paradigm is similar to that of FastTemplate, but with some
improvements.  It specifically does not allow executing php in the
templates, or anything that might be construed as a "real language".

YATS HomePage:
http://yats.sourceforge.net/

I welcome all feedback and contributions.

-danda

--
Dan Libby <[EMAIL PROTECTED]>, author of xmlrpc-epi

check out xmlrpc-epi -- a C library for xmlrpc with a PHP extension.
http://xmlrpc-epi.sourceforge.net

and learn about xmlrpc, enabling remote procedure calls over the net.
http://www.xmlrpc.com

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Zend API changes

[Dan Libby]

ok, so ZEND_VERSION_DOUBLE is crazy talk. the preprocessor doesn't like floats
either.  But something like ZEND_VERSION_MAJOR 4, ZEND_VERSION_MINOR 6 would
satisfy it.

-danda

Dan Libby wrote:

> This change also broke my extension.  I'd like to have the extension
> be buildable with all of 4.x without user intervention, so I'm trying
> to figure out some way to handle the change via the pre-processor.
>
> I thought that ZEND_VERSION, defined in zend.h, might do the trick.
> Unfortunately, it is defined as a string, thus the C preprocessor
> won't perform any comparisons against it. Perhaps in 4.0.6+ there
> could also be a ZEND_VERSION_DOUBLE, eg:
>
> #define ZEND_VERSION_DOUBLE 4.06
>
> Does anyone have any clever solutions to this problem that I could use
> today?  thx.

--
Dan Libby <[EMAIL PROTECTED]>, author of xmlrpc-epi

check out xmlrpc-epi -- a C library for xmlrpc with a fast PHP extension.
http://xmlrpc-epi.sourceforge.net

and learn about xmlrpc, enabling remote procedure calls over the net.
http://www.xmlrpc.com



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Zend API changes

[Dan Libby]

This change also broke my extension.  I'd like to have the extension
be buildable with all of 4.x without user intervention, so I'm trying
to figure out some way to handle the change via the pre-processor.

I thought that ZEND_VERSION, defined in zend.h, might do the trick.
Unfortunately, it is defined as a string, thus the C preprocessor
won't perform any comparisons against it. Perhaps in 4.0.6+ there
could also be a ZEND_VERSION_DOUBLE, eg:

#define ZEND_VERSION_DOUBLE 4.06

Does anyone have any clever solutions to this problem that I could use
today?  thx.

-danda

> It's in everyone's interest to keep the API intact.  The Zend API is now
> fairly stable (I don't expect compatibility breaking changes in the 4.0
> line);  Judging from the experience of PHP 3.0, there too, the API
> stabilized around x.0.5.
>
> Zeev
>
> At 18:29 4/5/2001, Brian Foddy wrote:
> >A small point I'd like to raise here.
> >
> >I noticed 4.0.5 made a change to the arguments of
> >zend_hash_get_current_key
> >by adding a "dupe" argument to the define and underlying function.
> >
> >This of course broke any external custom modules that are not
> >changed appropriately.  In this case the change was very simple,
> >but it raises a good question...
> >
> >Are there some guidelines independent external modules can follow
> >to remain more compatible between releases?  I'm not questioning
> >the right or need for underlying Zend API changes, obviously
> >when such changes are made all functions inside the PHP collection
> >are change accordingly.  But are there suggestions to minimize
> >these in the future and get better notified when they do occur?
> >
> >Thanks,
> >Brian
>

--
Dan Libby <[EMAIL PROTECTED]>, author of xmlrpc-epi

check out xmlrpc-epi -- a C library for xmlrpc with a fast PHP
extension.
http://xmlrpc-epi.sourceforge.net

and learn about xmlrpc, enabling remote procedure calls over the net.
http://www.xmlrpc.com



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] announcement: new xmlrpc php C extension

[Dan Libby]

Apologies in advance if this is not the appropriate list for such an announcment. If 
there is a better one, please direct me toward it.

I have cleaned up and released the php extension portion of the xmlrpc  library we 
have been using internally at Epinions.com for a while now. It is currently somewhere 
between alpha and beta level code. It is pretty stable, but I'd like to hear of your 
experience (good or bad) if you get the chance to try it.

Some docs and live examples can be found at:
http://xmlrpc-epi.sourceforge.net/main.php?t=php_about

I'm also looking for people who would be interested in helping out adding new features 
such as method introspection or fixing up the auto* build system and release packaging.

-danda


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]