[pLog-general] On php5...

[Oscar Renalias]

> I agree that php5 is not so popular by now, but things always change
> faster than our imagination:-).
>
> For a php5 branch of plog, I vote +1 and like to take care of it;-).
>
> Now, first step, how to name the new branch? any idea?

"plog-php5"?

>>> 2 Rename class name according to its real class name, borrowed from
>>> java. Such as, action.class.php -> Action.class. I rename the class
>>> name
>>> because:
>>> a) Borrowed from Java:-)
>>> b) I want to use phpunit2, and this is a must change.
>>
>> you mean, you transformed the class names to upper case?
>
> Yes, transformed most of the class by now, but not all, because I want
> to do step by step.
>>
>> Also, are you writing unit tests? If so, that sounds very good and 
>> it's
>> about time somebody did it!
>
> I DO think unit test is very important, also borrowed from Java.
> I have tested phpunit2, seems good, how about build out unit tests 
> based
> on phpunit2?
>
> Yes, writing tests maybe tedious, and time consuming, but the project
> will benifit from it in a long run view of point.

Well I don't have time to do that, I'd rather finish off 1.0 as soon as 
possible so no time for unit tests. But if you'd like to spend some 
time on that, go ahead :-)

>>> 3 Add module support, and move admin class,view and etc to
>>> modules/admin，sumamry action,view and etc to modules/summary,other
>>> module can be added too. More generally, I think only plog core 
>>> classes
>>> should be putted into class directory, others should be treated as
>>> modules or plugins.
>>
>> I don't quite agree with this but I think we could discuss about it...
>
> If only considering blog system, moudle support maybe redundent. I want
> to add module support because:
>
> 1 New branch of plog will not only a blog system, but also an
> application framework for php to develope more complex system.
> 2 Module support is easy to implement:-)
>
> But, I have no idea which is suitable,module or plugin?

Sincerely, I don't like it.

Plugins is a concept that we're using to expand the functionality of 
plog itself by adding new menu entries (in 1.0) or exporting additional 
objects to the templates, etc. I also don't see how a "module" works or 
it is defined.

But if all you want to do is separate the base code of the framework 
from the code of plog, as a blogging tool, then we just need to 
rearrange the directory structure a bit.

Finally, there is already a framework that was spun off from the 
post-0.3 code of plog, but it hasn't gone quite public yet. I have to 
say that the idea didn't quite work out, and to tell you the truth, I 
don't feel like going through the same hassle again. Different people 
have different ideas about how things should work, etc, and plog was 
supposed to be the flagship application of the new framework but in the 
end we had to call the whole thing off (well, the framework is out 
there but plog was never integrated into it) because it was too 
difficult.

As a personal opinion, I have noticed that in order to build a powerful 
framework you have to make a lot of generalizations since that's the 
point of a framework: try to be the base for many applications as 
possible. And when you want to build an application, you have to ignore 
most of all generalizations and build concrete, precise things. It is 
indeed true that plog is built on top of its own framework, but it's a 
framework that has developed overtime and most important of all, 
focused exclusively on plog. I think plog's framework should stay that 
way, focused on plog and nothing else.

Also think about it, we also do not need to carry the burden of 
additional things that should be part of the framework when plog 
doesn't really need any of them, do we?

All in all, I would vote -1 against it...

>>> 4 And, I give up log4php,but using PEAR::Log, because I just can not
>>> make log4php work under php5:-(, but PEAR::Log works fine.
>>
>> There are several classes borrowed from PEAR in the code but I have
>> never been very fond of PEAR as a framework itself. First of all,
>> because plog is already based on its own framework so we already have
>> our own Object, Execption, etc classes, there is no need to carry the
>> burden of additional PEAR, PEAR_Error, etc classes. If you take a look
>> at things like class/data/Date.php, or class/xml/parser/Parser.php,
>> you'll see that I spent some time removing all references to PEAR in
>> them...
>
>> Also, another negative opinion about PEAR:
>> http://www.sitepoint.com/blog-post-view.php?id=172065
>>
>> What was the reason for log4php not to work in php5? I understood that
>> the last version was supposed to work fine... I liked the package very
>> much and I don't think we should get rid of it just like that!
>> Specially after you recommended it so strongly!!!
>>
>> Would you care to reconsider your decision?
>
> In fact, I also prefer to log4php, but I can not make log4php works
> under php5. If anyone help to point out how to run log4php under php5,
> many thanks in advance:-)
>
> And, for PEAR::Log, this is just a log utility, very similar with
> log4php, but much smaller than log4php.
>
> I think before log4php can work under php5, we can use PEAR::Log as our
> log utility for php5 branch plog(again, we need a name for this
> branch:-)). And when log4php is ready for php5, replace PEAR::Log with
> log4php is very easy, just change few codes of object class, all other
> class will not be involved in.
>
> In another word, PEAR::Log is the only PEAR package I added to the new
> branch, and can be treated as a temperary solution.

Can't we try to fix log4php? Have you tried contacting the author? 
Perhaps he's got a new version coming out soon to solve all the 
problems with php5?

>>> I'd like to open another thread to discuss porting plog to php5, 
>>> anyone
>>> interested in it?
>>
>> We can consider this first message as the start :-)
>
> PS, how about write some documentations for the new branch, such as
> roadmap, code style guide and etc?

roadmap --> The 1.x releases (as many as needed) should be based on the 
current codebase with minor fixes to make it *just* work under php5. 
The 2.x branch should be based on the new development tree making use 
of the newest OOP features in php5.

But keep in mind that we haven't even released 1.0 yet and we're 
already talking about 2.0... :-)

new branch --> I say we call it "plog-php5", or something like that :-)

coding standards --> 
http://www.plogworld.org/wiki/index.php?pagename=Coding%20guidelines

anything else? :-)

Oscar