phpwebsite-developers — For our development team.

Re: [Phpwebsite-developers] Roadmap

[Spiggy T. <th...@me...>]

>
> > The big deal here is this: topics, subtopics, etc. should be setup once
>and
> > available to news stories, the links subsystem, discussion forums, and all
> > plug-ins that require the information. When someone registers, they should
> > be able to put in their information once and have it used throughout the
> > system so that their is no duplicate entry of information for each
>plug-in.
>Is this what everyone wants?  This is where I'm currently working.  If we do
>want the "topics" and "subtopics" to be consistant across the organization,
>then this needs to be in the core.  Once the topics are defined for each
>organization, then the plug-in modules can draw on them (topics)
>immediately.

i think it would make most sense this way. what id also like is to have a 
possibility of having a user portal kind of approach. not user submitted 
stuff (although they can) but user chosen content.. like choose a 'track' 
you're interested in and get news, articles etc on that topic. what i am 
thinking is choosing just one topic out of the options available... or if 
one of the topics is gardening and the user has no interest on it.. he/she 
can choose to ignore it completely. of course the admin could choose to 
override this (maybe the main topic IS gardening).

anyway, i managed to accomplish a small victory Friday. phpwebsite will be 
considered as the portal for my college. woohoo! what phpws does is enough 
for now. im hoping the real deal will be functional when the testing is over :)

paivi

[Phpwebsite-developers] Learning from phpGroupWare

[Todd O. <to...@da...>]

In developing an application framework for phpWebSite, I have tried to
review as many projects as possible to learn from their success (and
mistakes).  I continue to see many areas where we can look to phpGW's
success.  The following documentation link gives a good overview of their
plug-in API and language API.

http://www.phpgroupware.org/phpgroupware/phpgwapi/doc/

For those working with the translation interface, is phpGW's database
translation system too much of a performance hit?  Is it easier just to work
with a text file?

I would like some others to review the following code from the phpGW project
(phpGroupWare-0.9.9p1.tar.gz):

Access Control List class:
phpgroupware/phpgwapi/inc/phpgw_accounts_shared.inc.php

Templates (the templates look very much like those proposed here before,
although they use the phplib template class):
phpgroupware/phpgwapi/templates/

Session Management and general object design:
phpgroupware/phpgwapi/inc/phpgw_common.inc.php
phpgroupware/phpgwapi/inc/phpgw.inc.php

Do we use the phpgw classes as they are, modify them to meet our need, or
neither?

--Todd

RE: [Phpwebsite-developers] Roadmap

[Geoff S. <Ge...@Ho...>]

HERE'S MY QUESTION: WHAT CORE "SERVICES" DOES THE BASE SYSTEM NEED TO
PROVIDE TO PLUG-INS?

There are certain things that will be common across many plug-ins. These
things should be part of the core. Some of the things I've thought about
that would be common across many plug-ins are:

Administrative services should extend to plug-ins. For example, if the
system allows separate administrators for topics or sub-topics, sub-webs,
whatever, this should extend across plug-ins that use topics, sub-topics,
etc.

Mailing list functionality - the ability to have mailing lists for a plug-in
that can be setup when someone registers for a login id.

Themes - plug ins should be able to "inherit" the theme from the site.

I'm hoping that we can come up with a complete list of the services that the
core system should provide to plug-ins.

Geoff

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of
Todd Owen
Sent: Saturday, March 31, 2001 8:24 PM
To: php...@li...
Subject: Re: [Phpwebsite-developers] Roadmap


> We need to decide what the final form of the existing phpWebsite will be.
It
> should be a tool that only works with mySQL and is compatible with php3
and
> php4. This product would be "functionally stable". That means bug fixes
> only - no further enhancements.
Agreed!  We'll leave it mySQL only, good idea.

> ALSO, when someone registers for a login id, they would be presented
> a list of email subscriptions, some of which were put there by plug-ins.
This "alert" function seems interesting to me.  Is anyone working on a
detailed design proposal for this?  I am working on my core proposal, which
I hope to publish no later than Monday (even if slightly incomplete).  The
"alerts" won't be in it however.

> The big deal here is this: topics, subtopics, etc. should be setup once
and
> available to news stories, the links subsystem, discussion forums, and all
> plug-ins that require the information. When someone registers, they should
> be able to put in their information once and have it used throughout the
> system so that their is no duplicate entry of information for each
plug-in.
Is this what everyone wants?  This is where I'm currently working.  If we do
want the "topics" and "subtopics" to be consistant across the organization,
then this needs to be in the core.  Once the topics are defined for each
organization, then the plug-in modules can draw on them (topics)
immediately.

--Todd




_______________________________________________
Phpwebsite-developers mailing list
Php...@li...
http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Roadmap

[Todd O. <to...@da...>]

> We need to decide what the final form of the existing phpWebsite will be.
It
> should be a tool that only works with mySQL and is compatible with php3
and
> php4. This product would be "functionally stable". That means bug fixes
> only - no further enhancements.
Agreed!  We'll leave it mySQL only, good idea.

> ALSO, when someone registers for a login id, they would be presented
> a list of email subscriptions, some of which were put there by plug-ins.
This "alert" function seems interesting to me.  Is anyone working on a
detailed design proposal for this?  I am working on my core proposal, which
I hope to publish no later than Monday (even if slightly incomplete).  The
"alerts" won't be in it however.

> The big deal here is this: topics, subtopics, etc. should be setup once
and
> available to news stories, the links subsystem, discussion forums, and all
> plug-ins that require the information. When someone registers, they should
> be able to put in their information once and have it used throughout the
> system so that their is no duplicate entry of information for each
plug-in.
Is this what everyone wants?  This is where I'm currently working.  If we do
want the "topics" and "subtopics" to be consistant across the organization,
then this needs to be in the core.  Once the topics are defined for each
organization, then the plug-in modules can draw on them (topics)
immediately.

--Todd

RE: [Phpwebsite-developers] Mailing List plug-in

[Geoff S. <Ge...@Ho...>]

Jason:

I looked on hostscripts as well and saw several. I saw another one called
Relata.

I was hoping for some actual experience with the software.

But, thank you for your time and assistance in researching this.

Geoff

Geoff Staples,
Hostricity Web Hosting <http://www.hostricity.com/>

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of
Jason Campbell
Sent: Saturday, March 31, 2001 3:36 PM
To: php...@li...
Subject: RE: [Phpwebsite-developers] Mailing List plug-in


Geoff:

I looked on hotscripts for a PHP mailing list script and found this one
called PHPMailList.  Not sure how good it is but it looks like the author
is releasing a new app called Multilist for Multiple Lists.  Might want to
check it out: http://php.warpedweb.net/

You might find some others at hotscripts or Sourceforge for that matter.

Jason Campbell
Xplozive Media Technologies
www.xplozivemedia.com


> Todd:
>
> Thanks for the suggestion of Mailman. However, I'm curious. Why would I
> want to use a Python based program instead of a PHP based one?
>
> In principal, I suppose I'm not opposed to using a Python program. But,
> it seems counterproductive to add something that requires an additional
> interpretive environment to be installed on a server before one can use
> phpWebsite.
>
> I'm certainly open to your reasons for suggesting Mailman.
>
> ALSO, I'd like to hear from anyone who has a suggestion for a php /
> mySQL mailing list program.
>
> Thanks,
>
> Geoff
>
> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of
> Todd Owen
> Sent: Saturday, March 31, 2001 1:42 AM
> To: php...@li...
> Subject: Re: [Phpwebsite-developers] Mailing List plug-in
>
>
> Try Mailman.
>
> http://www.list.org
>
> --Todd
>
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers



_______________________________________________
Phpwebsite-developers mailing list
Php...@li...
http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Mailing List plug-in

[Todd O. <to...@da...>]

Mailman is a great mailing list program.  It's automatic web archive
interface is wonderful.  We're using it right now on SourceForge.  Its list
of users is quite impressive, so it's proven in very large environments.
BTW, egroups (now part of Yahoo) was also written in Python.

