GoPHP5

[Sebastian Mendel]

Hi,

it would be nice if Smarty dev team would participate

http://gophp5.org/


--
Sebastian Mendel

www.sebastianmendel.de

--
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[boots-2]

--- Sebastian Mendel <lists@...> wrote:
> Hi,
>
> it would be nice if Smarty dev team would participate
>
> http://gophp5.org/

Hi Sebastian.

What would need to be done other than stop saying that PHP4 is supported?
Smarty already works well with all versions of PHP > 4.0.6, not? Is the
expectation that there will be a version that uses features that would prevent
PHP < 5? Or is it just a marketing optics thing?

Best.
boots

>
> --
> Sebastian Mendel
>
> www.sebastianmendel.de
>
> --
> Smarty Development Mailing List (http://smarty.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

       
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222

--
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Sebastian Mendel]

boots schrieb:

> --- Sebastian Mendel <lists@...> wrote:
>> Hi,
>>
>> it would be nice if Smarty dev team would participate
>>
>> http://gophp5.org/
>
> Hi Sebastian.
>
> What would need to be done other than stop saying that PHP4 is supported?
> Smarty already works well with all versions of PHP > 4.0.6, not? Is the
> expectation that there will be a version that uses features that would prevent
> PHP < 5? Or is it just a marketing optics thing?

all new feature release after 2008-02 require PHP >= 5.2

in phpMyAdmin we release last new feature release this month (2.11), after
this you will only get 2.11.x with PHP 4 compatibility (being in our current
6 month release cycle)

in 2008-02 we will release 3 with min. requirements PHP 5.2 and still
support 2.11.x with security and stability updates - we will watch the
downloads of 2.11.x and decide how long we will provide updates to them


btw. MySQL support will also raise to >= 4.1 or even 5 (we did not decide
finally now)

i think this will help us greatly better focus on develop new features and
not testing and fixing all sorts of PHP version with all it's missing
features new in PHP 5 ( - and the same for MySQL)

we have the same problem as your development team currently has - lacking
man power - so this will not only help us but our customers too with a
better phpMyAdmin.


--
Sebastian Mendel

www.sebastianmendel.de

--
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Mark Rogers]

Sebastian Mendel wrote:
> boots schrieb:
>  
>> What would need to be done other than stop saying that PHP4 is supported
> all new feature release after 2008-02 require PHP >= 5.2
>  

I think it's safer to describe it as any future release after 2008-02
would not take PHP<5.2 compatibility into account, rather than actually
requiring 5.2+.

I hadn't appreciated until I read the GoPHP5 site just how long PHP5 has
been around - I've been using PHP since PHP3 so I was obviously aware of
PHP5 being released when it was (I even played with betas) but I'd lost
track of how long ago that was.

I have to say that I would agree that maintaining support for PHP<5.2
must be pretty pointless now; Smarty is pretty stable so anyone who
needs support for an older PHP version should find that the existing
Smarty version does what they need. And I say that as someone who still
has most of the sites I maintain running PHP4.3/MySQL 3.23 - I need the
push to get them migrated too!

PHP5's handling of XML in particular is a vast improvement over previous
versions, and I suspect XML is something that will increasingly be
important to Smarty users.

Out of curiosity, do any of the main Smarty developers do any work in
PHP4.x any more? There can't be many more than a handful of people who's
views really count on this, since they're the ones that do most of the
dev work.

As I'm not one of that handful, I don't expect (or want) my views to
count much, so +0.1 for this from me :-)

--
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0845 45 89 555
Registered in England (0456 0902) at 13 Clarke Rd, Milton Keynes, MK1 1LG

--
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[tfk]

Hi,

On 7/6/07, Mark Rogers <mark@...> wrote:

> Sebastian Mendel wrote:
> > boots schrieb:
> >
> >> What would need to be done other than stop saying that PHP4 is supported
> > all new feature release after 2008-02 require PHP >= 5.2
> >
>
> I think it's safer to describe it as any future release after 2008-02
> would not take PHP<5.2 compatibility into account, rather than actually
> requiring 5.2+.

I personally think that's a no-go. gophp5 aims on a complete rewrite
of the PHP4 code-base to make it PHP5.2+ only. Not "compatible". At
least I think I see a difference there.


Cheers,
Till

--
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Sebastian Mendel]

Mark Rogers schrieb:
> Sebastian Mendel wrote:
>> boots schrieb:
>>  
>>> What would need to be done other than stop saying that PHP4 is supported
>> all new feature release after 2008-02 require PHP >= 5.2
>
> I think it's safer to describe it as any future release after 2008-02
> would not take PHP<5.2 compatibility into account, rather than actually
> requiring 5.2+.

