Re[2]: [Envolution-devel] File Prefix's

[Furbo <fu...@si...>]

From my point of view i see it like this...

does pnAPI (all of the pn prefix stuff) HAVE to be replaced for the
current envolution code base, maybe not.. but would it allow
improvements if its removed, Yes!.  I will explain.

I will get into the technical debate over changing the api in a second
but first:
From a simplest point of view WHY would one project be dependant on an
API of another project's?? Is pn a library like smarty or adodb that
is meant to be used that way as a whole?  NO, its an application. its
internal parts are 'meant' to be used by itself.  envolution,
postnuke, xaraya (somewhat), and now max-dev are all similar (some almost
identical) in a lot of ways but why does any of them have to only
support the postnuke API?  why not actually improve on it (if they
can) and not just copy new PN work with every version.

ok the technical about the APi, and prefix: by having a project create
its own API it allows any project the freedom to do things in its own way.
to add enhancements, (both performance and security) and new
features.. it also allows for certain 'incorrect' coding ways to be
fixed.. by limiting any project to the api of anothers only you stifle innovation.
IF envolution (and all the pn forks) want to still offer
compatibility, then implementing a layer for all the pnXXX apis is a good thing..
Does that mean envo (or any project) has to create api layers for all
the CMS projects? NO.. but since, at least now, postnuke seems to be
the most developed for why not just make a wrapper for its api.

People have always argued/debated over weather envo (and all other pn
forks) are real CMS projects or just PN with a few modules.. well
creating an original API is a first step to truly offering features
that pn does not have..

YES, The pnAPI layer is a mandatory thing to be created for the new
api because of all the blocks/modules that rely on it now.. but future
modules could be coded just to envolution's api and take advantage of
any new 'bells and whistles' that Eric and the devs come up with.

Now for the Database prefix stuff:
Their is a db layer, pntables that abstracts any physical table/column
name from code.  THis was originally done to allow for the db to
change and not always effect the code AND to help devs a little.
all the nuke databases are HORRID!   No column needs a pn_ or a envo_
before it..   table prefixes are one thing, but the column naming is
pathetic for them all.
Look at the databases *column* prefix like this: when someone comes up
to you and asks "what is your name?"  its like saying what is the name column
from the user's table right??      you think to yourself, what is my
name and give it back, right?.    You DONT think, what is my pn_name or what
is my man_name..   its your Name.. prefixes are POINTLESS, you know
what it is the name of.. its the user table
Im not even going to get into the rest of the db issues (indexes,
foreign key naming, primary key naming, types, etc) as i could write a
book


In short my point is, prefixes are useless if EVERYTHING has the same
prefix. (column or API)  A prefix helps to distinguish two similar things apart.
Make an envo Api!! and make it great. Do what is needed for envolution to run with it.
Create a pn wrapper API for those pn modules to run too, play nice
with the 'parent' cms if you can.
and please, please... when it comes to the db.. ASK someone to help
you with creating tables..  the end users and other devs will thank
you when things are easy to understand, and properly setup for
performance.  an index is a terrible thing to waste.



-- 
Furbo

Computers are useless. They can only give you answers.
  -Pablo Picasso