http://www.list.org/inthenews.html

If we could get the same functionality in a PHP product, then we should use
it.  I just haven't seen one yet.

--Todd

RE: [Phpwebsite-developers] Mailing List plug-in

[Jason C. <cam...@xp...>]

Geoff:

I looked on hotscripts for a PHP mailing list script and found this one 
called PHPMailList.  Not sure how good it is but it looks like the author 
is releasing a new app called Multilist for Multiple Lists.  Might want to 
check it out: http://php.warpedweb.net/

You might find some others at hotscripts or Sourceforge for that matter.

Jason Campbell
Xplozive Media Technologies
www.xplozivemedia.com


> Todd:
> 
> Thanks for the suggestion of Mailman. However, I'm curious. Why would I
> want to use a Python based program instead of a PHP based one?
> 
> In principal, I suppose I'm not opposed to using a Python program. But,
> it seems counterproductive to add something that requires an additional
> interpretive environment to be installed on a server before one can use
> phpWebsite.
> 
> I'm certainly open to your reasons for suggesting Mailman.
> 
> ALSO, I'd like to hear from anyone who has a suggestion for a php /
> mySQL mailing list program.
> 
> Thanks,
> 
> Geoff
> 
> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of
> Todd Owen
> Sent: Saturday, March 31, 2001 1:42 AM
> To: php...@li...
> Subject: Re: [Phpwebsite-developers] Mailing List plug-in
> 
> 
> Try Mailman.
> 
> http://www.list.org
> 
> --Todd
> 
> 
> 
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> 
> 
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

RE: [Phpwebsite-developers] Mailing List plug-in

[Geoff S. <Ge...@Ho...>]

Todd:

Thanks for the suggestion of Mailman. However, I'm curious. Why would I want
to use a Python based program instead of a PHP based one?

In principal, I suppose I'm not opposed to using a Python program. But, it
seems counterproductive to add something that requires an additional
interpretive environment to be installed on a server before one can use
phpWebsite.

I'm certainly open to your reasons for suggesting Mailman.

ALSO, I'd like to hear from anyone who has a suggestion for a php / mySQL
mailing list program.

Thanks,

Geoff

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of
Todd Owen
Sent: Saturday, March 31, 2001 1:42 AM
To: php...@li...
Subject: Re: [Phpwebsite-developers] Mailing List plug-in


Try Mailman.

http://www.list.org

--Todd



_______________________________________________
Phpwebsite-developers mailing list
Php...@li...
http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

RE: [Phpwebsite-developers] Roadmap

[Geoff S. <Ge...@Ho...>]

Here's my cut on it:

We need to decide what the final form of the existing phpWebsite will be. It
should be a tool that only works with mySQL and is compatible with php3 and
php4. This product would be "functionally stable". That means bug fixes
only - no further enhancements.

What will happen is this: Folks will continue to use it and they will
continue to write plug-ins for it. So, it will have a life of its own.

If the plug-in scheme for the existing phpWebsite is compatible with the new
product, that would be nice -- but we have to get a certain amount of design
work done to determine if that will be the case. I would not compromise on
the new system to make the plug-in scheme work with both the current and the
new product.

Here's an example of something that could easily make the plug-in system for
the new product incompatible with a plug-in scheme for the existing product:
I mentioned the other day that the core product should include a mailing
list system so that plug-ins can integrate with it. This would allow a
weather plug-in, for example, to have a subscription for emailed weather
updates -- freeze alerts or whatever -- that uses the built-in mailing list
system. ALSO, when someone registers for a login id, they would be presented
a list of email subscriptions, some of which were put there by plug-ins.

The big deal here is this: topics, subtopics, etc. should be setup once and
available to news stories, the links subsystem, discussion forums, and all
plug-ins that require the information. When someone registers, they should
be able to put in their information once and have it used throughout the
system so that their is no duplicate entry of information for each plug-in.
And, just as important, to eliminate duplication of effort by admins setting
up the system.

It may be that the old plug-ins could work in the new system -- they just
wouldn't be able to take advantage of all the plug-in features without some
modification -- but, we won't know that until we have a new system design.

Perhaps, we should design the new system and then upgrade the existing
system so that it will work with the plug-ins for the new system? If that
could be done, we'd have the best of all worlds: An existing system that is
stable, works on php3 and php4, and can be expanded with plug-ins. AND,
those plug-ins would also work with the new system. I think it doubtful that
we could achieve 100% compatibility. But, we'll have to see how it all comes
out.

In any event, this would allow those with immediate requirements to address
them without totally locking themselves into the old system.

Geoff

Geoff Staples,
Hostricity Web Hosting <http://www.hostricity.com/>

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of
Mike Windsor
Sent: Saturday, March 31, 2001 10:51 AM
To: php...@li...
Subject: Re: [Phpwebsite-developers] Roadmap


Todd,


> I think Brian will let us know the vote for database abstraction layer by
> Monday, if not before.  This will allow those coding for the current
> structure to continue.

I hope so. :)

> programmers talking on the forums and they're ready to start coding.
Others
> of us are ready to redesign.  Am I making any sense?  Am I the only one
over
> here or not?

I agree and I am ready to start with some plugins as soon as we get a
standard.


Has anyone heard anything?

Mike


_______________________________________________
Phpwebsite-developers mailing list
Php...@li...
http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Roadmap

[Mike W. <wi...@ce...>]

Todd,


> I think Brian will let us know the vote for database abstraction layer by
> Monday, if not before.  This will allow those coding for the current
> structure to continue.

I hope so. :)

> programmers talking on the forums and they're ready to start coding.
Others
> of us are ready to redesign.  Am I making any sense?  Am I the only one
over
> here or not?

I agree and I am ready to start with some plugins as soon as we get a
standard.


Has anyone heard anything?

Mike

Re: [Phpwebsite-developers] Integrated User/Group & Permissions

[clayton c. <cc...@ca...>]

Todd,
    the code i sent you can be made to accomodate parts of what Zope does,
with the exception of heirarchical permissions. with its user-groups and the
general permissions code, it can support named, object-level permissions
which can be assigned to a user (registered or unregistered), group, and
roles within groups. One deviation from Zope roles is the notion of
"actions" - or operations permissible for a role. one can assign multiple
actions per role. it is flexible enough to allow the user to choose what
style of permissions s/he wishes to employ.

   ACS in its later versions began to implement a more layered user (hence
permissions) structure, but based on my reading of the code, it really would
take a well tuned back end to deal with the type of queries they needed to
support it. definitely not for your garden variety ISP. thats one of the
reasons i stopped tracking it at version 3.xxx. The Zope architecture is
indeed nice, but i think they have custom serialization to handle their data
model.

i'll give the AccessControl.txt file a read ....

Re: [Phpwebsite-developers] Mailing List plug-in

[Todd O. <to...@da...>]

Try Mailman.

http://www.list.org

--Todd

[Phpwebsite-developers] Mailing List plug-in

[Geoff S. <Ge...@Ho...>]

I have to add a mailing list system to phpWebsite.

I'd prefer to tailor an existing program as opposed to writing something
from scratch.

Anyone have any suggestions of mailing list systems I might take a look at?

Also, is there is specification for the plugin systm somewhere?

Thanks,

Geoff

Geoff Staples,
Hostricity Web Hosting <http://www.hostricity.com/>

Re: [Phpwebsite-developers] Integrated User/Group & Permissions

[Todd O. <to...@da...>]

You can find the best access control system I've seen, in Zope.
http://www.zope.org

Just download version 2.3.1, which was released today, and look in the
following location for the Python files that define Zope's access control
granularity.
Zope-2.3.1-src\lib\python\AccessControl\