at least for phpMyAdmin, what i was talking about in last post, this is not
correct, as we not just anymore "take PHP<5.2 compatibility into account"
but actively remove code that was used to implement/simulate behavior from
PHP 5 and introduce OO functionality not supported by PHP 4


but i do not know how the Smarty dev team will handle this


--
Sebastian Mendel

www.sebastianmendel.de

--
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Mark Rogers]

Sebastian Mendel wrote:
> at least for phpMyAdmin, what i was talking about in last post, this is not
> correct, as we not just anymore "take PHP<5.2 compatibility into account"
> but actively remove code that was used to implement/simulate behavior from
> PHP 5 and introduce OO functionality not supported by PHP 4
>  

Oh OK, I misread it. Even so I agree that removing PHP4 workarounds is a
good thing if there's a reason to do so (eg if PHP5 gives a better
performing way to do something or a way which is otherwise more robust).
Changing something that works for something that "should" be the same,
for no other reason that to break PHP4 compatibility, would seem like a
bad idea, as (unlike phpMyAdmin) Smarty does need to retain
compatibility with templates written previously (whether for older
versions or not, perhaps except where that compatibility is broken
purely because of a PHP version issue). Ie if I have a site which works
now on PHP5 and after the Smarty upgrade to the PHP5 version no longer
works because something obscure is now done differently, then that *is*
an issue, and changing things that work just to break PHP4 compatibility
would be prone to breaking things in this way.

--
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0845 45 89 555
Registered in England (0456 0902) at 13 Clarke Rd, Milton Keynes, MK1 1LG

--
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[boots-2]

--- Mark Rogers <mark@...> wrote:

> Sebastian Mendel wrote:
> > at least for phpMyAdmin, what i was talking about in last post, this is not
> > correct, as we not just anymore "take PHP<5.2 compatibility into account"
> > but actively remove code that was used to implement/simulate behavior from
> > PHP 5 and introduce OO functionality not supported by PHP 4
> >  
>
> Oh OK, I misread it. Even so I agree that removing PHP4 workarounds is a
> good thing if there's a reason to do so (eg if PHP5 gives a better
> performing way to do something or a way which is otherwise more robust).
> Changing something that works for something that "should" be the same,
> for no other reason that to break PHP4 compatibility, would seem like a
> bad idea, as (unlike phpMyAdmin) Smarty does need to retain
> compatibility with templates written previously (whether for older
> versions or not, perhaps except where that compatibility is broken
> purely because of a PHP version issue). Ie if I have a site which works
> now on PHP5 and after the Smarty upgrade to the PHP5 version no longer
> works because something obscure is now done differently, then that *is*
> an issue, and changing things that work just to break PHP4 compatibility
> would be prone to breaking things in this way.

First, I appreciate the comment that people are making in this thread. In my
view, this is a worthwhile discussion and I am interested to hear what Smarty
users/devs think on this point.

I think I might be able to speak for the core Smarty devs when I say that we
have striven to support Smarty for the target group: PHP 4.0.6+. Indeed, we
have tended to favor PHP4 idioms over PHP5 idioms just for sake that we wanted
to make sure that Smarty was available to widest audience possible. As a result
of that effort, current versions of Smarty can be expected to run on *any* and
*all* PHP installations that one might find in production today. So, it seems
to me that it remains important to continue that level of support when it is
both easy to do so (which for Smarty it is) and while considering the fact that
PHP4 is still running at something like an 80% adoption rate. That said (and
considering that PHP4 will surely be put to pasture) I do agree that thinking
of the future always makes sense.

Now I'll speak only for myself. I've been running PHP5 for years. If for no
other reason, I highly recommend everyone who can to migrate to PHP5.2 as
quickly as they can; even if you don't need the extra features, the performance
improvements (Smarty performs best under PHP 5.2, IMO) make it worthwhile. I
think that if/when (more of a "when", then an "if") the Smarty 3.x branch
arrives, it can be expected to break with the old PHP4 compatibility just
because it will use PHP5+ only features. Until that happens, I see no harm
(perhaps even as I risk the very small reputation I may have) in continued
support for PHP4 users. I may be a PHP5 user myself, but I don't see why Smarty
has to renege on PHP4 support at this point. It costs us nearly nothing to
support PHP4 and PHP4 is wildly still the most popular version deployed.

Smarty has consistently been a lowest common denominator type of library --
without a compelling rewrite that takes specific advantage of new PHP features,
I see no reason to abandon that at this time. What other PHP library still runs
as well on 4.0.6 as it does on 5.2.1 and every version between? Should Smarty
2.x really demand 5.2+ when it can still easily support legacy users?

