[pLog-svn] Announcing SoylentX.com powered by a souped up Plog

[Oscar Renalias]

On 6/21/05, Allan Sun <sunajia at gmail.com> wrote:
> > THE BIGGEST PROBLEM with customizing Plog is one that every OS project
> > faces. I as the user/developer want to hack the core so I can make Plog 
> > do exactly what I want it to. BUT I also want to take advantage of
> > developments and new versions. How do I do this? (That's rhetorical, but
> > if you have any really good suggestions....) 
>  
>   
> I've been using the Plog framework to develop my own product for a long
> while, I got the same problem with upgrading the existing code with newer
> version of Plog core. I think it's  because the programme architecture is
> not cleared enough. 

I know, I know, but that's why the code is open... your help is always
appreciated :) If you find an class, method or pattern that could be
improved, get rid of or be added to the API, please let us know.

> I do realise it's because of the performance, we have to put more
> Plog-dedicated methods/ properties into a very generic class, e.g. Model/
> Template / View and even Action, the result is when I try to use the Plog
> framework to do my own project ( which is not blog related at all), I have
> to spend several hours on splitting the core from the Plog programmes and
> delete lots of the Plog only methods, and maybe change some methods to make
> more generic ( e.g the View, it's using BlogInfo, which is to special). 

I've just had a quick look at the most basic classes of our framework
because I had forgotten how they looked like :))) I noticed that
Action, View, Model and Controller do not have any dependency on
BlogInfo, UserInfo or anything like that. Perhaps you meant to say
that BlogView or BlogAction have a dependency on them? In that case,
you'd of course be right...

In a more general way, there are still lots of classes that do not
depend or are related to blogs: FormValidator, all the Validator
classes, all the Config* classes, and even Model. Those could be
easily reused in any other project if necessary.

> I've talked this is Oscar, and he said Plog is only a blog software, and the
> Plog team is not aiming to provide a general framework, which I think he's
> pretty right, so what I'm doing now is for each new project I split the core
> from latest Plog again and again. :P 
>   
> But I still wander that one day the architecture of Plog can go very clear
> and we can easily use the Plog framework to do the re-development. 

On this topic, I never said that I'm not 100% interested... :) In
fact, I'd love to see this happen.

My only concern is how much "re-development" will mean for us but if
you feel like it, I can even appoint you chief architect of the plog
core (so that I can concentrate on the "plog" aspect of plog :)) so
that you can get working on it. It's just a matter of getting the ball
rolling... At this point the release schedule for 1.1 has slipped to
probably late autumn, so this still gives us plenty of time to play
with things.

We can discuss what belongs to the core/framework and what belongs to
the application itself, and then start moving things around to
probably different folders, etc. This would also allow us to keep
separate releases for both the framework and plog itself, and even be
maintained by completely different persons if necessary.

If anybody is interested, I declare this discussion open :)

Oscar