Menu
▾
▴
envolution-devel — Envolution Development List
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(2) |
Feb
(48) |
Mar
(17) |
Apr
(13) |
May
(102) |
Jun
(163) |
Jul
(203) |
Aug
(185) |
Sep
(16) |
Oct
(4) |
Nov
|
Dec
|
|
From: Mark C. <ma...@ma...> - 2003-08-28 16:37:36
|
LOL, i probably will. I love making templates. Hey, just and idea, but would it be possible to load the comments api in any module by just adding something like [-$COMMENTSAPI-] anywhere in a template for the module. That way you could use the template to actually place where you want the comments to appear. Also, the comments api would need templates themself so you can design how you want them to look. For example, i have a news page on a site that it would be very useful to load the comments on the right side, in a column fashion, only load them flat, and limit the characters of each comment to maybe 150 or so. -MACscr ----- Original Message ----- From: "Andrei Kivilev" <ak...@ho...> To: <env...@li...> Sent: Thursday, August 28, 2003 7:19 PM Subject: RE: [Envolution-devel] File Prefix's > >ak, if u dont remember me, i was the layout manager for envo before i > got > >deployed to iraq, so of course i love this stuff. =P > > > >-MACscr > > Hi Mark, > > I do remember you promised to create all templates for all modules I > write ;) > > Best Regards, > > ak > > > > > ------------------------------------------------------- > 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 > |
|
From: Andrei K. <ak...@ho...> - 2003-08-28 16:19:40
|
>ak, if u dont remember me, i was the layout manager for envo before i got >deployed to iraq, so of course i love this stuff. =P > >-MACscr Hi Mark, I do remember you promised to create all templates for all modules I write ;) Best Regards, ak |
|
From: Mark C. <ma...@ma...> - 2003-08-28 16:03:34
|
ak, if u dont remember me, i was the layout manager for envo before i got deployed to iraq, so of course i love this stuff. =P -MACscr ----- Original Message ----- From: "Andrei Kivilev" <ak...@ho...> To: <env...@li...> Sent: Thursday, August 28, 2003 6:48 PM Subject: RE: [Envolution-devel] File Prefix's > > > >"UI usability team" > >That sounds like me =P > > Hm... I think we have a volunteer for UI usability team :) > > Eric, take a note ;). > > Best Regards, > > ak > > > > > ------------------------------------------------------- > 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 > |
|
From: Furbo <fu...@si...> - 2003-08-28 16:01:37
|
Along with the idea of utility modules. What about hooks? to be used to access them?? i dunno.. I can say that i know PN IS working on an improved hooks implementation (i dont know all the details) but hooks was always meant to be the 'glue' that allowed modules to call 'utility modules' I do not speak of the pn hooks as a 'envo must take theirs' or anything but only maybe see how they may be doing it.. or something.. envo is still similar to pn.. IF they are doing something envo and PN people could work together to maybe solve a problem? who knows -- Furbo Computers are useless. They can only give you answers. -Pablo Picasso |
|
From: Andrei K. <ak...@ho...> - 2003-08-28 15:48:50
|
>"UI usability team" >That sounds like me =P Hm... I think we have a volunteer for UI usability team :) Eric, take a note ;). Best Regards, ak |
|
From: Andrei K. <ak...@ho...> - 2003-08-28 15:48:49
|
Since we finally got into code development discussions here, this would be a good time to actually start working on all the exciting things we would like to see in envo. I have compiled a list of things I would like to see as utility modules or API extensions (we should make a decision on naming, btw). We can share our ideas in this thread, and I will recompile the list to incorporate ideas at least once a week. When we think we got the basics down, I will post it on the forums to get even more feedback. So, here is the first iteration of Utility Modules Wish List :) ***Content Utility Module: Global content registration. Whenever a piece of content is created by any module, it is registered with Content Utility Module. Unique ID assigned by Content Utility Module is a universal identifier for everything created by modules. Permissions, category assignment, comments and ratings assignments as well as notifications can be tied to this unique global ID. Required Components: -unique content id from the module content belongs to. -name to be displayed for associated content id -module name (or module ID) (to associate content to the right module) -language ***Category Utility Module Global categories tree for content that was meant for browsing based access. Required Components: -category id to uniquely identify content within categories tree. -parent id for categories tree structure -unique content id from Content Utility Module to point to actual content. -type to identify if a given category id content pointer or another category. -language I am currently working on these two modules. Actually, they are combined into one, but I am planning to separate them into two separate entities. The following Utility Modules are just concepts :). I don't have any code for them yet. ***Comments Utility Module Comments facility that can be assigned to any content id. Required Components: Ability to do display threaded, nested and flat styles (probably through parent id and group id) ***Ratings Utility Module Ability to rate any piece of content. Required Components: -ability to compute composite rating. -ability to have either scale or good/bad rating for any content type -ability to display number of good and number of bad votes (The more I think about it, it looks to me that having two different ratings utility modules might be better) ***Private Messaging Utility Module Should at least provide the same functionality current PM module provides. ***Notification Utility Module Can let you associate user ids with content ids and raise alerts if a given action has been performed (like content being assigned to a given category, or content modification or deletion). ***Email Utility Module Should handle email messaging for envo. Can be invoked whenever specified alert is triggered by, for example, Notification Utility Module. ***XML-RPC Utility Module Should provide interface (abstraction layer) for functions (methods) designed for remote access (or allowed to be accessed remotely) ***SOAP Utility Module Same as XML-RPC but for SOAP protocol ***Backup Utility Module A tool to backup not only entire database, but separate tables (per module for example) and use Email Utility Module to mail a copy to site admin. ***RSS Utility Module Should provide an easy tool to convert any content into an XML file suitable for RSS feed. That is all I can think of for now :). Feel free to through in additional Utility Module ideas. The more the better :). When you reply with suggestions, please use <name> Utility Module at the beginning of your comment. Will make my life a lot easier. Best Regards, ak |
|
From: Mark C. <ma...@ma...> - 2003-08-28 13:27:32
|
>"UI usability team" That sounds like me =P ----- Original Message ----- From: "Andrei Kivilev" <ak...@ho...> To: <env...@li...> Sent: Thursday, August 28, 2003 2:20 PM Subject: RE: [Envolution-devel] File Prefix's > Hi Mark, > > I really think templates should be used wisely. Some people (especially > me), really lack design skills. IMHO, we need a "UI usability team" that > will make sure consistent "look and feel" is achieved for official Envo > distribution. The same goes for DB, by the way. I think we have enough > talented people here to make envo much better :). > > As for Comments API and other "enhancements", they can be thought of as > "utility modules". Such modules expose their methods (functions) for > other modules to use. This makes them very close to the API we are using > now. What we need to do is carefully plan any such utility modules. Get > developers and users feedback. And only after they are of production > quality, we should consider including them in our stable releases. OOP > approach might make it a little easier to understand and maintain, IMHO. > > As for rewriting modules, I think we should do API first. After we get > usable API with at least basic things in it, then rewriting "core" > modules will be much easier and time efficient. > > Best Regards, > > ak > > > > > > ------------------------------------------------------- > 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 > |
|
From: Andrei K. <ak...@ho...> - 2003-08-28 11:21:12
|
Hi Mark, I really think templates should be used wisely. Some people (especially me), really lack design skills. IMHO, we need a "UI usability team" that will make sure consistent "look and feel" is achieved for official Envo distribution. The same goes for DB, by the way. I think we have enough talented people here to make envo much better :). As for Comments API and other "enhancements", they can be thought of as "utility modules". Such modules expose their methods (functions) for other modules to use. This makes them very close to the API we are using now. What we need to do is carefully plan any such utility modules. Get developers and users feedback. And only after they are of production quality, we should consider including them in our stable releases. OOP approach might make it a little easier to understand and maintain, IMHO. As for rewriting modules, I think we should do API first. After we get usable API with at least basic things in it, then rewriting "core" modules will be much easier and time efficient. Best Regards, ak |
|
From: Mark C. <ma...@ma...> - 2003-08-28 09:29:50
|
Very well said ak. I also agree about the absense of a Comments API and a Ratings API. Both would be very useful to me. I also agree with the idea of keeping api compliant downloads and just thrown together ones seperate. BTW, as soon as the Reviews and Downloads module are api compliant and templateable i have some templates for them. I have a great design for both that could be the default layout on install. But of course users can make them whatever they want, just thought a good default layout would be useful. I know cleaning the code is the main priority right now and not features, but just wanted to share a little bit of ideas. I would almost call the code cleanup a rewrite. Why you ask? Because I feel a lot of the code is a mess. Lots of hacks and quick fixes. I know I am guilty myself of making these quick changes to maybe add a small feature to a module or a change to the layout (full templates will fix this) that isnt as efficient as it should be. Keep all the same features for now, but make all core modules api compliant and take advantage of templates just like they should. Take out modules that arent part of the core. If its not a core module (and api compliant of course), we shouldnt include it in the standard download. I know PN is using the encompass code (Xanthia) for .726 and an even better version for pn .8, so i think we can learn a lot from their changes they made to our code. Looks like they are making it a little more effiecient and have added a few options as well. I have a lot of other ideas that I think will help with the code cleanup and rewrite. I also have a lot of ideas on how to reorganize how changes are made to made to different settings of modules, blocks, and encompass. Basically making it easier to make the all the possible changes to a block or module at one central point. Not all at the same screen, but not having to back out of one module to get into another to make a change to the module you were just at. LOL, not sure if you follow, but I will give some visual examples later on. Sorry, i know i jump around a lot with what i am talking about, but hopefully you still understood the jist of what i was trying to say. I talked about feature freezes, but then also added ideas about new features. These of course can be used after the major cleanup is done. -MACscr ----- Original Message ----- From: "Andrei Kivilev" <ak...@ho...> To: <env...@li...> Sent: Thursday, August 28, 2003 11:21 AM Subject: RE: [Envolution-devel] File Prefix's > Hi guys, > > First of all, this comment is not addressed to anyone in particular. > Thus, it should not be taken as any sort of personal attack. > > Now, here is what I think about Envo and PN in their current (released) > state. Both are platforms, and provide common features, like user > management, multi-lingual interface and consistent themes. THAT IS IT! > Oh yeah, and one "integrated" application on top of that, called News! > So, IMHO, at the moment Envo = PN = News module. Most other differences > are in presentation layer. BTW, how many Envo installations disable News > module or at least do not make it the default one? And even this "core" > module is NOT pnAPI (or any other API) compliant. On the other hand, 3rd > party modules that are announced on Envo and PN sites most of the time > claim to be 100% pnAPI (an exception might be pnHTML, but it is a > completely different story). The reason is simple, PN (and its forks) > had promised to support all modules that are pnAPI compliant. So, IMHO, > it is of paramount importance for Envo to support pnAPI as it promised > (if technically feasible, of course). On the other hand, I am all for > "new" envAPI (or whatever we call it). It should take good ideas from > pnAPI and add new features that will make creating modules for Envo > easier and less time consuming. What I don't understand is why we still > don't have Comments API or Ratings API or Notification API. I am sure > most 3rd party developers would love to use these APIs in their own > modules. After all, API is THE ONLY WAY for modules (blocks, or anything > else) to interact with Envo. The same goes for Workflow. And Categories, > and everything else. The question is, do we make a "bridge" between > pnAPI and envAPI? I think not. This is not our job to integrate PN based > modules with all the features Envo can provide. All we ever promised is > that PN modules will not break because some of pn-something functions > can't be found on an envo install. Furthermore, I would suggest we make > all compatibility things into separate downloads, and make sure that > users understand that by using them we can't guarantee that Envo install > with these add-ons will perform as fast as the "clean" one. Think of it > as Wine on Linux. You only use it when there is no alternative, period. > > > Best Regards, > > ak > > > > > ------------------------------------------------------- > 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 |
|
From: Andrei K. <ak...@ho...> - 2003-08-28 08:22:38
|
Hi guys, First of all, this comment is not addressed to anyone in particular. Thus, it should not be taken as any sort of personal attack. Now, here is what I think about Envo and PN in their current (released) state. Both are platforms, and provide common features, like user management, multi-lingual interface and consistent themes. THAT IS IT! Oh yeah, and one "integrated" application on top of that, called News! So, IMHO, at the moment Envo = PN = News module. Most other differences are in presentation layer. BTW, how many Envo installations disable News module or at least do not make it the default one? And even this "core" module is NOT pnAPI (or any other API) compliant. On the other hand, 3rd party modules that are announced on Envo and PN sites most of the time claim to be 100% pnAPI (an exception might be pnHTML, but it is a completely different story). The reason is simple, PN (and its forks) had promised to support all modules that are pnAPI compliant. So, IMHO, it is of paramount importance for Envo to support pnAPI as it promised (if technically feasible, of course). On the other hand, I am all for "new" envAPI (or whatever we call it). It should take good ideas from pnAPI and add new features that will make creating modules for Envo easier and less time consuming. What I don't understand is why we still don't have Comments API or Ratings API or Notification API. I am sure most 3rd party developers would love to use these APIs in their own modules. After all, API is THE ONLY WAY for modules (blocks, or anything else) to interact with Envo. The same goes for Workflow. And Categories, and everything else. The question is, do we make a "bridge" between pnAPI and envAPI? I think not. This is not our job to integrate PN based modules with all the features Envo can provide. All we ever promised is that PN modules will not break because some of pn-something functions can't be found on an envo install. Furthermore, I would suggest we make all compatibility things into separate downloads, and make sure that users understand that by using them we can't guarantee that Envo install with these add-ons will perform as fast as the "clean" one. Think of it as Wine on Linux. You only use it when there is no alternative, period. Best Regards, ak |
|
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 |
|
From: Scott K. <sc...@ki...> - 2003-08-27 20:29:17
|
On Wed, 2003-08-27 at 09:21, Sergey Alexandrov wrote: > Hello all, > > Actually I do not see any points to remome prefix except one: jump > put of > PN. If you wanted PN in the first place you shouldn't even be using Envolution. > Why? Because Envolution does not want to be a PN clone forever. > 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? No one said anything about dropping compatibility. > I'm sure, PN team not going to drop prefix. I don't care what PN team does or doesn't do....this is not PN! > > Compatibility layer? Good idea. But why? To keep some compatibility with PN. > 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? Some may, some may not. > 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? First off whenever I hear someone say "destroy" in regard to Envolution I laugh. No one is destroying anything. In fact we are trying to improve and make better the CMS. Your assessment that anything is destroyed is based on what exactly? I would assume it's based on misinformation or no information. To immediately assume and proclaim that someone is destroying something simply because things are changing is outrageous. The only fact in life is that things will change! If you can't accept change then your in for a rough ride no matter what context it is used in. > 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. This, as I've said before is NOT PostNuke if you wanted PN then go use PostNuke. > > 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. > Hopefully prefixes will be removed from the database table as well. You call that a "point of no return"...I call it a "point of departure". The fact is this: Envolution wants to have as much compatability with PN due to the wide variety of modules and blocks out there currently in use. But not at the expense of our own identity...this after all is a fork of PN and as a fork is meant to progress and develop into it's own unique CMS....I should know as thats what I and three others founded the project on. The belief that Envolution would evolve from a common code tree once shared with PN into a unique and better code tree we could call our own. So...decide what is best for you and follow your decision to achieve your goals. But don't come here and say that using PN's api and PN's core and PN's this, and PN's that....cause if you feel that strongly about PN's code then you should really be using PN. If Brian, Brandon, Max, and I wanted to be like PostNuke forever we never would have founded Envolution in the first place. Zoom |
|
From: Scott K. <sc...@ki...> - 2003-08-27 16:49:36
|
On Mon, 2003-08-25 at 15:43, Eric Barr wrote: > Based on the input and discussion lately I have released a statement regarding > the Code Cleanup Initiative effective immediately. To get all of the details > check out the article on the envolution.com website. > > http://www.envolution.com/index.php?name=News&file=article&sid=10021&mode=thread > &order=0&thold=0 > > Also, a coding standards document has been put up in the documentation section. > These standards should be adhered to by all core developers. If you have > comments, questions, or suggestion for better ways of doing this, please contact > me so that we can discuss this. Here is a link to the coding standards doc. > > http://www.envolution.com/index.php?module=subjects&func=viewpage&pageid=29 > > As always, your input is welcome and needed. Anybody who wishes to help in this > effort please contact me directly at eri...@en... so that we can get > you set up with a project to work on. > > Thanks! > > Eric Barr > Project Manager :: E n v o l u t i o n > Good work on the code guidelines. Might I suggest we add this information as well: I might add that if anyone uses non-unix editors to write code (we talking windows apps) to ensure that there are no ^M or extraneous carriage returns at the end of your lines. If you have code that you are unsure of let me know and I'll check it and correct it with the most excellent dos2unix script commonly available on juts about every major linux distro available. Also make sure that no whitespace or blank lines appear after the closing php tag. Zoom |
|
From: Furbo <fu...@si...> - 2003-08-27 16:25:41
|
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 |
|
From: Sergey A. <se...@ac...> - 2003-08-27 14:22:06
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hello all,<br>
<br>
Actually I do not see any points to remome prefix except one: jump
put of <br>
PN. Why? There are a lot of modules and blocks, that was written
for PN,<br>
using pnAPI, and a lot of ppl continued write software for PN. Why
you want<br>
to drop compatibility? I'm sure, PN team not going to drop prefix.
Compatibility<br>
layer? Good idea. But why? For useing enoAPI, envoHTML and so on?<br>
Ok, let's create compatibility layers for all open source CMS you
can find.<br>
Do you really need it? Probably you, guys have to do a lot of work
to cleanup code<br>
before change compatibility level of Envo. What do you mean
"central api"?<br>
Guys, there are "central API" - this is pnAPI. It was developed a
long time, a lot of<br>
ppls are using it, and you decided to destroy that? Why? To make
Envo dominant?<br>
You have to think more to start this work. Main goal of using pnAPI
- compatibility<br>
and it's not nessesarly to create additional layer . If you want
to, just create ENVO <br>
compatibility layer, and write all you, guys want, but leave space
for those, who<br>
want to use Envo core with pnModules and pnBlocks. <br>
<br>
Don't forget to remove _pn_ prefixes from table and column names -
that will be<br>
"point of no return" for Envo.<br>
<br>
Thank you very much. <br>
<br>
Serg aka Goblin.<br>
<br>
Eric Barr wrote:<br>
<blockquote type="cite" cite="mid20038272142.786407@xenomachine">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, 2003-08-26 at 14:03, Eric Barr wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">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:<a class="moz-txt-link-freetext" href="http://www.vmware.com/wl/offer/358/0">http://www.vmware.com/wl/offer/358/0</a>
_______________________________________________ Envolution-devel
mailing list <a class="moz-txt-link-abbreviated" href="mailto:Env...@li...">Env...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/envolution-devel">https://lists.sourceforge.net/lists/listinfo/envolution-devel</a>
</pre>
</blockquote>
<pre wrap="">
------------------------------------------------------- This sf.net
email is sponsored by:ThinkGeek Welcome to geek heaven.
<a class="moz-txt-link-freetext" href="http://thinkgeek.com/sf">http://thinkgeek.com/sf</a>
_______________________________________________ Envolution-devel
mailing list <a class="moz-txt-link-abbreviated" href="mailto:Env...@li...">Env...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/envolution-devel">https://lists.sourceforge.net/lists/listinfo/envolution-devel</a>
</pre>
</blockquote>
<pre wrap=""><!---->
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
<a class="moz-txt-link-freetext" href="http://thinkgeek.com/sf">http://thinkgeek.com/sf</a>
_______________________________________________
Envolution-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Env...@li...">Env...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/envolution-devel">https://lists.sourceforge.net/lists/listinfo/envolution-devel</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Thank you,
--
Sergey Alexandrov
ACT Inc.
Tel: (770) 935-0300
FAX: (770) 935-0303
email: <a class="moz-txt-link-abbreviated" href="mailto:se...@ac...">se...@ac...</a>
</pre>
</body>
</html>
|
|
From: Eric B. <apa...@xe...> - 2003-08-27 07:01:48
|
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 |
|
From: Mark C. <ma...@ma...> - 2003-08-26 22:44:53
|
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 |
|
From: Eric B. <apa...@xe...> - 2003-08-26 21:38:07
|
You make a very good point, also to make the transition as painless as=
possible
a "redirect" layer can be added so that modules do not break. For example:
pnVarCleanFromInput($var)
{
=09varCleanFromInput($var);
}
Eventually when we have the compatibility system completed this will not be=
an
issue and this temporary layer could be removed.
Eric Barr
Project Manager :: E n v o l u t i o n
On 26 Aug 2003 16:31:33 -0500, Scott Kindley wrote:
> 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
|
|
From: Scott K. <sc...@ki...> - 2003-08-26 21:32:13
|
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 |
|
From: Eric B. <apa...@xe...> - 2003-08-26 19:24:20
|
<html><head><meta name=3D"Generator" content=3D"PocoMail 3 HTML/CSS=
Generator"/>
<style type=3D"text/css"><!--
p{display:block;font-family:"Tahoma";font-size:8pt;color:black;margin:0.00in=
;text-align:left;}
LI{display:list-item;font-family:"Tahoma";font-size:0pt;color:black;margin-t=
op:0.00in;margin-bottom:0.00in;text-align:left;}
td{display:block;font-family:"Tahoma";font-size:0pt;color:black;margin-left:=
0.00in;margin-right:0.00in;text-align:left;}
--></style>
</head><BODY BGCOLOR=3D"#F0F0F0"><p class=3D"p"><SPAN=
style=3D"font-family:'Tahoma';">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!<br/>=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';"><B>Eric=
Barr</B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';"><U><B>Project=
Manager</B></U><B> :: <I>E n v o l u t i o n</I></B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
</body></html>
|
|
From: Eric B. <eri...@sb...> - 2003-08-26 19:02:29
|
<html><head><meta name=3D"Generator" content=3D"PocoMail 3 HTML/CSS=
Generator"/>
<style type=3D"text/css"><!--
p{display:block;font-family:"Tahoma";font-size:8pt;color:black;margin:0.00in=
;text-align:left;}
LI{display:list-item;font-family:"Tahoma";font-size:0pt;color:black;margin-t=
op:0.00in;margin-bottom:0.00in;text-align:left;}
td{display:block;font-family:"Tahoma";font-size:0pt;color:black;margin-left:=
0.00in;margin-right:0.00in;text-align:left;}
body{}
--></style>
</head><BODY BGCOLOR=3D"#F0F0F0"><p class=3D"p"><SPAN=
style=3D"font-family:'Tahoma';">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!<br/>=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';"><B>Eric=
Barr</B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';"><U><B>Project=
Manager</B></U><B> :: <I>E n v o l u t i o n</I></B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
</body></html>
|
|
From: Mark C. <ma...@ma...> - 2003-08-26 14:27:43
|
I am very glad to finally see some activity at envolution.com and the dev list. I have great faith in Eric's skills and vision. I can't wait for envolution to finally blossom into the project it was meant to be almost 1 year ago. -MACscr |
|
From: Eric B. <apa...@xe...> - 2003-08-25 20:44:21
|
Based on the input and discussion lately I have released a statement= regarding the Code Cleanup Initiative effective immediately. To get all of the details= check out the article on the envolution.com website. http://www.envolution.com/index.php?name=3DNews&file=3Darticle&sid=3D10021&mode=3Dth= read &order=3D0&thold=3D0 Also, a coding standards document has been put up in the documentation= section. These standards should be adhered to by all core developers. If you have comments, questions, or suggestion for better ways of doing this, please= contact me so that we can discuss this. Here is a link to the coding standards doc. http://www.envolution.com/index.php?module=3Dsubjects&func=3Dviewpage&pageid=3D29 As always, your input is welcome and needed. Anybody who wishes to help in= this effort please contact me directly at eri...@en... so that we can= get you set up with a project to work on. Thanks! Eric Barr Project Manager :: E n v o l u t i o n |
|
From: Eric B. <apa...@xe...> - 2003-08-13 08:11:21
|
<html><head><meta name=3D"Generator" content=3D"PocoMail 3 HTML/CSS=
Generator"/>
<style type=3D"text/css"><!--
p{display:block;font-family:"Tahoma";font-size:10pt;color:black;margin:0.00i=
n;text-align:left;}
LI{display:list-item;font-family:"Tahoma";font-size:0pt;color:black;margin-t=
op:0.00in;margin-bottom:0.00in;text-align:left;}
td{display:block;font-family:"Tahoma";font-size:0pt;color:black;margin-left:=
0.00in;margin-right:0.00in;text-align:left;}
body{}
--></style>
</head><BODY><p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">These are my=
thoughts about the current code and suggestions to make it better.=
Hopefully after reading this you will be able to take a closer look at the=
code base and find new and better ways to improve it.</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">The number one topic that=
I'd like to start out with is the use of standards. I feel that standards=
are very important to any project, especially one with as many people as=
Envolution. Standards help to better read and understand code, help people=
to easily communicate with one another about code and help in creating=
clean and solid running code. This is one area of Envolution that I think=
is lacking at the moment and with a little hard work something that can=
fixed for the benefit of everybody working with the project. There are=
several forms of standards that I think we could benefit from that I will=
go over right now.</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';"><B>Coding=
Standards</B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">This type of standard is=
basically just a guideline to follow when writing code. This includes=
variable and function naming, tab settings, commenting, etc. This just=
helps everybody to be on the same page, and also makes reading through=
sections of code much easier.</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';"><B>Standard API=
Procedures</B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Having a standard API is=
important for many reasons. If a standardized API is utilized it helps to=
make common coding problems easier to solve, cuts back heavily on the=
amount of repeat code used and makes the process of enhancing or upgrading=
the core easier without the hassle of breaking compatibility with older=
versions. What this achieves is making Envolution easier to use while=
greatly improving speed and using less resources.</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Both of these types of=
standards should be discussed with the community (especially the=
developers) and a standard laid out for everybody to use.</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Ok, now on to the actual=
code itself. I've been spending a great deal of time going over it and=
watching the way it works and these are my thoughts/opinions on what=
specifically needs to be worked on and some suggestions for how to go about=
that.</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';"><B>01. pnAPI - Creation of=
many unnecessary variables</B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Creating just a single=
variable is not very resource intensive by itself but the creation of many=
variables begins to add up over time, especially when most of those=
variables are never used.</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Here are a few=
examples:</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';font-size:8pt;"><B>Example=
1.) includes/pnAPI.php</B></SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">44 $supers =3D=
array('_REQUEST',</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">45 =
'_ENV',</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">46 =
'_SERVER',</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">47 =
'_POST',</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">48 =
'_GET',</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">49 =
'_COOKIE',</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">50 =
'_SESSION',</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">51 =
'_FILES',</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">52 =
'_GLOBALS' );</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">53</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">54 foreach( $supers as=
$__s) {</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">55 =
if ( (isset($$__s) =3D=3D true) && (is_array( $$__s ) =3D=3D true) )=
extract( $$__s, EXTR_OVERWRITE );</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">56 }</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">In this section of the=
pnAPI is trying to work around the register globals turned off issue. I'm=
not quite sure exactly why this is being done though. What it is doing is=
extracting all of the keys and values from each of the super global=
variables and turning them into regular variables, however none of these=
variables are actually used. Depending on the server environment this could=
be 10 - 50 new variables created that are never used. Remember that these=
variables are created every time a page in Envolution is accessed so they=
add up very quickly.</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Suggestion:</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Talk with the developers=
who added this particular code to find out why it was done this way, then=
look at seeing if there is a better approach. Also, another thing to point=
out here is that good in code documentation could really help people to=
understand what your code is trying to do.</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';font-size:8pt;"><B>Example=
2.) config.php</B></SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">72 extract($pnconfig,=
EXTR_OVERWRITE);</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">This particular file loads=
up the configuration settings for Envolution. At the very end of the file=
the $pnconfig variable is being extracted. This creates a variable for each=
of the configuration variables (there are 8 of them). These are created and=
never used, however there is a comment saying that this should be=
deprecated.</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Suggestion:</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Lets make sure that this=
has been fully deprecated and remove it asap.</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';"><B>02. pnAPI - Code=
Organization</B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Another thing that I am=
noticing while looking through the pnAPI is the organization of code. There=
are several "hacks" placed in odd places in between some functions. Code=
like this should be grouped accordingly for better organizing and also to=
make it easier to read and understand what is happening in the code. This=
is an important topic that needs to be discussed in the near future with=
the development community.</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';"><B>03. pnAPI - Removal of=
Hacks</B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">I've lightly touched on=
this topic in several other areas but I think it's worth mentioning on its=
own. Hacks are a good part of the programming process. They help you to=
figure out a direction to go in solving a problem and help greatly during=
debugging processes. Nine times out of ten though hacks do not follow=
standards and usually take up more resources than they should. For release=
quality code all hacks should be taken care of and fixed to work with the=
standards of the API and code base. This will help a great deal with making=
the system faster, cutting back redundant code and better improving the=
quality of Envolution.</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">=A0</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';"><B>03. pnAPI - Global=
Variables</B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">There are still a great=
many global variables in use with Envolution. The use of global variables=
can be a source of controversy at times, some people think that they are=
easier to use and others think that using globals is more restrictive to=
the code in the long run. I am definitely one of the second type of people.=
The problem with the use of globals is twofold, they have been known to be=
the source of many security issues and it prevents from using standard=
methods of accessing variables. The details on this are beyond the scope of=
this particular writing (it would take a lot of room to discuss the theory=
behind that) but I would be happy to talk with anyone who has any further=
questions.</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';"><B>04. General - Config=
Files</B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">In config.php the same if=
statement is repeated twice.</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">39 if=
(@file_exists("config/env-config.php"))</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">40 {=
include("config/env-config.php"); }</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">And again on:</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">60 if=
(@file_exists("config/env-config.php"))</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">61 {=
include("config/env-config.php"); }</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">This is just redundant code=
that should be cleaned out, doesn't really harm anything but taking the=
unneeded code out will make the code footprint smaller.</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';"><B>05. General -=
Instantiating Classes</B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">The object model in php 4=
is a little bit different than that of other languages like Java and c++.=
When instantiating an object in php like this:</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">$object =3D new=
Object();</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Creates a new <I>copy</I>=
of the object instead of creating a <I>reference</I> to an object of the=
same type already in existence. There are many great articles on the web=
about Object Oriented PHP programming that cover this topic in further=
detail. The main problems that this presents though are that objects don't=
always behave as expected, and creating new instances takes up server=
resources (more on this topic later). A properly instantiated object would=
look like this:</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">$object =3D& new=
Object();</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">This makes a reference to=
Object and places it in the $object variable.</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';"><B>06. pnAPI - pnDBInit()=
and pnDBGetConn()</B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">This point ties in with the=
last section (05. General - Instantiating Classes). The issue here deals=
with the way that the $dbconn variable is handled. The first issue is that=
$dbconn is being passed around as a global variable, which as previously=
discussed carries some issues mainly sensitive information such as db=
username and password being stored in the global namespace. The second=
issue is that $dbconn is an object. Take a look at the code concerning=
these two functions as well as the ADONewConnection() function:</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">524 function=
pnDBInit()</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">525 {</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">     =
  ...</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">537 // Start=