I'd be happy to hear more on this issue from any interested parties.

Best,
boots

PS. As an aside, it is my humble opinion that a rewrite of Smarty should target
PHP 5.2 as a minimum. I propose that it may even be worthwhile to wait for such
a change until PHP6 arrives so as to finally be able to uniformly support
unicode at the same time as upgrading the architecture.



 
____________________________________________________________________________________
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

--
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Alain Williams]

On Mon, Jul 09, 2007 at 12:44:00AM -0700, boots wrote:

> Smarty has consistently been a lowest common denominator type of library --
> without a compelling rewrite that takes specific advantage of new PHP features,
> I see no reason to abandon that at this time. What other PHP library still runs
> as well on 4.0.6 as it does on 5.2.1 and every version between? Should Smarty
> 2.x really demand 5.2+ when it can still easily support legacy users?
>
> I'd be happy to hear more on this issue from any interested parties.
> ....

The big problem is the 'long term support' offered by distros.
Eg RedHat Enterprise 4 came out with PHP4 and so will continue to offer/support
PHP4 for another 5 years or so.

If/when PHP4 becomes a museum piece (proposed 8/8/8) the RedHat support team will
ensure that security fixes are back ported into the RedHat supported PHP.
This is a good thing; it is exactly what people who pay for want - they want an
unchanging platform so that their applications just continue to work.

Since smarty is not part of the RedHat offering people who run RHE4 will be left
with an unsupported component.

The only way that we can do 2 different things is to fork smarty:
* smarty museum: PHP4, only receives security fixes
* smarty current: move to PHP 5.2

I suspect that in 2 years time we will have the same discussion about moving
to PHP 6. At that time we will fork again to have 2 museum branches.

How long do we support stuff in the museum ? Probably 3-5 years.

It is important to realise that the museum gets security fixes only. If you
want a new feature you must upgrade. This is to keep the work load down.

> PS. As an aside, it is my humble opinion that a rewrite of Smarty should target
> PHP 5.2 as a minimum. I propose that it may even be worthwhile to wait for such
> a change until PHP6 arrives so as to finally be able to uniformly support
> unicode at the same time as upgrading the architecture.

+1 to wait for PHP6

--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
[phone]  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>

--
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Cameron Perry-3]

Hi everyone,