Zope is a great product, but it has a steep learning curve.  There's too
much overhead to be used for small sites where you just want to hack out
some scripts.  Zope allows a custom template for every object, which is
great except when you don't want it.  Making some site wide changes in a
Zope can be painful.  Zope is a worthy competitor to what we are doing here
and contains some fuctionality that will never appear in phpWS, like
versioned changes to a live site (very cool).  Digital Creations has 30+
developers working full time on Zope right now, including von Rossum of
Python.  After much consideration, I had to leave Zope because of the
multiple organization support issue (it wasn't designed that way).  All that
said, there are lots of good ideas in the Zope code that would make
phpWebSite a better product.

Here's AccessControl.txt from directory above:

--Todd

---------------------
Security Architecture
---------------------

Users
-----

Objects representing users may be created in Principia
User Folder objects. User objects maintain the information
used to authenticate users, and allow roles to be associated
with a user.



Permissions
-----------

A "permission" is the smallest unit of access to an object,
roughly equivalent to the atomic permissions seen in NT:
R (Read), W(Write), X(Execute), etc. In Principia, a permission
usually describes a fine-grained logical operation on an object,
such as "View Management Screens", "Add Properties", etc.

Different types of objects will define different permissions
as appropriate for the object.



Types of access
---------------

A "type of access" is a named grouping of 0 or more of the
permissions defined by an object. All objects have one predefined
type of access called Full Access (all permissions defined by that
object). A user who has the special role "Manager" always has Full
Access to all objects at or below the level in the object hierarchy
at which the user is defined.

New types of access may be defined as combinations of the
various permissions defined by a given object. These new
types of access may be defined by the programmer, or by
users at runtime.




Roles
-----

A role is a name that ties users (authentication of identity)
to permissions (authorization for that identity) in the system.
Roles may be defined in any Folder (or Folderish) object in the
system. Sub folders can make use of roles defined higher in the
hierarchy. These roles can be assigned to users. All users,
including non-authenticated users have the built-in role of
"Anonymous".

Principia objects allow the association of defined roles
with a single "type of access" each, in the context of that
object. A single role is associated with one and only one
type of access in the context of a given object.



Examples
--------

  User                        Object1

  o has the role "RoleA"      o has given "RoleA" Full Access

  Result: the user has Full Access to Object1.



  User                        Object2
  o has the role "RoleA"      o has given "RoleB" Full Access

                              o has given the role "RoleA" View Access,
                                a custom type of access that allows only
                                viewing of the object.

  Result: the user has only View Access.



Notes
-----

All objects define a permission called "Default permission". If this
permission is given to a role, users with that role will be able to
access subobjects which do not explicitly restrict access.



Technical
---------

Objects define their permissions as logical operations.
Programmers have to determine the appropriate operations
for their object type, and provide a mapping of permission
name to attribute names. It is important to note that permissions
cannot overlap - none of the attributes named in a permission
can occur in any of the other permissions. The following are
proposed permissions for some current principia objects:


Folder
  o View management screens
  o Change permissions
  o Undo changes
  o Add objects
  o Delete objects
  o Add properties
  o Change properties
  o Delete properties
  o Default permission

Confera Topic
  o View management screens
  o Change permissions
  o Undo changes
  o Add objects
  o Delete objects
  o Add properties
  o Change properties
  o Delete properties
  o Default permission
  o Change Configuration
  o Add Messages
  o Change Messages
  o Delete Messages

Tabula Collection
  o View management screens
  o Change permissions
  o Undo changes
  o Add objects
  o Delete objects
  o Add properties
  o Change properties
  o Delete properties
  o Default permission
  o Change schema
  o Upload data
  o Add computed fields
  o Change computed fields
  o Delete computed fields

Document/Image/File
  o View management screens
  o Change permissions
  o Change/upload data
  o View

Session
  o View management screens
  o Change permissions
  o Change session config
  o Join/leave session
  o Save/discard session

Mail Host
  o View management screens
  o Change permissions
  o Change configuration




To support the architecture, developers must derive an
object from the AccessControl.RoleManager mixin class,
and define in their class an __ac_permissions__ attribute.

This should be a tuple of tuples, where each tuple represents
a permission and contains a string permission name as its first
element and a list of attribute names as its second element.

Example:

    __ac_permissions__=(

    ('View management screens',
     ['manage','manage_menu','manage_main','manage_copyright',
      'manage_tabs','manage_propertiesForm','manage_UndoForm']),
    ('Undo changes',       ['manage_undo_transactions']),
    ('Change permissions', ['manage_access']),
    ('Add objects',        ['manage_addObject']),
    ('Delete objects',     ['manage_delObjects']),
    ('Add properties',     ['manage_addProperty']),
    ('Change properties',  ['manage_editProperties']),
    ('Delete properties',  ['manage_delProperties']),
    ('Default permission', ['']),
    )



The developer may also predefine useful types of access, by
specifying an __ac_types__ attribute. This should be a tuple of
tuples, where each tuple represents a type of access and contains
a string name as its first element and a list of permission names
as its second element.

By default, only "Full Access" is defined (by the RoleManager mixin).
If you wish to override __ac_types__ to provide convenient types of
access, you must always be sure to define "Full Access" as containing
the names of all possible permissions for your object.

Example:

    __ac_types__=(

    ('Full Access', map(lambda x: x[0], __ac_permissions__)),
    ('Change', ['Add Objects', 'Add Properties', 'Change Properties']),

    )



Developers may also provide pre-defined role names that are
not deletable via the interface by specifying an __ac_roles__
attribute. This is probably not something we'll ever use under
the new architecture, but it's there if you need it.

Example:

    __ac_roles__=('Manager', 'Anonymous')

Re: [Phpwebsite-developers] RE: Phpwebsite-developers digest, Vol 1 #43 - 10 msgs

[Todd O. <to...@da...>]

Welcome to the group Bob.  I just posted a roadmap segment, but I wanted to
respond to some of your questions.

> 1. What is the current status of this project (it appears to be going
> in several different directions).
Appalacian State just opened phpWebSite to outside developers about 6 weeks
ago, and there has been lots of activity sense then.  We're all going in the
same direction--FORWARD.  Most of the "directions" you refer to have to do
with more advanced options.  I feel very comfortable with the group; we're
all getting along well and the conversations are very positive and polite.

> 2. Is the core code going to be rewritten?
Most likely.  Think of it like Linux firewalling; ipfwadm (2.0) is still
being used, athough it was totally rewritten as ipchains (2.2) and now
netfilter (2.4).  I think you should begin your involvement now.  phpBB is
being totally rewritten as version 2.0, but I still think 1.2 is the best
forum software I've used.  My point is that the current incarnation of phpWS
is great and will continue to be improved.

> 5. Who is the final decision maker on this project? Does this person have
a
> roadmap? Has anything been decided at this time?
Brian Brown at Appalacian state is the final decision maker for phpWS and
Matt McNarey (also at App State) is second in command.

> 6. Is there going to be a stripped down version of the core code and leave
> everything else as a plugin?
That's my goal, if there's consensus, but again there are already lots of
plug-ins being developed right now.

> I have slowed my progress down for obvious reasons and would like
> to see a solid foundation set so we can just get on with this and produce
> the best CMS/Portal there is.
Everyone that has posted to the developers list is very talented in my
opinion; the diversity of ideas (which may seem distracting at times) will
make phpWS the best CMS/Portal out there.  Some of those posting have only
been with the project a month or so, like myself.  We've covered a LOT of
ground in the last two weeks alone.

I am very passionate about the project as are many others on the development
team.  Our singular goal is to turn phpWS in a premier open source product.
So WELCOME !!!

--Todd Owen

Re: [Phpwebsite-developers] Roadmap

[Todd O. <to...@da...>]

I think Brian will let us know the vote for database abstraction layer by
Monday, if not before.  This will allow those coding for the current
structure to continue.

I agree that development on the current phpWS should not be affected by the
"redesign".  This should work something like the Linux kernel.  2.2
continues as 2.3 is developing, then at some point 2.4 is magically
complete.  I like the idea of 80% design and 20% code.  My degree is in
electrical engineering and I have designed some very large buildings ($120
million range).  A well thought out design is CRITICAL.  When building my
last prison, a change to the foundation would have been cripling to the
entire project.

That's why I think more dialog, like what we're having now, is very
beneficial and shouldn't be cut off today.  However, I do understand that
some people want to code and we do need standards for that code.  Things
like database abstraction layer, code indention and naming (underscores)
should be decided now and be used in both the "stable" and "development"
versions.  I propose we start using the odd and even version naming
beginning with version 0.8 and the rewrite will be 1.0.

Although I'm glued to every developer list email, I realize that lots of
others are using the Sourceforge forums.  Most of my work will be on the
rewrite, but that's OK because we'll still work together as a group, whether
you're primarily 0.8.x or 0.9.x.  There appear to be lots of plug-in module
programmers talking on the forums and they're ready to start coding.  Others
of us are ready to redesign.  Am I making any sense?  Am I the only one over
here or not?

--Todd

[Phpwebsite-developers] RE: Phpwebsite-developers digest, Vol 1 #43 - 10 msgs

[Bob M. <web...@is...>]

Hello everyone, I have been formally asked to join the developement team on
this project and have some questions.
1. What is the current status of this project (it appears to be going in
several different directions).
2. Is the core code going to be rewritten?
3. Is the user authentication system thats in place now going to be changed?
ie. session handling, cookie based...
4. Is there a set standard for the plugins and themes?
5. Who is the final decision maker on this project? Does this person have a
roadmap? Has anything been decided at this time?
6. Is there going to be a stripped down version of the core code and leave
everything else as a plugin?

I see too many responses in regards to what I have mentioned above and see
no actual plan or structure. I would like to get started on this as I have
customers that are very interested in this project but who are not willing
to wait on something that will take too long to accomplish. I have also been
working on this from another aspect as well and that is the integration of
phpWebSite and vBulletin along with many plugins that I have already
written, I have slowed my progress down for obvious reasons and would like
to see a solid foundation set so we can just get on with this and produce
the best CMS/Portal there is. Any comments or feedback?

Thamk you,
Bob McCambridge

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of
php...@li...
Sent: Friday, March 30, 2001 11:27 AM
To: php...@li...
Subject: Phpwebsite-developers digest, Vol 1 #43 - 10 msgs


Send Phpwebsite-developers mailing list submissions to
	php...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
or, via email, send a message with subject or body 'help' to
	php...@li...

You can reach the person managing the list at
	php...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Phpwebsite-developers digest..."


Today's Topics:

   1. Re: Template system: Proposal (Karsten Dambekalns)
   2. Re: Template system: Proposal (clayton collie)
   3. Re: Integrated User/Group & Permissions (clayton collie)
   4. Re: Template system: Proposal (Todd Owen)
   5. Re: Roadmap (Todd Owen)
   6. Good Feature to Consider [long] (clayton collie)
   7. Re: Integrated User/Group & Permissions (clayton collie)
   8. Re: Integrated User/Group & Permissions (Todd Owen)
   9. SV: [Phpwebsite-developers] Roadmap (Frits Jensen)
  10. Re: Good Feature to Consider [long] (Karsten Dambekalns)

--__--__--

Message: 1
Date: Fri, 30 Mar 2001 15:40:19 +0200
From: Karsten Dambekalns <k.d...@tu...>
To: php...@li...
Subject: Re: [Phpwebsite-developers] Template system: Proposal
Organization: fishfarm
Reply-To: php...@li...


--V88s5gaDVPzZ0KCq
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 30, 2001 at 07:56:17AM -0500, Todd Owen wrote:
> > leftbox
> > rightbox
> > main
>=20
> I think we're selling the project short if we have leftbox and rightbox,
> etc.  The themes need to be more generic and flexible.  Such as the
> following:
>=20
> --Objects on a certain page
> nav_bar, weather, articles, poll1, poll2 (second instance), job_posts,
> header, footer

Right. But will these be "blocks" or not? That is, do we need special styles
for those?

I think we should stick with something like left,right,main, for the sake of
simplicity. If we jave something like {leftblocks}, we have the opportunity
to let the system reorder the single blocks within that.

> --Theme/template
> <html><body>
> <style sheet here>
> {header}<br />
> <table>
> <tr><td>{nav_bar}</ td><td>{articles}</ td>
> <td>{poll1}</ td><td>{poll2}</ td></ tr> <hr />
> <tr><td>{weather}</ td><td>{job_posts}</ td></ tr>
> </ table>
> <br />{footer}
> </ body></ html>

How would the system know that those placeholders exist? And what about a
plugin? Is this was to go into the {plugin} part of the template, all would
be well. But if that plugin neede something like {my_blah_plugin}, you
wouldn't be able to use that plugin with some other theme...

> You see my point.  We need to have each of the page objects separate, then
> allow the theme/template to arrange them independant of left, main and to=
p.

Yes, seperatley, but following some rules. If I may lay out some ideas...
(we might have something like this as documentataion on "how to write
themes"):
--------------------------
- A theme has to provide at least one page template, one block template and
  exactly one stylesheet.

- The stylesheet *must* define the following classes and tags in that class=
es:
  (insert with what Frits and/or others come up) [1]

- The stylesheet *may* define additional styles for classes or tags used
  solely in the corresponding template. The must not interfer with the
  standard PHPWS style/class names. [1]

- The page template *must* provide placeholders for:
  - blocks1, blocks2, blocks3, blocks4 [2]
  - plugins1, plugins2 [2]
  - header [3]
  - footer [3]
  - main [4]
  - menu

- The block template *must* define a standard block for use with the
  format_block($title,$content) function (or whatever function there may
  be).

- The theme *may* define more block templates, which can be assigned to
  individual blocks through the admin interface.
--------------------------

This is mainly a proposal, although I would consider it thought through, at
least in a basic way :-)

[1] By setting up rules for the stylesheet, we achieve a minimum level of
compatibility between templates. By allowing additional rules in them, we
give designers some more freedom.

[2] The page must define 4 block and 2 plugin placeholders, because we could
give the possibility to assign a plugin or block to one of the block or
plugin "places". I do not name them blocks_left, blocks_top, et al, because
that would imply a position. Having them numbered, gives a theme author the
possibility to place blocks1 and blocks2 directly above each other, for
example.
 - Question: shall we seperate blocks and plugins, or shall plugins be plced
   like blocks?
 - Question: Are 4 (6) blocks/block positions enough?

[3] These would be for placing some smallprint (like at the bottom of the
page and what is $titlebar in config.php now)

[4] Here would go anything else that is produced dynamically (except the
menu, of course).

REMEMBER: These rules are for standard themes (and their authors), they make
sure that a theme is fully compatible with an out-of-the-box install of
PHPWS. If one wants to develop a theme for personal use, he/she could easily
omit blocks3 and blocks4, as well as the header. He wouldn't be able to
complain about being able to assign plugin x to blocks3, though :-) And such
a template wouldn't pass QA at Appstate and therefore wouldn't be offered on
the download page.

