Thread: [Envolution-devel] File Prefix's

Brought to you by: apathyboy, fixxx, furbo

envolution-devel

[Envolution-devel] File Prefix's

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>

Re: [Envolution-devel] File Prefix's

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

Re: [Envolution-devel] File Prefix's

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

Re: [Envolution-devel] File Prefix's

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

Re: [Envolution-devel] File Prefix's

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

Re: [Envolution-devel] File Prefix's

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>
&nbsp;&nbsp;&nbsp; Actually I do not see any points to remome prefix except one: jump
put of <br>
&nbsp;&nbsp;&nbsp; PN. Why? There are a lot of modules and blocks, that was written
for PN,<br>
&nbsp;&nbsp;&nbsp; using pnAPI, and a lot of ppl continued write software for PN. Why
you want<br>
&nbsp;&nbsp;&nbsp; to drop compatibility? I'm sure, PN team not going to drop prefix.
Compatibility<br>
&nbsp;&nbsp;&nbsp; layer? Good idea. But why? For useing enoAPI, envoHTML and so on?<br>
&nbsp;&nbsp;&nbsp; Ok, let's create compatibility layers for all open source CMS you
can find.<br>
&nbsp;&nbsp;&nbsp; Do you really need it? Probably you, guys have to do a lot of work
to cleanup code<br>
&nbsp;&nbsp;&nbsp; before change compatibility level of Envo. What do you mean
"central api"?<br>
&nbsp;&nbsp;&nbsp; Guys, there are "central API" - this is pnAPI. It was developed a
long time, a lot of<br>
&nbsp;&nbsp;&nbsp; ppls are using it, and you decided to destroy that? Why? To make
Envo dominant?<br>
&nbsp;&nbsp;&nbsp; You have to think more to start this work. Main goal of using pnAPI
- compatibility<br>
&nbsp;&nbsp;&nbsp; and it's not nessesarly to create additional layer . If you want
to, just create ENVO <br>
&nbsp;&nbsp;&nbsp; compatibility layer, and write all you, guys want, but leave space
for those, who<br>
&nbsp;&nbsp;&nbsp; want to use Envo core with pnModules and pnBlocks. <br>
<br>
&nbsp;&nbsp;&nbsp; Don't forget to remove&nbsp; _pn_ prefixes from table and column names -
that will be<br>
&nbsp;&nbsp;&nbsp; "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>

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

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

Re: [Envolution-devel] File Prefix's

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

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

RE: [Envolution-devel] File Prefix's

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

Re: [Envolution-devel] File Prefix's

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

RE: [Envolution-devel] File Prefix's

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

Re: [Envolution-devel] File Prefix's

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
>

[Envolution-devel] Utility Modules

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

Re: [Envolution-devel] Utility Modules

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

RE: [Envolution-devel] Utility Modules

From: Andrei K. <ak...@ho...> - 2003-08-28 18:23:07

Hi Furbo,

I think that hooks as they are today, not really useful. I might be
wrong, but I have to see a meaningful implementation of them before I
would make a judgment. If we implement Content Utility Module, it would
be a snap to integrate improved hooks system you are talking about (we
will already have that universal content_id to work with). On the other
hand, IMHO, the biggest problem with hooks, as they are now, is that you
can't pass any arguments to it but item_id (well, you could but there is
no standards system, and there is no guarantee the it is not going to
fail if some incompatible argument is passed in). It is easier to
implement flags in module settings to turn some features (like sanitizer
for example) on or off and include if statement to call sanitizer API
function within a module where module developer thinks it is needed.

But it is just my personal opinion. If someone is willing to work on
hooks or integrating something like it from PN in the future, I am all
for it!

Best Regards,

ak

Re[2]: [Envolution-devel] Utility Modules

From: Furbo <fu...@si...> - 2003-08-28 19:15:51

Thursday, August 28, 2003, 2:22:37 PM, Andrei wrote:
> I think that hooks as they are today, not really useful. I might be
> wrong, but I have to see a meaningful implementation of them before I
> would make a judgment. If we implement Content Utility Module, it would
> be a snap to integrate improved hooks system you are talking about (we
> will already have that universal content_id to work with). On the other
> hand, IMHO, the biggest problem with hooks, as they are now, is that you
> can't pass any arguments to it but item_id (well, you could but there is
> no standards system, and there is no guarantee the it is not going to
> fail if some incompatible argument is passed in). It is easier to
> implement flags in module settings to turn some features (like sanitizer
> for example) on or off and include if statement to call sanitizer API
> function within a module where module developer thinks it is needed.

Oh i agree hooks is only a concept idea right now.. in developemnt at
best..  Just was an idea for the 'glue' to link things..   any common
API for calling and loading util mods is good..

PLUS any work on things like this is good


-- 
Furbo

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

RE: [Envolution-devel] File Prefix's

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

Re: [Envolution-devel] File Prefix's

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
>

RE: [Envolution-devel] File Prefix's

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

Re: [Envolution-devel] File Prefix's

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
>

RE: [Envolution-devel] File Prefix's

From: Andrei K. <ak...@ho...> - 2003-08-28 18:13:05

Hi Mark,

I am no expert on templates, but usually API function (method) returns
some value. I will give you an example. Breadcrumbs function works like
this:

$breadcrumbs = breadcrumbs($cat_id);

//where $cat_id is category id for which you want to create breadcrumbs
//navigation.

$breadcrumbs will always return an array (even if you are at the root
parent_id = 0) This array will have following information for every
array member:

$breadcrumbs[]['cat_id'] - category id (for further navigation)

$breadcrumbs[]['cat_name'] - category name to display

How you, as a template designer use this information, is up to you! That
is why I call these functions API. They do not provide ready to display
output. On the other hand, we can create sub-templates (like ready to
insert snippets of ready to display code) that you can call from another
template like [-$BREADCRUMBS-VERTICAL-] to display breadcrumbs in a
vertical fashion.

But, I am not developing templating for envo (you can thank me for that
later :)), so, I can't guarantee that you will have sub-templates at all
:).

Best Regards,

ak