Menu
▾
▴
Re: [Envolution-devel] File Prefix's
|
From: Eric B. <apa...@xe...> - 2003-08-27 21:14:07
|
Hello, This first statement will likely sound very harsh, but there is just not any= better way to put it. If you want to create pnModules and pnBlocks with the= Envo core go to PostNuke. These two projects are so very similar right now= because all that happens is one team comes up with a good idea and the other takes= and adapts it. I agree with the many people who have already stated that if this= continues we might as well just merge back with postnuke. Secondly, yes there currently is a central API called pnAPI. And yes it has= been developed for a long time with a lot of people using it. But it is also the= source of buggy and poorly written code that is essentially holding this= project back. Postnuke has realized this fact and has been working on a cleanup for= some time. The main goal of using pnAPI actually was not compatibility, it was to= give us a foundation until we could create a much better API. Now having= said that, the beauty of creating a central API with a compatibility layer is= that people creating pnModules and pnBlocks will NEVER know the difference. I'm sort of moving through your statement backwards here so bear with me.= You are probably correct that PN team isn't going to drop the pn prefix. That= makes sense because they are PostNuke, we however are not. This doesn't mean that= we plan on replacing it with an env or envo prefix. That is only a form of= branding our code and serves no purpose whatsoever. Now is where we get back to my original reason for wanting to drop the prefix, Code Management. Prefix's in= code are meant to separate packages (groups of code). It promotes better organized code and prevents accidentally re declaring functions. As far as removing the database prefix's, I will be the first to admit that= databases aren't my area of expertise. That is why I have consulted others= in the community that know what they are talking about, either they have a= degree in database design or that is their primary day job. These prefix's serve no= purpose except to brand the code, which is utterly pointless. Thanks for your comments though, my explanation isn't meant to be harsh,= just explaining where I am coming from. As I said before these changes will not affect anybody who currently writes or uses API compliant modules (ie:= modules that are not hacks). And it will also greatly improve performance and manageability. Eric Barr Project Manager :: E n v o l u t i o n On Wed, 27 Aug 2003 10:21:03 -0400, Sergey Alexandrov wrote: > Hello all, > > > Actually I do not see any points to remome prefix except one: > jump put of PN. Why? There are a lot of modules and blocks, > that was written for PN, using pnAPI, and a lot of ppl > continued write software for PN. Why you want to drop > compatibility? I'm sure, PN team not going to drop prefix. > Compatibility layer? Good idea. But why? For useing enoAPI, > envoHTML and so on? Ok, let's create compatibility layers for > all open source CMS you can find. Do you really need it? > Probably you, guys have to do a lot of work to cleanup code > before change compatibility level of Envo. What do you mean > "central api"? Guys, there are "central API" - this is pnAPI. > It was developed a long time, a lot of ppls are using it, and > you decided to destroy that? Why? To make Envo dominant? You > have to think more to start this work. Main goal of using pnAPI - > compatibility and it's not nessesarly to create additional > layer . If you want to, just create ENVO compatibility layer, > and write all you, guys want, but leave space for those, who > want to use Envo core with pnModules and pnBlocks. > > Don't forget to remove _pn_ prefixes from table and column > names - that will be "point of no return" for Envo. > > Thank you very much. > > > Serg aka Goblin. > > > Eric Barr wrote: > I am actually in the planning stages of such a system now. The goal > is to be able to have compatibility layers for any cms system that > uses a standard central api. There are several different ways to > approach this that I'm looking into and it will all boil down to > the method that is most efficient. Keep the suggestions coming in, > creative ideas like this are what we need around here! Eric Barr > Project Manager :: E n v o l u t i o n On Tue, 26 Aug 2003 > 18:40:30 -0400 (EDT), Mark Chaney wrote: I like the idea too, > couldnt there also be an compatibility layer or api that would be > able to tell old pn or env mods where to look for the current > api's, etc. Just an idea, but i know in the past we were looking at > somethig like that. -MACscr On Tue, 2003-08-26 at 14:03, > Eric Barr wrote: I would like to suggest the removal of > all prefix's such as "pn" and "env" from the filenames in the > codebase. Prefix's in my opinion should be reserved for package > naming. Does anyone else have an opinion on this? If so sound off! > Eric Barr Project Manager :: E n v o l u t i o n I > agree. But I also think we should go ahead and standardize on the > no- prefix thing for all code as well. Cause if the core code is > "prefix-less" most modules would require a rewrite anyway because > they will no doubt make calls to the old prefix code left over from > postnuke...for example pnAPI.php Zoom ----------------------------- > -------------------------- This SF.net email is sponsored by: VM > Ware With VMware you can run multiple operating systems on a single > machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual > machines at the same time. Free trial click > here:http://www.vmware.com/wl/offer/358/0 > _______________________________________________ Envolution-devel > mailing list Env...@li... > https://lists.sourceforge.net/lists/listinfo/envolution-devel > ------------------------------------------------------- This > sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ Envolution-devel > mailing list Env...@li... > https://lists.sourceforge.net/lists/listinfo/envolution-devel > ------------------------------------------------------- This > sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ Envolution-devel > mailing list Env...@li... > https://lists.sourceforge.net/lists/listinfo/envolution-devel > -- Thank you, -- Sergey Alexandrov ACT Inc. Tel: (770) 935-0300 > FAX: (770) 935-0303 email: se...@ac... --------------------- > ---------------------------------- This sf.net email is sponsored > by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf > _______________________________________________ Envolution-devel > mailing list Env...@li... > https://lists.sourceforge.net/lists/listinfo/envolution-devel |