That's it, sorry for the much too long post (again!) :o)

Regards,
Karsten
--=20
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w=B3: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

--V88s5gaDVPzZ0KCq
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1e-SuSE (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6xIzCzmcQByaBiO8RAgW2AKDelxt940Ns6ynE6bWcXBRrTW4AtACgwSHj
CpzGpVmPVHP5dseRA/bjf7Y=
=wyIR
-----END PGP SIGNATURE-----

--V88s5gaDVPzZ0KCq--


--__--__--

Message: 2
From: "clayton collie" <cc...@ca...>
To: <php...@li...>
Subject: Re: [Phpwebsite-developers] Template system: Proposal
Date: Fri, 30 Mar 2001 09:15:17 -0500
Reply-To: php...@li...

Karsten,

> - The page template *must* provide placeholders for:
>  - blocks1, blocks2, blocks3, blocks4 [2]
>  - plugins1, plugins2 [2]
>  - header [3]
>  - footer [3]
>  - main [4]
i hate to harp on Smarty again, but one nicety it has is that you (the
developer) can define custom tags which can take parameters which can come
from PHP variables or a config file. So you can have something like :

{block number=$block_number position=$block_position theme=$site_theme}

to implement this you would then define a function in an addon file which
takes the parameters passed to it and return an html fragment. if needed,
you can put the tag in a template block which generates the required
parameters.


btw
for some reason, all your messages appear as attachments in LookOut Express
----- Original Message -----
From: "Karsten Dambekalns" <k.d...@tu...>
To: <php...@li...>
Sent: Friday, 30. March 2001 8:40
Subject: Re: [Phpwebsite-developers] Template system: Proposal





--__--__--

Message: 3
From: "clayton collie" <cc...@ca...>
To: <php...@li...>
Subject: Re: [Phpwebsite-developers] Integrated User/Group & Permissions
Date: Fri, 30 Mar 2001 09:31:24 -0500
Reply-To: php...@li...

WD,
  i dont know if its ok to send attachments through the list. email me
privately (my email address is visible, right ?) and i'll send it to you ..

----- Original Message -----
From: "W.D.Sumilang" <wa...@on...>
To: <php...@li...>
Sent: Thursday, 29. March 2001 18:16
Subject: RE: [Phpwebsite-developers] Integrated User/Group & Permissions





--__--__--

Message: 4
From: "Todd Owen" <to...@da...>
To: <php...@li...>
Subject: Re: [Phpwebsite-developers] Template system: Proposal
Date: Fri, 30 Mar 2001 09:35:38 -0500
Organization: Data Dynamix
Reply-To: php...@li...

Karsten, you're correct; we should make the themes use block1, block2, etc.
to make them more generic, in lieu of the specific names I gave them.

We should have an agreed upon set of style sheet parameters that is used
throughout the PHP code on the site including plug-in modules.  If a plug-in
developer wants to use a new CSS parameter, that's OK, but it must fall back
to one of the standards if not included in a default theme--this would keep
things from breaking (i.e. looking strange).

--Todd

TRANSLATE[[ As a loyal vi user, I continue to take offense to Karsten's
signature block.  Unless it stops, all Big Brother vi users will be forced
to retaliate ;) ]]




