[UPHPU] PHP Framework Project Launch - Coders welcome to attend

Mac Newbold mac at macnewbold.com
Thu Jun 2 09:06:55 MDT 2005


Today at 12:29am, BigDog said:

> I see php5 as i did with php3 moving to php4. Most people continued to run 
> their apps on php3 until they ported it all over to php4. But all new 
> development was done in php4 to leverage the new features. I think that since 
> we are developing a new framework we will want to have the future in mind and 
> use the newest stable release of php. however, this is a group decision and if 
> it was decided to use php4 that is fine. But the idea of even having php5 
> mixed in is a hard concept to manage. I would say that if you are doing some 
> in php5, then just do it all in php5.

That's how I feel about it too... if we're going to require php5, we might 
as well use it wherever it helps. But I'd like to avoid requiring it at 
all, at least in the core. If there's anything I wouldn't mind seeing that
requires PHP5, it would be an independent and optional module that works 
with the system.

> im wondering if i am missing the group concept of a framework on this. imho a 
> framework is a code base that allows developers to build web applications in 
> short amounts of time cause much of the basic stuff is done. From the list of 
> items i only saw a couple of items that seemed to fit into the framework. Is 
> this the right conclusion we are making with the term "framework".

I think I agree with you on this too. To quote from Victor's message with 
the notes from the meeting, here are my thoughts.

These are the kind of things that I think make this a framework:

* Login user / user permission verification (if failure HTML provided
for logging in)
* Insert sterile Data [not sure I understand what this means]
* skinable web design [I'd maybe call it "flexible", but skinnable works]
* admin on the page viewed by IP / logged status
* plugin capability for handwritten / new mods or apps
* Search Engine Optimization
* gzip header compression [this was mentioned very briefly]

To me, the goal is to get what you suggest: "a code base that allows 
developers to build web applications in short amounts of time cause much 
of the basic stuff is done."

Some of the stuff that we discussed went way beyond that, and in my 
opinion, should only be added after the core is done, and as an 
enhancement to make it easier to build web applications that happen to 
fall in categories like CMS, blog, client-management-system, and so forth. 
To me, they are not the core of the project, but peripheral.

These items I think are just bells and whistles that some people would 
like to see in it some day:

* RSS server
* Chat frontEnd (AJAX)
* Blog frontend
* Billing
* Time Tracker
* Calendaring
* RSS Backend
* Blog Backend

As an example, when this project is far enough along, I plan on using it 
to start out every new "web-app" site I build. Some of those would be 
e-commerce sites that sell products and have shopping carts. Some would be 
informational sites that need content management features. Many would 
involve some type of user account, whether they're required or optional, 
open to the public or for site admins only, or have 2 permissions levels 
("all" and "none"), or 250 possible permission levels, or 32 independent
permission bits.

To me, the framework should make all of those easy to get started. If it 
is something common enough that I can enumerate the features and 
capabilities that should be able to be configured for a given site, then 
it is a candidate for the framework.

After the core is done, things like RSS, Blogging, and so forth, could be 
worked into it, but honestly, I haven't ever needed to build a site that 
had RSS, Blogging, or Chat built into it. The closest was one site that 
wanted to tie in a PHPBB forum. So at most, I could say that about 2% of 
the sites I have worked on have needed a forum, but RSS, Blogging, and 
Chat aren't even on the chart yet, so I personally don't see them as 
priorities.

Another thing I'd like to avoid in every way possible is reinventing the 
wheel. The world doesn't really need Yet Another CMS/Blog/RSS 
generator/Forum/[Insert your favorite here]. If we need those features, we 
should probably be setting up glue to integrate existing good systems with 
ours, and leverage the work they have done and will likely continue to do.

The things that are going to be most generally useful to everyone are the 
things that are needed on a large percentage of PHP or PHP/SQL web sites 
overall. I think that's where we should focus. How many systems out there 
do you know of that target that market? If you can name even one, let me 
know, cause I'd like to check it out. Right now I'm stuck using all my own 
home-grown stuff, and so far, I can only afford to develop it as much as a 
client is willing ot pay for, which often stops at the same place their 
need for features and generality stops.

Sorry for the rant and long-windedness. I'm glad we're getting some good
discussion going. These are the kinds of things that need to be decided 
before we get knee deep in this project.

Mac

--
Mac Newbold		MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com	http://www.macnewbold.com/



More information about the UPHPU mailing list