connection</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">538 $dbconn =
=3D ADONewConnection($dbtype);</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">     =
  ...</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">553 }</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">and</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">560 function=
pnDBGetConn()</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">561 {</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">562 global=
$dbconn;</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">563</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">564 return=
array($dbconn);</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">565 }</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">finally</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">2795 function=
&ADONewConnection($db=3D'')</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">2769 {</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">     =
  ...</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">2829 }</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">When Envolution first=
begins it's initialization process it runs the pnDBInit() function. Inside=
this function a call is made to ADONewConnection(). If you look closely at=
the interface for the ADONewConnection function you will see the "&"=
symbol. This tells the function that when it returns a value it needs to=
return it by reference. Now look back at line 538 in the pnDBInit()=
function. Here the object is being copied instead of given a reference and=
is stored in the global variable $dbconn. This is our first copy of the=
database object, and it stores all of pnadodb's configuration settings (54=
in all).</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Now we move on to=
pnDBGetConn(). This is a function everybody should be familiar with. A call=
to pnDBGetConn() normally looks like this:</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">list($dbconn) =3D=
pnDBGetConn();</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Lets break down this call.=
First when you make the call to pnDBGetConn a new copy is made in the local=
scope at line 562. Then at line 564 another copy is made and is returned to=
the calling statement. Then finally back in the calling statement a third=
copy is created and assigned to the local $dbconn by the list() function.=
Each of these copies stores the same 54 configuration settings for a total=
of 162 unneeded settings taking up space in system memory. Granted that=
alone is not much, but you must remember that this is 162 being put into=
memory each time pnDBGetConn() is called. This is a huge drain on resources=
if your website gets any amount of traffic.</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Suggestion:</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">Several things need to be=
done in order to clear this up. First, the global variables situation=
should be attended to. This will require a bit of thought and discussion to=
come up with the best solution. Second, begin using the correct method of=
passing and instantiating objects in order to cut back on the number object=
copies created. Finally, the pnDBGetConn() needs to address the that it=
returns the object to the calling statement.</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN=
style=3D"font-family:'Tahoma';"><B>Conclusion</B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">All of these issues (and=
many others) occur during just the first two lines of code in=
index.php:</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">31 include=
'includes/pnAPI.php';</SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Courier New';">32=
pnInit();</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">This means that all of this=
happens every time you load a page through Envolution, and doesn't take=
into account any of the problems that occur from this point on. Taking=
steps to fix these issues and others like them will help to create a solid=
web environment for everyone who uses or develops for=
Envolution.</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';">I look forward to=
discussing these topics with everyone and if anybody has any questions feel=
free to email me. I just want to remind everybody these are just my=
thoughts on issues that I've seen while looking over the code and should be=
treated as such.</SPAN></p>
<p class=3D"p"> </p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';font-size:8pt;"><B>Eric=
Barr</B></SPAN></p>
<p class=3D"p"><SPAN style=3D"font-family:'Tahoma';font-size:8pt;"><U><B>Project=
Manager</B></U><B> :: <I>E n v o l u t i o n</I></B></SPAN></p>
</body></html>
|
|
From: Scott K. <sc...@ki...> - 2003-08-06 21:41:53
|
On Wed, 2003-08-06 at 14:09, David C.C. wrote: > On Tuesday 05 August 2003 15:18, Scott Kindley wrote: > > On Tue, 2003-08-05 at 07:57, TiMax wrote: > > > Thanks for your respect my request and to not have add my news in home > > > page. > > > > > > TiMax > > > > Your post was published. > > > > The content of your post does not further Envolution development so it > > does not belong on the front page. > > > > Zoom > > Sorry. I know everybody is tired about this flame, but: > - When envohispano.com was born, it was published in front page. > Now that envolution.it is going to die as "official support", I suppose that > the new has to be published in the same way, hasn't it? > Nuclei > Adding support certainly aids development....taking away support doesnt. So no it doesnt "further" or "advance" development of Envolution it only serves to disrupt support until a new suport site is located and established. Another way to look at it is that no one wants to read negative comments and articles...espcially those that are so ugly and malicious in nature that it makes the entire community look bad. So in the interest of fairness we published the artile, but not on the main news index page. Zoom |
1 message has been excluded from this view by a project administrator.