--__--__--

Message: 5
From: "Todd Owen" <to...@da...>
To: <php...@li...>
Subject: Re: [Phpwebsite-developers] Roadmap
Date: Fri, 30 Mar 2001 09:39:04 -0500
Organization: Data Dynamix
Reply-To: php...@li...

My proposal is that EVERYTHING should be a plug-in, including much of what
is now "core" functionality, like the referrer tracking, categories and
polls.  I want to see phpWS as more of an erector site, with just about
everything available a la carte.  What does everyone think about this?  I
think it helps a user mentally organize phpWS and makes my database scheme
;) look more logical.

Each plug-in module would have its own admin page too and it would be the
perfect place to add access control.

--Todd




--__--__--

Message: 6
From: "clayton collie" <cc...@ca...>
To: <php...@li...>
Subject: [Phpwebsite-developers] Good Feature to Consider [long]
Date: Fri, 30 Mar 2001 10:00:19 -0500
Reply-To: php...@li...

This is long, so bear with me ...

in my portal seeking travels, i ran across TerraCotta
(www.terracottasoftware.com) which provides basic infrastucture for
site-building. the docs make for good reading. they have a few very
interesting features (one of which is that you can automatically download
and install features from other terracotta sites - dont ask me about
security)

in any case one of the issues i was contemplating was one of module
dependencies (actually there are two levels of dependency, but i'll just
deal with one)

 lets say david d. developer creates a plugin which mails out notices when
concerts are added to the event calendar. well as it stands, we would have
to go in and modify the calendar code to accomodate this. also, if he wants
to give the 1000th registered member a free subscription to his dead-tree
magazine, he'd have to muck about in the code again. and what if he decides
to yank the calendar plugin ? well then youve got orphan DB entries to deal
with and your other plugins will crash and burn expecting to find something
that aint there.

one way to handle this is by Alerts ( TC's description and implementation
details at www.terracottasoftware.com/tc/doc/alerts ). basically you
register interest in events with a callback. when those events occur, your
code gets called. these "events" are stored in the database, and you can set
up a cron job to process them. they have urgency levels, so a low-disk quota
event would get handled before user registration event. They can also be
filtered.  so in our example the calendar module would call a raise_event()
function whenever someone added a new entry (events have associated data, so
you can store details). The registration module can raise an event when
someone registers.
  Alerts can get expensive, so we dont do them for very frequently occurring
events. Also for efficiency purposes, we can have an events_registered field
in the plugins table so that a plugin only needs to raise an event if
someone is interested.

<question to self>then again, can we manage all of this via cron? but this
way we have a greater level control which we can exercise via a web
interface</question>

just a thought...

BTW
PHPWeblog uses their html parser to screen user posts. it has a configurable
level of screening.
Their "Views" feature is an interesting take on block content handling. We
should probably look a this too.

----- Original Message -----
From: "Mike Windsor" <wi...@ce...>
To: <php...@li...>
Sent: Thursday, 29. March 2001 22:16
Subject: [Phpwebsite-developers] Roadmap


> Hey,
> Was there a meeting scheduled for tomorrow? Is it still on?  Will a
decision
> "roadmap" be laid out tomorrow on March 30?
> Just wondering when we will get some direction?  Not that I will be much
> help but I would like to know if I should continue to follow this project
or
> find another. Although I have limited code knowledge I would like to began
> to learn something  maybe about plugins.  I've looked at some of the
plugins
> now and see a little bit about how they work, but it sounds like it might
> get changed around a bit.
> I've talked to other people who have made forums or weather scripts or
> financial scripts and I convinced some of them to take a look at
phpWebSite,
> they and I believe that the first plugin in any category will more than
> likely be the standad in the beginning which will bring more people to
their
> own script and improve it.  I think if you end up debating on the best
> approach to long many are going to lose interest and go with the next
> version of nuke5 that is going to have "modules",  and this project will
> lose out.  I understand things like this take planning and so forth, but
my
> wish would be for a very well thought out decision done in a timely
matter.
> Hopefully we get a sense of direction by this weekend.
> Anyway, I'll just sit here with my sharp stick and prod you along <g>
>
>
> winzor
> (wanna be)
>
>
>
> ----- Original Message -----
> From: "Spiggy TheCat" <th...@me...>
> To: <php...@li...>
> Sent: Thursday, March 29, 2001 8:14 PM
> Subject: [Phpwebsite-developers] about mysql (slightly OT)
>
>
> > people who checked the openacs site, might have stumbled into this
(rather
> > lengthy with all the comments) article. people at openacs seem to be
> really
> > against mysql.
> >
> > http://openacs.org/philosophy/why-not-mysql.html
> >
> > paivi
> >
> >
> > _______________________________________________
> > Phpwebsite-developers mailing list
> > Php...@li...
> > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> >
> >
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers



--__--__--

Message: 7
From: "clayton collie" <cc...@ca...>
To: <php...@li...>
Subject: Re: [Phpwebsite-developers] Integrated User/Group & Permissions
Date: Fri, 30 Mar 2001 10:09:53 -0500
Reply-To: php...@li...

Alain,
   > http://www.phpsecurepages.f2s.com/
>
> This looks really good !

yes, but the problem is granularity. this only deals with coarse-grained,
page-level access. we need (i think) a generalized system to deal with
arbitrary objects in the system (can user x or group g do y with object a)


----- Original Message -----
From: "Alain Fontaine" <al...@va...>
To: <php...@li...>
Sent: Thursday, 29. March 2001 17:29
Subject: RE: [Phpwebsite-developers] Integrated User/Group & Permissions


