[UPHPU] PHP Framework Project Launch - Coders welcome to attend
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
* Time Tracker
* 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
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
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 Newbold MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com http://www.macnewbold.com/
More information about the UPHPU