| php 5 |
Thu, 09 September 2004 06:24  |
|
I am moving this here because pm threads are... not threaded 
I think this looks like a great start! The top level classes have been modified and these changes could fairly easily be pushed down into widgets/forms etc. I can't test this because I don't have php 5 installed anywhere but it looks good.
Reworking the include set up (and getting files to end in .php) would be another nice addition.
I think one of the biggest problems is going to be the logistics of the transition. I don't think anyone wants to maintain a php 4 version and php 5 version simultaneously. The small, day-to-day bug fixes have to go on the version currently being used-- i.e. php 4. When are you planning to upgrade?
Trying to work on this before production is running or transitioning to php 5 is not going to be very productive.
culley
|
|
|
| Re: php 5 |
Thu, 09 September 2004 10:33  |
|
I think the biggest challenge is to try and adopt as much of php5's new OOP features as possible, and yet keep the API changes to a minimum to help migrating to 3.0.0 of phphtmllib easier. I have a vested interest in doing that as I use phphtmllib at my job.
As far as the includes go, I'm not sure the best way to solve it. I could create static methods in the base class that could be called to do the includes, but that in itself causes other problems, namely scope issues.
It would be nice to just do
phphtmllib::include_forms(); //to include just the form engine
phphtmllib::include_html_widgets(); //to include just the html widgets
It might be worth a try, but I'm sure since the includes would happen inside of a function, scoping issues would arrise.
|
|
|
| Re: php 5 |
Thu, 09 September 2004 11:16 |
|
I hadn't even thought about BC problems... But of course maintaining BC is critical.
Isn't this "first draft" getting more and more out of date with each commit? It would be nice to have it in a branch so updates to the trunk could be ported across. Who knows how big of a nightmare that would be as the php 5 branch drifts away.
It is hard to put a lot of energy into this when the implementation is to be done "someday...". I suspect it wont happen till your work decides to upgrade.
The static method approach to includes sounds ideal. Individual widgets could even be included with include_widget('name')
Do you think the scoping issues would show up within the library itself or client code? Client code could just deal with it by calling the methods whenever scoping problems pop up.
culley
|
|
|
| Re: php 5 |
Thu, 09 September 2004 11:28 |
|
I think for the most part the base classes were the only thing that I had modified in that test port. So I was thinking I could branch at the next official release, and then only put bug fixes in the 2.x tree from the on out, and put all of the real development into the 3.x tree. It's basically how the php team does their major changes.
I'm not sure at this point what else should be changed for 3.0. All of the helper functions that live in tag_utils dir can probably stay the same no? I had thought about a little bit of reorginzation of the file layout. Basically break everything up into html classes/utils, xml classes/utils, etc. etc.
It's not that big of a deal though.
I'm open to anything at this point. I just want to try and maintain BC as much as possible.
|
|
|
| Re: php 5 |
Thu, 09 September 2004 12:45 |
|
Ambitious! Are you going to migrate you work to php 5 when you branch? It seems like it would be difficult to branch otherwise.
I would probably have trouble contributing to the php 5 branch till we are running php 5. The changes I make are usually work related. If work is runing php 4 and I need to change something then committing to the php 5 branch is going to be complicated.
We *want* to run php 5 but it still seems a little early. zend.com is still running php 4 
culley
|
|
|
| Re: php 5 |
Thu, 09 September 2004 13:47 |
|
I am trying to push php5 here at work. We have a small patch release going out in 2 weeks, and then another fairly short release cycle of 1 month after that which we will definetly still be php4. After those 2 short releases I definetly want to move to php5. I am most likely going to be building a C++ reporting server for our product and want to use SOAP to communicate with that server. PHP5 has a nice new SOAP extension built in, which I have played with and seems to work I have a couple of other guys in the team here at work already buying into it, its just a matter of writing a testbed app for it and proving it to mgmt.
So I have php5 plans in the somewhat near term. I have already ported our main product to php5 and it seems to work with very little changes. So If php5 itself is stable, then I don't think it would be very hard to get the rest of the team to commit to it.
|
|
|
| Re: php 5 |
Thu, 09 September 2004 16:17 |
|
PHP5 has __autoload(), which could solve all of the phphtmllib include problems. All you would have to do is override that function. Then when php tries to instantiate the class, which is undefined because it hasn't been included, the __autoload() will get called, and then you just include_once() the appropriate file.
We could even provide a function that could get called by the user of phphtmllib that will load the appropriate files w/in phphtmllib.
Say the user just instantiates the DefaultGuiDataList,
phphtmllib::__autoload() could get manually called from the global __autoload() call that the user of phphtmllib writes. Then phphtmllib::__autoload() will try and determine if the class is owned by phphtmllib, and then include it based upon the global $phphtmllib var?
Then all the user would have to do is write
function __autoload($classname) {
//check for app includes here
....
//ok check for phphtmllib's includes
phphtmllib::__autoload($classname)
}
|
|
|
| Re: php 5 |
Fri, 10 September 2004 07:09 |
|
__autoload() sounds like it was built to solve exactly this problem. Unfortunately the php documentation seems to have some trobles with this page:
http://www.php.net/manual/en/language.oop5.magic.php
so I can't read the official docs on it. 
Will each class need an __autoload() method that includes everything it needs? i.e. does ATag need it?
I need to get php 5 running somewhere...
culley
|
|
|
| Re: php 5 |
Fri, 10 September 2004 18:16 |
|
|
No, you only need to define 1 global __autoload() function and do all you need to do inside that. So I think 3.0 could provide a function that could just get called inside of the __autoload() method that could do all of the autoload includes for phphtmllib.
|
|
|
|
| Re: php 5 |
Thu, 21 April 2005 08:47 |
|
I was actually thinking about doing something like that after seeing some of the SimpleXML extension features at the MySQL conference. Andi Gutmans gave a good talk on php5 and showed off some of SimpleXML's features.
One of the nice features of phphtmllib is that it outputs very readable html code if you want it to. Is there a way to tell the DOM how to indent the resulting xml?
There are a couple caveats to the nicely formatted output, one of which is the <textarea> tag can't be indented or the content will render indented inside the textarea visible to the user. So I would still need to have control over how certain tags get rendered. Also, there are times when you actually don't want whitespace between 2 certain tags because the browsers fail to render them properly. I've run into this with <img> tags.
This is why I have the set_collapse() method as well as the no newline after open tag function as well. I guess the point is that we still need ultimate control on how the tags get rendered. I just wonder if there is a way to control that with the new DOM object somehow?
[Updated on: Thu, 21 April 2005 09:09]
|
|
|
| Re: php 5 |
Thu, 21 April 2005 09:55 |
|
ok I have been messing around with your example and trying to modify it to see if I can somehow create the same API that phphtmllib already provides, and it seems that the Dom objects are readonly for the most part and can't really be extended. I tried to do something as simple as
class test extends DomElement {
function test($tagname='name', $attributes=array()) {
parent::__construct($tagname);
foreach($attributes as $name => $value) {
$this->setAttribute($name, $value);
}
}
}
I get fatal errors on the setAttribute() call, which is very very lame, and makes it pretty much useless. It seems you have no choice but to put the DomElement objects into a DomDocument before you can manipulate them at all, which is inflexible and dumb IMO.
There needs to be a way to provide the same phphtmllib API or using the DOM is basically useless to me. I have many many apps that use phphtmllib now and I can't afford to have to rewrite everything to conform to a Dom API, which basically just throws all the widgets, classes of phphtmllib in the toilet.
|
|
|
|
| Re: php 5 |
Thu, 17 May 2007 23:48 |
|
unfortunatly not. phphtmllib 3.0.0 is a new beast all together.
I went ahead and made it into a full blown framework now and a lot of the older 2.x apis have changed....for the better.
|
|
|
Members
Search
Help
Register
Login
Home
E-mail to friend 
]