> Hi,
>
> http://www.phpsecurepages.f2s.com/
>
> This looks really good !
>
> Take a look.
>
> Alain
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers



--__--__--

Message: 8
From: "Todd Owen" <to...@da...>
To: <php...@li...>
Subject: Re: [Phpwebsite-developers] Integrated User/Group & Permissions
Date: Fri, 30 Mar 2001 10:43:54 -0500
Organization: Data Dynamix
Reply-To: php...@li...

> yes, but the problem is granularity. this only deals with coarse-grained,
> page-level access. we need (i think) a generalized system to deal with
> arbitrary objects in the system (can user x or group g do y with object a)

I agree that we need per object instance level access control.  This means
that you may only have one forum plug-in, which the site admin gets to
control, but two forum instances that require separate access control by
different users.

This is part of my roadmap.

--Todd




--__--__--

Message: 9
From: Frits Jensen <FJ...@uv...>
To: "'php...@li...'"
	 <php...@li...>
Subject: SV: [Phpwebsite-developers] Roadmap
Date: Fri, 30 Mar 2001 17:31:22 +0200
Reply-To: php...@li...

I totally agree! This way the obvious danger of mess, interference and
disagreements is avoided. It cannot be avoided that some want to make things
different than others out of need, religion or whatever reason. Is
everything in modules, forced to compatibility by standards set by the core
program, set by Appalachian on input of everybody, hey - everybody is happy
:) More product, less fuss. We can easily have two 'official' versions of a
plugin, thus having creative and productive "arguments" (my plugin is more
popular than yours) instead of stopping democracy - Join the force of your
choice.

Less chance of core problems! 'This plugin returns error' is better than
'This product returns error'

Also it will reduce the betaversions, as the central core will be easier to
produce, and then one may have to wait for plugins, but this must be better
than to wait for the whole package..

Another obvious, and I should think extremely giving bonus, is that
programmers will have more to show; "Plugin by:.." instead of "Contributors
to the project, version this and that:..."

The core should *never* sacrifice anything in order to be
backwards-compatible between major releases. A plugin should have a number
in its name, referring to which version of core it worked with, eg
'weather_plugin_7.php'. The reason for this is that this is free code, not
expansive hardware - you can just upgrade everything if you want to move to
next major release - This way we can get a head start, and move fast and
flexible - not get stuck like some well known DOS-based OS, or as a large
non-module-based project easily could be.

The guys at Appalachian should kick back and decide which plugins they'd
recognise, then put them on the official site after validating XTML, safe
programming, etc.


BTW; I am working on a proposal for CSS standards. Anyone read my (and
Karstens) thoughts, and have comments?


=) I think this whole community thing is way far out funny; Humanoids are
moving from individuals to interacting cells in a large producing organism.
Maybe if the right circumstances are there, life eventually will occur.
Given the chance of communicating with ASCII in real-time on a global basis,
coding eventually will occur. Hello fellow cells :) Forgive me for looking
down.. Hail Todd. Frits.

> -----Oprindelig meddelelse-----
> Fra: Todd Owen [mailto:to...@da...]
> Sendt: 30. marts 2001 16:39
> Til: php...@li...
> Emne: Re: [Phpwebsite-developers] Roadmap
>
>
> My proposal is that EVERYTHING should be a plug-in, including
> much of what
> is now "core" functionality, like the referrer tracking,
> categories and
> polls.  I want to see phpWS as more of an erector site, with
> just about
> everything available a la carte.  What does everyone think
> about this?  I
> think it helps a user mentally organize phpWS and makes my
> database scheme
> ;) look more logical.
>
> Each plug-in module would have its own admin page too and it
> would be the
> perfect place to add access control.
>
> --Todd
>
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>


--__--__--

Message: 10
Date: Fri, 30 Mar 2001 18:16:03 +0200
From: Karsten Dambekalns <k.d...@tu...>
To: php...@li...
Subject: Re: [Phpwebsite-developers] Good Feature to Consider [long]
Organization: fishfarm
Reply-To: php...@li...


--jKBxcB1XkHIR0Eqt
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 30, 2001 at 10:00:19AM -0500, clayton collie wrote:

> one way to handle this is by Alerts ( TC's description and implementation
> details at www.terracottasoftware.com/tc/doc/alerts ). basically you
> register interest in events with a callback. when those events occur, your

Another source of information about his is the excellent book by Till Gerken
"Web Application Development with PHP4" published by New Riders. He
describes the callback system used in phpChat - which can be downloaded at
http://www.phpwizard.net/ and also is a good reading :-)

There we could look at callback functionality realized in PHP...

Regards,
Karsten
--=20
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w=B3: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

--jKBxcB1XkHIR0Eqt
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1e-SuSE (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6xLFCzmcQByaBiO8RAn5VAJ44jPcWgPuqg3jK9t5x2vK1rRQmRgCfeGWT
H5oZ3kjEWCgP7AYD8YyFo2I=
=rX7E
-----END PGP SIGNATURE-----

--jKBxcB1XkHIR0Eqt--



--__--__--

_______________________________________________
Phpwebsite-developers mailing list
Php...@li...
http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers


End of Phpwebsite-developers Digest

[Phpwebsite-developers] Plugin Interface for incorporating other apps

[Jason C. <cam...@xp...>]

I haven't been posting anything lately on the list or on the forums I've 
just been reading all the discussions and I've been ready to code something 
for awhile now :)  Yea I know we should get some things changed before 
coding but I'm a coder at heart what can I say...!  Anyways, a new idea...

Has anyone thought about how we could take say a guestbook with its own 
tables and structure etc and have it work with phpWebSite without changing 
the code of either app?  I've been thinking about this and have a few ideas 
on it.

1) We could either pass their username/pw to the other app (not too safe)
2) We could have another table with user names and encrypted pws to send to 
the other app's login page and have it login the user that way.  The 
encrypted PW would be their pw for all the plugged-in applications like say 
a chat script, guestbook, etc.
3) I think phpWebSite's login module needs to be redone before this could 
be used in a safe matter.

Anyone got any ideas on this subject.....


Jason Campbell
Xplozive Media Technologies
www.xplozivemedia.com

[Phpwebsite-developers] Wondering about today...

[Jason C. <cam...@xp...>]

So today has come and its almost gone for us over here in the USA.  I can't 
wait to see the vote count on the dev team voting :)  Should be interesting 
to see and we can finally start to work on some code I hope.  I'm itching 
to start coding again!

Jason Campbell
Xplozive Media Technologies
www.xplozivemedia.com

RE: [Phpwebsite-developers] Good Feature to Consider [long]

[Geoff S. <Ge...@Ho...>]

The specific example you cite (a plug-in that wants to mail something out)
brings up an interesting point.

A really good mailing list system that has an api or whatever to allow
plug-ins to use it should be a core function.

The reason is that we would want for the mailing list to be well integrated
with the administration system and the user registration system so that when
someone signs up, they can select mailing lists they want to be on and
notifications they want to receive when things happen in the various
plug-ins. So, a plug-in capability should be the ability to register mailing
list and notification items.

Geoff

Geoff Staples,
Hostricity Web Hosting <http://www.hostricity.com/>

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of
clayton collie
Sent: Friday, March 30, 2001 9:00 AM
To: php...@li...
Subject: [Phpwebsite-developers] Good Feature to Consider [long]


This is long, so bear with me ...

in my portal seeking travels, i ran across TerraCotta
(www.terracottasoftware.com) which provides basic infrastucture for
site-building. the docs make for good reading. they have a few very
interesting features (one of which is that you can automatically download
and install features from other terracotta sites - dont ask me about
security)

in any case one of the issues i was contemplating was one of module
dependencies (actually there are two levels of dependency, but i'll just
deal with one)

 lets say david d. developer creates a plugin which mails out notices when