Maybe I'm missing something somewhere, but is there any way to  
gracefully handle the fatal errors if a requested template function  
doesn't exist? For example, if {myfunc} is written into the template  
but function.myfunc.php doesn't exist there is a fatal error that  
kills the remainder of the page render. Is there any built-in  
functionality  in Smarty (though I didn't find it doesn't mean it  
doesn't exist) that would allow the script  to catch that error and  
treat it almost as if the {myfunc} function was never requested in  
the first place? I could see it being as simple as returning NULL for  
functions, or returning the text contained within the block function  
tags. If there's nothing like that in Smarty, is it something the dev  
team could/would consider implementing in a future release?

For me it matters because I'm writing an app that allows users/
content editors to add small page plugins to content areas. At the  
moment I simply plan on using a wrapper function that safely handles  
the above problem, but is still not my ideal work-around.
For example  (forgive any errors - this is just off the top of my  
head for demonstration purposes... and it's pretty late at night :-)

{* in the template *}
{callfunc name="weather"}

//---- function.callfun.php --
smarty_function_callfunc($params, &$smarty){
         if(function_exists("smarty_function_".$params['name']) {
                // call the function and continue
                // return output to template
        } else {
                return NULL;  //there would be an empty spot where that plugin was  
placed.
        }
}

//---- function.weather.php --
smarty_function_weather($params, &$smarty){
        //get local weather
        //fetch template & return
}

Any input is appreciated!

Thanks,
Cameron

--
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[boots-2]

--- Alain Williams <addw@...> wrote:

> On Mon, Jul 09, 2007 at 12:44:00AM -0700, boots wrote:
>
> > Smarty has consistently been a lowest common denominator type of library --
> > without a compelling rewrite that takes specific advantage of new PHP
> features,
> > I see no reason to abandon that at this time. What other PHP library still
> runs
> > as well on 4.0.6 as it does on 5.2.1 and every version between? Should
> Smarty
> > 2.x really demand 5.2+ when it can still easily support legacy users?
> >
> > I'd be happy to hear more on this issue from any interested parties.
> > ....
>
> The big problem is the 'long term support' offered by distros.
> Eg RedHat Enterprise 4 came out with PHP4 and so will continue to
> offer/support
> PHP4 for another 5 years or so.

Very good point. I suspect that even when a PHP5+ only version of Smarty is
realized, that PHP4 versions will continue to be maintained -- the big question
is by who and how. The pressing issue on that is resources. Of course, the
longer we stay with with a PHP4+ support mentality, the longer we avoid the
resource capability fracture. I'm not saying there aren't a lot of negatives
that go along with that but I do think that there are some justifiable
positives. Despite its popularity (and usefulness, IMHO) Smarty is a fairly
small project compared to PHP and so it may fall short of attracting the level
of developer attention that might be required to maintain multiple versions of
the project. Even with our active community, it seems that recently we have
been stretched for development cycles (except in those rare cases when a
security issue has arisen -- the dev team always treats those as priority 1
cases).

Again, I think this is an important point and I am glad that you raised it;
considering the discussions that are revolving around PHP4 on the internals
list, it seems that now is the time for folks in the Smarty community to speak
up on where they currently stand, where they expect to be and what sort of
support they expect or can contribute to in terms of the PHP4/5/x issue as it
relates to Smarty 2.x.

thanks!
boots

> If/when PHP4 becomes a museum piece (proposed 8/8/8) the RedHat support team
> will
> ensure that security fixes are back ported into the RedHat supported PHP.
> This is a good thing; it is exactly what people who pay for want - they want
> an
> unchanging platform so that their applications just continue to work.
>
> Since smarty is not part of the RedHat offering people who run RHE4 will be
> left
> with an unsupported component.
>
> The only way that we can do 2 different things is to fork smarty:
> * smarty museum: PHP4, only receives security fixes
> * smarty current: move to PHP 5.2
>
> I suspect that in 2 years time we will have the same discussion about moving
> to PHP 6. At that time we will fork again to have 2 museum branches.
>
> How long do we support stuff in the museum ? Probably 3-5 years.
>
> It is important to realise that the museum gets security fixes only. If you
> want a new feature you must upgrade. This is to keep the work load down.
>
> > PS. As an aside, it is my humble opinion that a rewrite of Smarty should
> target
> > PHP 5.2 as a minimum. I propose that it may even be worthwhile to wait for
> such
> > a change until PHP6 arrives so as to finally be able to uniformly support
> > unicode at the same time as upgrading the architecture.
>
> +1 to wait for PHP6
>
> --
> Alain Williams
> Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT
> Lecturer.

       
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow 

--
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[howard chen]

+1 GoPHP6

W should skip PHP5 and directly to PHP6 if we really want to rewrite
Smarty (for new coding styles, new OOP platterns, new features etc)

But after all, we should make sure our existing codes never break PHP4.

It is not our job to promote PHP5, isn't?
Anyway, is it too late...


Howa

On 7/9/07, boots <jayboots@...> wrote:
> --- Mark Rogers <mark@...> wrote:
> > Sebastian Mendel wrote:
> > > at least for phpMyAdmin, what i was talking about in last post, this is not
> > > correct, as we not just anymore "take PHP<5.2 compatibility into account"
> > > but actively remove code that was used to implement/simulate behavior from
> > > PHP 5 and introduce OO functionality not supported by PHP 4
> > >

--
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Sebastian Mendel]

just to clearify:

(for me) dropping support for PHP <= 5.2 does not mean rewriting the whole
code base, but more important making it more easier adopt new features
without taking care of old PHP versions -> this results in no completely new
code which will probably break old themes

btw. i think Smarty dev team is (currently) lacking man power to do a full
rewrite - and reducing supported PHP versions will also help the lacking man
power!


When developing on PHP 5 it would be very helpfull if major libraries like
Smarty would not flood the log with E_STRICT/NOTICEs when testing own
application


Just remembering: E_STRICT/NOTICE is used in PHP 5 to warn about possible
changes in PHP 6 too so it will help with transition to PHP 6 too.


Of course a Project like Smarty should still support a legacy version for
security fixes and possible minor bug fixes - but i think this is a low
effort task - at least for such a major app like Smarty is.


Some of the arguments mentioned here are exactly the reason for GoPHP5 ->
breaking the cycle! apps run in PHP 4 -> hosters provide PHP 4 -> lacy
developers do not fix there apps to run with PHP 5 -> hosters must provide
PHP 4 -> apps must run with PHP 4 -> hosters provide PHP 4 -> ... uh oh
thats wired!

The question is not how it helps YOUR project but how it HELPS THE
COMMUNITY! -> this resulting in helping your project!

Please read the reasons on gophp5.org carefully and linked discussions -> it
does not help discuss the same here already discussed 100 times on another
mailinglists (at least before reading through them).



btw. http://news.php.net/php.internals/30508


--
Sebastian Mendel

www.sebastianmendel.de

--
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php