php-general Digest 31 Oct 2012 02:53:43 -0000 Issue 8026
Topics (messages 319617 through 319623):
Re: TURBOPY cloud framework + IDE beta available NOW
319617 by: Johannes Reichardt
319618 by: Lester Caine
319619 by: marco.behnke.biz
319620 by: marco.behnke.biz
319621 by: Johannes Reichardt
319622 by: Lester Caine
Re: list of places to learn programming online
319623 by: tamouse mailing lists
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
From what I see most of your concepts are not up to date of how you
would do things now.
This starts with simple "leave brackets on if else single line
conditions" which is from my point of view a no go and ends with using
static calls instead of instances.
Thank you for your feedback.
Especially the static calls improve code quality a lot in my opinion.
But it is different to common standards, I am aware of that.
And why PHP 5.2?
Why not? With some tweaks it would work on PHP4 but for the sake of security
it uses some filter_var methods that are 5.2 specific.
And I am curious if you have developed a real templating engine or if
you are going by eval()? From what I see, it looks a bit like that.
Yes, that is the default. But hardly any impact on performance. For
Websites with
highest traffic it would be simple to write out the controller code
instead of storeing it in the db only,
other ways would be stream sockets that allow "including" of db pages.
But these are only my points. I browsed the pages, had no insight on the
code.
But I like your concept on the in place editing, that looks pretty cool
and handy.
Thank you. Maybe you want to download and install it some time, would be
glad to get more feedback from you :)
- Johannes
--- End Message ---
--- Begin Message ---
Johannes Reichardt wrote:
And why PHP 5.2?
Why not? With some tweaks it would work on PHP4 but for the sake of security
it uses some filter_var methods that are 5.2 specific.
And since 60% of the world is still stuck with ISP provided hosting on PHP5.2 or
less it does 'widen the market' ...
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--- End Message ---
--- Begin Message ---
Lester Caine <les...@lsces.co.uk> hat am 30. Oktober 2012 um 11:07 geschrieben:
> >> And why PHP 5.2?
> > Why not? With some tweaks it would work on PHP4 but for the sake of security
> > it uses some filter_var methods that are 5.2 specific.
> And since 60% of the world is still stuck with ISP provided hosting on PHP5.2
> or
> less it does 'widen the market' ...
Ok, I can take that point. I haven't installed anything on a shared host for a
while. Always working with VServers.
Johannes Reichardt <johannes.reicha...@googlemail.com> hat am 30. Oktober 2012
um 10:24 geschrieben:
> > From what I see most of your concepts are not up to date of how you
> > would do things now.
> > This starts with simple "leave brackets on if else single line
> > conditions" which is from my point of view a no go and ends with using
> > static calls instead of instances.
> Thank you for your feedback.
> Especially the static calls improve code quality a lot in my opinion.
> But it is different to common standards, I am aware of that.
In times of testability and several design patters, the use of static calls is
really outdated.
I understand that you can read and write the invocations of the methods much
faster, but you should think more to the future on that point.
> > And I am curious if you have developed a real templating engine or if
> > you are going by eval()? From what I see, it looks a bit like that.
> Yes, that is the default. But hardly any impact on performance. For
> Websites with
> highest traffic it would be simple to write out the controller code
> instead of storeing it in the db only,
> other ways would be stream sockets that allow "including" of db pages.
The/my problem with eval() comes from a security point of view.
> Thank you. Maybe you want to download and install it some time, would be
> glad to get more feedback from you :)
Yeah, you known, I love to, but there are 29+some other project I want to do as
well.
For now I'll stick to I am doing right now and try to finish it first ;)
Marco Behnke
Dipl. Informatiker (FH), SAE Audio Engineer Diploma
Zend Certified Engineer PHP 5.3
Tel.: 0174 / 9722336
e-Mail: ma...@behnke.biz
Softwaretechnik Behnke
Heinrich-Heine-Str. 7D
21218 Seevetal
http://www.behnke.biz
--- End Message ---
--- Begin Message ---
Sebastian Krebs <krebs....@gmail.com> hat am 30. Oktober 2012 um 16:20
geschrieben:
> 2012/10/30 ma...@behnke.biz <ma...@behnke.biz>
>
> > Ok, I can take that point. I haven't installed anything on a shared host
> > for a
> > while. Always working with VServers.
> >
>
> And if you want to take your job serious, thats definitely the way to go. I
> don't think it's useful to give the ISPs a legitimation to stay forever on
> outdated (5.3 exists since 06/2009, last 5.2 is from 01/2011) and
> unsupported (12/2010) (and therefore probably insecure) versions neither by
> tolerating their update-laziness, nor by providing software, that encourage
> their update-laziness. ;) Just my two cent, but really 5.2? 5.5 is
> (loosely) scheduled for Q1 2013 ;)
That is why I go for 5.3 at least.
And would recommend that to everyone, reasons mentioned above!
but I do get the point, that if you want to have customers using your product,
and they have access to 5.2 only, then you have to support it somehow.
But you can also take a look at others projects like TYPO3, they force you to
use PHP 5.3 to be up to date
--- End Message ---
--- Begin Message ---
In times of testability and several design patters, the use of static calls is
really outdated.
I understand that you can read and write the invocations of the methods much
faster, but you should think more to the future on that point.
I am not sure if that is true for TURBOPY. It has been "organically
grown" over the years
and I had no scenario where I needed instances. The benefit of more
compact code is worth
it for this scenario I think. The nature of a server request is still
very procedural.
The/my problem with eval() comes from a security point of view.
Yes that is true, if you enable the templating language it is not safe
anymore.
If you take care of that it is ok, but you have to know about it.
Your points are interesting and they let me explain what TURBOPY is not:
Just a framework like the ones you are used to. Its concepts differ a
lot from
other frameworks, like the idea of "accessibiliy over convention" for
example.
With TURBOPY I try to bring back more creativity in the developing process,
allowing you to reach goals in less time.
- Johannes
--- End Message ---
--- Begin Message ---
Johannes Reichardt wrote:
In times of testability and several design patters, the use of static calls is
really outdated.
I understand that you can read and write the invocations of the methods much
faster, but you should think more to the future on that point.
I am not sure if that is true for TURBOPY. It has been "organically grown" over
the years
and I had no scenario where I needed instances. The benefit of more compact code
is worth
it for this scenario I think. The nature of a server request is still very
procedural.
The/my problem with eval() comes from a security point of view.
Yes that is true, if you enable the templating language it is not safe anymore.
If you take care of that it is ok, but you have to know about it.
Your points are interesting and they let me explain what TURBOPY is not:
Just a framework like the ones you are used to. Its concepts differ a lot from
other frameworks, like the idea of "accessibiliy over convention" for example.
With TURBOPY I try to bring back more creativity in the developing process,
allowing you to reach goals in less time.
I've been in much the same mode with bitweaver for a number of years. We have
reworked all the code so that it is 'clean' on PHP5.4 but many users ARE still
tied to ISP's who having tried to move to PHP5.3 they have rolled back to 5.2
because so many sites simply stopped working! I've been trying to get at least
some interest in working out what setup of PHP5.3 will continue to run existing
5.2 code without the problems ISP's are encountering, but in many cases their
users are not 'code junkies' and just want things to work as they did. Changing
things in PHP5.3 so they could be killed in 5.4 was somewhat short sighted so we
are now in a situation where ISP's can't simply wipe out their customers sites
so they are stuck supporting and unsupported version of PHP :(
As long as PHP5.3 and 4 are installed WITHOUT using the default configurations,
then one can get most legacy sites working fairly cleanly, but its the messages
being created in the background that cause an extra load on ISP's and that need
to be cleaned up again. The problem is that there is no pressing need to switch
over since the old code IS working fine?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--- End Message ---
--- Begin Message ---
Fascinating. This kicked off the spam blocker
On Tue, Oct 30, 2012 at 7:38 PM, tamouse mailing lists
<tamouse.li...@gmail.com> wrote:
> This just hit my inbox from another source. I haven't had any time to
> vet the list, but here is the link to the post:
>
> <
thenextweb DOT
com/dd/2012/10/21/so-you-want-to-be-a-programmer-huh-heres-25-ways-to-learn-online/>
--- End Message ---