concerts are added to the event calendar. well as it stands, we would have
to go in and modify the calendar code to accomodate this. also, if he wants
to give the 1000th registered member a free subscription to his dead-tree
magazine, he'd have to muck about in the code again. and what if he decides
to yank the calendar plugin ? well then youve got orphan DB entries to deal
with and your other plugins will crash and burn expecting to find something
that aint there.

one way to handle this is by Alerts ( TC's description and implementation
details at www.terracottasoftware.com/tc/doc/alerts ). basically you
register interest in events with a callback. when those events occur, your
code gets called. these "events" are stored in the database, and you can set
up a cron job to process them. they have urgency levels, so a low-disk quota
event would get handled before user registration event. They can also be
filtered.  so in our example the calendar module would call a raise_event()
function whenever someone added a new entry (events have associated data, so
you can store details). The registration module can raise an event when
someone registers.
  Alerts can get expensive, so we dont do them for very frequently occurring
events. Also for efficiency purposes, we can have an events_registered field
in the plugins table so that a plugin only needs to raise an event if
someone is interested.

<question to self>then again, can we manage all of this via cron? but this
way we have a greater level control which we can exercise via a web
interface</question>

just a thought...

BTW
PHPWeblog uses their html parser to screen user posts. it has a configurable
level of screening.
Their "Views" feature is an interesting take on block content handling. We
should probably look a this too.

----- Original Message -----
From: "Mike Windsor" <wi...@ce...>
To: <php...@li...>
Sent: Thursday, 29. March 2001 22:16
Subject: [Phpwebsite-developers] Roadmap


> Hey,
> Was there a meeting scheduled for tomorrow? Is it still on?  Will a
decision
> "roadmap" be laid out tomorrow on March 30?
> Just wondering when we will get some direction?  Not that I will be much
> help but I would like to know if I should continue to follow this project
or
> find another. Although I have limited code knowledge I would like to began
> to learn something  maybe about plugins.  I've looked at some of the
plugins
> now and see a little bit about how they work, but it sounds like it might
> get changed around a bit.
> I've talked to other people who have made forums or weather scripts or
> financial scripts and I convinced some of them to take a look at
phpWebSite,
> they and I believe that the first plugin in any category will more than
> likely be the standad in the beginning which will bring more people to
their
> own script and improve it.  I think if you end up debating on the best
> approach to long many are going to lose interest and go with the next
> version of nuke5 that is going to have "modules",  and this project will
> lose out.  I understand things like this take planning and so forth, but
my
> wish would be for a very well thought out decision done in a timely
matter.
> Hopefully we get a sense of direction by this weekend.
> Anyway, I'll just sit here with my sharp stick and prod you along <g>
>
>
> winzor
> (wanna be)
>
>
>
> ----- Original Message -----
> From: "Spiggy TheCat" <th...@me...>
> To: <php...@li...>
> Sent: Thursday, March 29, 2001 8:14 PM
> Subject: [Phpwebsite-developers] about mysql (slightly OT)
>
>
> > people who checked the openacs site, might have stumbled into this
(rather
> > lengthy with all the comments) article. people at openacs seem to be
> really
> > against mysql.
> >
> > http://openacs.org/philosophy/why-not-mysql.html
> >
> > paivi
> >
> >
> > _______________________________________________
> > Phpwebsite-developers mailing list
> > Php...@li...
> > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> >
> >
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers


_______________________________________________
Phpwebsite-developers mailing list
Php...@li...
http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

[Phpwebsite-developers] myphpNuke

[Mike W. <wi...@ce...>]

Here is a fork off nuke and he has already done a great deal with the block
issue.  Read more here.

http://www.kodewulf.za.net/article.php?sid=76&mode=thread&order=0


winzor


----- Original Message -----
From: "Karsten Dambekalns" <k.d...@tu...>
To: <php...@li...>
Sent: Friday, March 30, 2001 10:22 AM
Subject: Re: [Phpwebsite-developers] Template system: Proposal

SV: [Phpwebsite-developers] Template system: Proposal

[Frits J. <FJ...@uv...>]

Pardon for the way too long mail - I do not dare to edit in others material
- Regarding CSS standardizing, Todd, Karsten, Frits:

> -----Oprindelig meddelelse-----
> Fra: Karsten Dambekalns [mailto:k.d...@tu...]
> Sendt: 30. marts 2001 15:40
> Til: php...@li...
> Emne: Re: [Phpwebsite-developers] Template system: Proposal
> 
> 
> On Fri, Mar 30, 2001 at 07:56:17AM -0500, Todd Owen wrote:
> > > leftbox
> > > rightbox
> > > main
> > 
> > I think we're selling the project short if we have leftbox 
> and rightbox,
> > etc.  The themes need to be more generic and flexible.  Such as the
> > following:
> > 
> > --Objects on a certain page
> > nav_bar, weather, articles, poll1, poll2 (second instance), 
> job_posts,
> > header, footer
> 
> Right. But will these be "blocks" or not? That is, do we need 
> special styles
> for those?
> 
> I think we should stick with something like left,right,main, 
> for the sake of
> simplicity. If we jave something like {leftblocks}, we have 
> the opportunity
> to let the system reorder the single blocks within that.

Yeah! It should be


'PrimaryBox', 'SecondaryBox', 'MainBox', 'SpecialStrong', 'SpecialFaint',
and 'Ident'.


You see each of these should have a full set of full descriptions on
_everything_ possible in CSS.
This way you could end op using <h1> in 6 different places, and having this
to be 6 completely different looks! My graphic teacher put emphasis on never
having more than 3 font types on a page, but within this system you could
have <h1> -> <h6> and <body> = 7 different fonts, times the 6 different
categories = 42 different fonts on your page at once. Combinations with
links not counted for. I am telling you *if* this system will act as a
limit, it is only good for the overall looks :)

Let me try and explain the use of the 'subsets' I was thinking of, in
*typical* use. Each of the following would have _complete_ CSS control (for
those who dont know; this is way much control). 



Tell me in which situation, other than the one where you would like a mess,
the following would not be enough:

'PrimaryBox': Typically used as what is now typically Left Box. This kind of
object is on all the time, like menus and navigators. To this category, also
other objects that is displayed in a similar way, typically benieth,
belongs. To emphasize; Each of the 8 parts 

+------1------+
|             |
2  Headline   3
|             |
+------4------+
+------5------+
|             |
|             |
6  Body text  7
|             |
|             |
+------8------+

of this (and all other subsets) will have individual "margin", "body" and
"padding" to be set with each of the subsets like color, thicknes and so on.
I should invent a system for naming the levels. Also you will have complete
control of everything else, like <h1> -> <body>, <hr> and so on in the
subset.

'SecondaryBox': Typically polls, newsflash-boxes, adverts, more flashy stuff
that you would only want on your front page. Typically is the use of what
now is Right Box.

'MainBox': The body of the pages, all that is brought to focus; Calenders,
searchresults, main stories, threads and so on. To emphasize; within this,
as in all other, you could have <h1> -> <h6> and <body> etc, giving you
plenty of playroom for your design.

'SpecialStrong': On occations you'd like to break out of your design - YOU'D
LIKE TO SHOUT, like on errors, administration notes, etc. This subset is for
defining how "things in red" should look like.

'SpecialFaint': Copyright notes, picture descriptions, hints on forms. You
would not have to have this in a design that would differ from the rest, but
this set of subsets for design would give you the possibility.

'Ident': The final one; Just in case you'd want to use CSS on your logo.
Coded to be used on what is now 'the top-bar'.

Some might argue that you'd need the possibility of having a plugin-subset,
but as plugins should end up being the main generator of public content, the
output should slide in with the rest of the web - Plugins should not be
plugins for the ordinary user. Also see Karstens argument on 'Knowing which
plugin to belong to' hereunder.

All the tables should have 0 in 'border', 'cellspacing', and 'cellpadding',
'width' and 'height' not defined, as this should be defined by the CSS, and
be neutral without.

I will try and document the above with illustrations in a document, that
should be handed out to those who would like to design a CSS for
PhpWebsite.. More thoughts welcome.

Frits

> 
> > --Theme/template
> > <html><body>
> > <style sheet here>
> > {header}<br />
> > <table>
> > <tr><td>{nav_bar}</ td><td>{articles}</ td>
> > <td>{poll1}</ td><td>{poll2}</ td></ tr> <hr />
> > <tr><td>{weather}</ td><td>{job_posts}</ td></ tr>
> > </ table>
> > <br />{footer}
> > </ body></ html>
> 
> How would the system know that those placeholders exist? And 
> what about a
> plugin? Is this was to go into the {plugin} part of the 
> template, all would
> be well. But if that plugin neede something like {my_blah_plugin}, you
> wouldn't be able to use that plugin with some other theme...
> 

Excactly! Frits.

> > You see my point.  We need to have each of the page objects 
> separate, then
> > allow the theme/template to arrange them independant of 
> left, main and top.
> 
> Yes, seperatley, but following some rules. If I may lay out 
> some ideas...
> (we might have something like this as documentataion on "how to write
> themes"):
> --------------------------
> - A theme has to provide at least one page template, one 
> block template and
>   exactly one stylesheet.
> 
> - The stylesheet *must* define the following classes and tags 
> in that classes:
>   (insert with what Frits and/or others come up) [1]
> 

As above..

> - The stylesheet *may* define additional styles for classes 
> or tags used
>   solely in the corresponding template. The must not interfer with the
>   standard PHPWS style/class names. [1]
> 
> - The page template *must* provide placeholders for:
>   - blocks1, blocks2, blocks3, blocks4 [2]
>   - plugins1, plugins2 [2]
>   - header [3]
>   - footer [3]
>   - main [4]
>   - menu
> 
> - The block template *must* define a standard block for use with the
>   format_block($title,$content) function (or whatever 
> function there may
>   be).
> 
> - The theme *may* define more block templates, which can be 
> assigned to
>   individual blocks through the admin interface.
> --------------------------
> 
> This is mainly a proposal, although I would consider it 
> thought through, at
> least in a basic way :-)
> 
> [1] By setting up rules for the stylesheet, we achieve a 
> minimum level of
> compatibility between templates. By allowing additional rules 
> in them, we
> give designers some more freedom.
> 
> [2] The page must define 4 block and 2 plugin placeholders, 
> because we could
> give the possibility to assign a plugin or block to one of 
> the block or
> plugin "places". I do not name them blocks_left, blocks_top, 
> et al, because
> that would imply a position. Having them numbered, gives a 
> theme author the
> possibility to place blocks1 and blocks2 directly above each 
> other, for
> example.
>  - Question: shall we seperate blocks and plugins, or shall 
> plugins be plced
>    like blocks?
>  - Question: Are 4 (6) blocks/block positions enough?
> 
> [3] These would be for placing some smallprint (like at the 
> bottom of the
> page and what is $titlebar in config.php now)
> 
> [4] Here would go anything else that is produced dynamically 
> (except the
> menu, of course).
> 
> REMEMBER: These rules are for standard themes (and their 
> authors), they make
> sure that a theme is fully compatible with an out-of-the-box 
> install of
> PHPWS. If one wants to develop a theme for personal use, 
> he/she could easily
> omit blocks3 and blocks4, as well as the header. He wouldn't 
> be able to
> complain about being able to assign plugin x to blocks3, 
> though :-) And such
> a template wouldn't pass QA at Appstate and therefore 
> wouldn't be offered on
> the download page.
> 
> That's it, sorry for the much too long post (again!) :o)
> 
> Regards,
> Karsten
> -- 
> Why do we have to hide from the police, daddy?
> Because we use emacs, son. They use vi.
> -----------------------------
> mailto:k.d...@tu... w³: http://www.k-fish.de/
> gpg: http://www.k-fish.de/mykeys.gpg
> 

Re: [Phpwebsite-developers] Template system: Proposal

[Karsten D. <k.d...@tu...>]

On Fri, Mar 30, 2001 at 09:35:38AM -0500, Todd Owen wrote:

> TRANSLATE[[ As a loyal vi user, I continue to take offense to Karsten's
> signature block.  Unless it stops, all Big Brother vi users will be forced
> to retaliate ;) ]]

ROTFLOL :-))

Karsten
--=20
Why do we have to hide from the police, daddy?
Because we use emacs^H^H^H^H^Hvi, son. They use vi^H^Hemacs.
-----------------------------
mailto:k.d...@tu... w=B3: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

Re: [Phpwebsite-developers] Good Feature to Consider [long]

[Karsten D. <k.d...@tu...>]

On Fri, Mar 30, 2001 at 10:00:19AM -0500, clayton collie wrote:

> one way to handle this is by Alerts ( TC's description and implementation
> details at www.terracottasoftware.com/tc/doc/alerts ). basically you
> register interest in events with a callback. when those events occur, your

Another source of information about his is the excellent book by Till Gerken
"Web Application Development with PHP4" published by New Riders. He
describes the callback system used in phpChat - which can be downloaded at
http://www.phpwizard.net/ and also is a good reading :-)

There we could look at callback functionality realized in PHP...

Regards,
Karsten
--=20
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w=B3: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

SV: [Phpwebsite-developers] Roadmap

[Frits J. <FJ...@uv...>]

I totally agree! This way the obvious danger of mess, interference and
disagreements is avoided. It cannot be avoided that some want to make things
different than others out of need, religion or whatever reason. Is
everything in modules, forced to compatibility by standards set by the core
program, set by Appalachian on input of everybody, hey - everybody is happy
:) More product, less fuss. We can easily have two 'official' versions of a
plugin, thus having creative and productive "arguments" (my plugin is more
popular than yours) instead of stopping democracy - Join the force of your
choice.

Less chance of core problems! 'This plugin returns error' is better than
'This product returns error'

Also it will reduce the betaversions, as the central core will be easier to
produce, and then one may have to wait for plugins, but this must be better
than to wait for the whole package..

Another obvious, and I should think extremely giving bonus, is that
programmers will have more to show; "Plugin by:.." instead of "Contributors
to the project, version this and that:..."

The core should *never* sacrifice anything in order to be
backwards-compatible between major releases. A plugin should have a number
in its name, referring to which version of core it worked with, eg
'weather_plugin_7.php'. The reason for this is that this is free code, not
expansive hardware - you can just upgrade everything if you want to move to
next major release - This way we can get a head start, and move fast and
flexible - not get stuck like some well known DOS-based OS, or as a large
non-module-based project easily could be.

The guys at Appalachian should kick back and decide which plugins they'd
recognise, then put them on the official site after validating XTML, safe
programming, etc.


BTW; I am working on a proposal for CSS standards. Anyone read my (and
Karstens) thoughts, and have comments?


=) I think this whole community thing is way far out funny; Humanoids are
moving from individuals to interacting cells in a large producing organism.
Maybe if the right circumstances are there, life eventually will occur.
Given the chance of communicating with ASCII in real-time on a global basis,
coding eventually will occur. Hello fellow cells :) Forgive me for looking
down.. Hail Todd. Frits.

> -----Oprindelig meddelelse-----
> Fra: Todd Owen [mailto:to...@da...]
> Sendt: 30. marts 2001 16:39
> Til: php...@li...
> Emne: Re: [Phpwebsite-developers] Roadmap
> 
> 
> My proposal is that EVERYTHING should be a plug-in, including 
> much of what
> is now "core" functionality, like the referrer tracking, 
> categories and
> polls.  I want to see phpWS as more of an erector site, with 
> just about
> everything available a la carte.  What does everyone think 
> about this?  I
> think it helps a user mentally organize phpWS and makes my 
> database scheme
> ;) look more logical.
> 
> Each plug-in module would have its own admin page too and it 
> would be the
> perfect place to add access control.
> 
> --Todd
> 
> 
> 
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>