phpwebsite-developers — For our development team.

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

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

> 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

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

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

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

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

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

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

Re: [Phpwebsite-developers] Roadmap

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

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

Re: [Phpwebsite-developers] Template system: Proposal

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

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 ;) ]]

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

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

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

Re: [Phpwebsite-developers] Template system: Proposal

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

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

Re: [Phpwebsite-developers] Template system: Proposal

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

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

Re: [Phpwebsite-developers] Template system (Smarty)

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

RE more flexible page layout

Todd,
  i completely agree ! dont you just hate it when you go to the net and find
50million sites that look exactly like yours ? aside from showing
appreciation to the developers, i may not broadcast what software is driving
sites i may do for customers. <plug>the good thing about Smarty is that you
can define your own "parameterized" tags (they remind me slightly of
ColdFusion), so you can accomodate situations like this in a customized way
</plug>

Re: [Phpwebsite-developers] Template system (Smarty)

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

> 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

--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>

Oops, did I have four columns instead of three on top, then just two on the
bottom?
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.

--Todd

Re: [Phpwebsite-developers] Template system (Smarty)

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

On Thu, Mar 29, 2001 at 09:37:08PM +0200, Frits Jensen wrote:

> I suppose IE 5.5/Win is 100% print/monitor, but in general, I should think
> one exciting thing of this project is 'doing it right' - so if for nothing

Yep! Doing it right, just for the sake of it! Though it can be hard
sometimes :-)

> > What are those for? Or do you mean leftbox_menu { padding-left: ...
> > padding-right:... } ?!?
>=20
> lol - I was dumb enough to try and describe the mathematics, using imagin=
ary
> syntax.. Sorry, I can see it makes no sense. Perhaps this will: (no syntax
> now, just describing how many 'tags' needed)
>=20
> We have 5 areas:
>=20
> leftbox
> rightbox
> main
> special_big
> special_small

Are that enough? Everyone: Think about that, and submit ideas! What comnes
to my mind immediately is: what about Weblinks, Articles, et al. Do we need
seperate defintions for those, or are they just "main"? And if they will be
rewritten as plugins or modules seperate from the core system, what happens
then? Styles for plugins?

> Theese will each need all the usual stuff as 'h1 font size' for each 5, '=
h2
> font size' for each 5 and so on.
>=20
> Second, I was trying to describe how some need padding, border, etc for a=
ll
> four sides (Not just h1, but left padding, right padding, etc), marked
> individually, and so on.

Right.

> The main thing in my nonsense was that all there is to work with is one of
> those 5 'subsets'; When coding, you could chose if your object belonged to
> leftbox, rightbox, main, special_big, or special_small, and within this y=
ou
> then could choose say 'h1'. I cannot remember the syntax but I will creat=
e a
> complete set if u agree and understand..

Yes do that. Maybe you don't need to write a full stylesheet at first, but
rather refine the proposed structure (waiting for input to my above
mentioned call...) and make a "real" stylesheet afterwards.

> One extra subset for the top-bar would be needed.

Ack.

> Thanks for the backup - I'll get to it - Only I am kinda new to all this
> hacking, so please confirm that I am on solid ground here - I make the ab=
ove
> rules in a CSS where all is just black & white & Arial, and submit it on
> this channel? Have u understood what I am trying to do, and would it be of
> any use?

See above, maybe you should refine the structure first. But in general, that
is the way you should proceed.

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

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

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

On Fri, Mar 30, 2001 at 12:29:46AM +0200, Alain Fontaine wrote:

> http://www.phpsecurepages.f2s.com/

If using phplib cou can have groups, rights and check for user permissions
on page basis or just for parts of pages.

It lacks group support out of the box, but I have seen additions to
implement that.

In short: I would like to use phplib or something based on that (or our own
implementation, remember the Koehntopp article I posted?), just because it
is good to know what you are using _rather well_ when it has something to do
with security (and I looked under the hood of phplib long enough :-) ).

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

[Phpwebsite-developers] Roadmap

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

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] Custom boxes for different pages

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

A feature I'd like to see is the ability to display different left and right
boxes on different pages.

I customized phpNuke to do this. To see it, go to www.ActionAgenda.com.
Select various category pages (selected from the menu on the upper right)
and notice that each category page has different news feeds on it. (The news
feeds are on the lower left of each page.)

Geoff Staples,
3883 Turtle Creek Blvd., Suite 1812
Dallas, Texas   75219-4432
214.599.0260
Hostricity Web Hosting <http://www.hostricity.com/>

[Phpwebsite-developers] about mysql (slightly OT)

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

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] phpSlash

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

Check out phpSlash at http://sourceforge.net/projects/phpslash/ or
http://phpslash.sourceforge.net/

They're good folks over their. They are trying to something similar to
phpWebsite and they are serious about doing it properly.

They've been through a lot of the discussions about PEAR / phpLib, theming,
and many other issues we are now discussing.

There's some good information in their discussion list archives.

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

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

[W.D.Sumilang <wa...@on...>]

My sentiments exactly... i'm game... send the info.

__________________________________________________
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com

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

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

Todd,
   i'll send it out tomorrow as im rushed for the rest of the day.

> Anyway, http://www.openacs.org has the TCL, Aolserver, Postgresql version,
>  The OpenACS group worked hard moving the Oracle
>  stored procedures from ACS to the TCL side of OpenACS.

thats what i had to do to try and make things more DB independent.


> I won't digress about how I think Python is
> the best language around)
that my next "P" language to tackle, after Perl (not pretty, but good for
"heavy lifting") and PHP. everything ive read suggests that its a thing of
beauty.

> Since my goal for PHP is to have multiple sites within the same
installation
> (and same database tables), then an access control list becomes
increasingly
> more important.
Multi-sites in the same DB shouldnt be a problem at all. Permissions are
based on object Ids (primary keys), so it doesnt matter which site they
belong to. The permission system is a general framework you use to
grant/revoke/check access to any object in the system. it can be tailored to
fit many scenarios.  (its a little clearer if you look at the object model
and the source code)

>ACS's strength is definitely its data model, which will benefit anyone who
> studies it.

Absolutely !

Re: [Phpwebsite-developers] Database Design Suggestions

[Brian W. B. <br...@ap...>]

>> As far as database abstraction goes, let me cast my vote for PEAR. 
>> Smarty uses PEAR (although not for databases), phplib will be
>> integrated into PEAR, and I believe PEAR will become the standard,
>> whether phpWebSite adopts it or not--it's in the PHP distribution
>> already.  Having reviewed the classes, I believe they will serve us
>> well.

Yes, PEAR is looking good.

-- 
Brian W. Brown
Internet Systems Architect, ESS
Student Development
Room 269, John Thomas Hall
Appalachian State University  
Boone, NC 28608

vox: 828-262-7124
fax: 828-262-2585

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

[Alain F. <al...@va...>]

Hi,

http://www.phpsecurepages.f2s.com/

This looks really good !

Take a look.

Alain

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

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

I too considered using ACS for community building,especially after reading
Phil Greenspun's book available at http://www.arsdigita.com/books/panda/
which I recommend to Everyone!  My dead tree version has some beautiful
photographs.

Anyway, http://www.openacs.org has the TCL, Aolserver, Postgresql version,
which is open source.  The OpenACS group worked hard moving the Oracle
stored procedures from ACS to the TCL side of OpenACS.

Having used Zope for a while (I won't digress about how I think Python is
the best language around), I realized that some of the things I wanted to
accomplish wouldn't scale well in Zope.  However, one of Zope's strong suits
is it's access control lists (ACLs).  Since Zope works like a tree, an ACL
object on a branch controls access for all object nodes below it.

Since my goal for PHP is to have multiple sites within the same installation
(and same database tables), then an access control list becomes increasingly
more important.  I would like to see your work on this port Clayton to give
me (us) some ideas about how we could implement this functionality in phpWS.
ACS's strength is definitely its data model, which will benefit anyone who
studies it.

--Todd

[Phpwebsite-developers] Integrated User/Group & Permissions

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

As a part of my search for a portal engine, i came across ACS, which had
everything i was looking for, except for the fact that its written in TCL,
needs AOLServer, and insists on Oracle (though PGSql and Interbase variants
exist). In any case i began a port of ACS to PHP (more on that later),
learning many things in the process.

ACS has a pretty good SQL based User/Group and permissions model which could
work in the context of phpWS. i have a good start on porting parts of it
over, so if anyone is interested, give me a shout and i can email something
you can look at. Note, however that it is incomplete, and absolutely
positively will _not_ compile, and has a few more features than we need to
deal with at the moment (they have a concept of "group type", which new
groups "inherit" attributes from).

   However, it can definitely be massaged to form a part of the PWS
architecture. In particular, the permissions system would only need minor
work to get working once the user stuff is finished.

i have more ideas i'll share later  ...

Re: [Phpwebsite-developers] Database Design Suggestions

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

I had voted for ADODB before Smarty was found and I think PEAR would be the 
way to go too if we were to use Smarty just for the fact that Smarty uses 
it and like you said it already is in PHP to begin with....



>> 1. All primary keys should be integer (size, indexing speed,
> comparability).
>> This may cause issues for heavily populated tables (forums, etc),
>> though
> we
>> can design around it.
> 
> I agree that there should be an integer primary key for every table.  I
> don't understand your concern with large forums.  The indexing is still
> more efficient with integers.
> 
> As far as database abstraction goes, let me cast my vote for PEAR. 
> Smarty uses PEAR (although not for databases), phplib will be
> integrated into PEAR, and I believe PEAR will become the standard,
> whether phpWebSite adopts it or not--it's in the PHP distribution
> already.  Having reviewed the classes, I believe they will serve us
> well.
> 
> --Todd
> 
> 
> 
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

SV: [Phpwebsite-developers] Template system (Smarty)

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

Karsten (and onyone with interest);

> -----Oprindelig meddelelse-----
> Fra: Karsten Dambekalns [mailto:k.d...@fi...]
> Sendt: 29. marts 2001 20:39
> Til: php...@li...
> Emne: Re: [Phpwebsite-developers] Template system (Smarty)
> 
> 
> On Thu, Mar 29, 2001 at 08:11:52PM +0200, Frits Jensen wrote:
> 
> > I totally disagree, as having your themes this way would 
> make using good
> > third-party tools for editing CSS very complex, and the 
> whole structure more
> > complex from a designers point of view. One directory 
> containing one theme
> > makes sense for the user, increases ease of use, and is 
> open for the future
> > expansions. Pardon my tone =)
> 
> You are making a point here. Third-Party CSS editors would 
> get disturbed by
> placeholders in the CSS tenplate file. Hmmm....

I admit I do not code, but it just seems straight ahead for me to have
"real" CSS in its own file, and then whatever extra files a theme
unfortunetely have to have along in the same directory - messy, perhaps, but
sloppy, I should say no, as this is just playing by the given realities of
different systems interacting, and being prepered for whatever comes at the
same time.

> 
> > CSS'ing more versatile. Also there should be a referrer to 
> print and aural
> > versus monitor in the coding - I would like my pages to 
> print nicely. A
> > theme should consist of at least both one for monitor, and 
> one for print, to
> > be a complete theme.
> 
> That got my attention: Is there _any_ browser available, that _really_
> supports _any_ of the possibilities to format for printing? 
> Last time I
> looked at that issue, I was all too disappointed!
> 
> Or are you referring to this with a look in the future?

I suppose IE 5.5/Win is 100% print/monitor, but in general, I should think
one exciting thing of this project is 'doing it right' - so if for nothing
else, just for the sake - its only one line pr CSS-call, and does the
printing-CSS not exist, well no harm done, it'll get ignored, or
alternative, one could place an empty CSS for printing if one could not
bother.

> 
> But of course you are right. Maybe we should just do it 
> anyway, and see the
> browser makers implement it, just to satisfy the gazillion phpWebSite
> users... :-)

Jep =)

> 
> > There should be a certain logic to the tagging, so that we 
> do not end up
> > using 5 trillion individually named tags, one for each 
> plugin, option and
> > 'little thing i just coded'. Limit is the keyword. Without 
> having thought it
> > all the way through, I would say that it would be plenty 
> with 5 areas of
> > tagging. It could be something like:
> > 
> > leftbox.h1 =...
> > rightbox.h1 =...
> > article.h1 =...
> > special_big.h1 =...
> > special_small.h1 =...
> > top_bar.h1 =...
> > [...]
> > and so on...
> 
> Ok, I got that... Though you probably mean leftbox.h1 {...}
> 
> > leftbox_menu_padding.left =...
> > leftbox_menu_padding.right =...
> > leftbox_menu_padding.bottom =...
> > leftbox_menu_padding.top =...
> > leftbox_menu_padding.left =...
> > 
> > rightbox_menu_padding.left =...
> > rightbox_menu_padding.right =...
> > 
> > and so on...
> 
> What are those for? Or do you mean leftbox_menu { padding-left: ...
> padding-right:... } ?!?

lol - I was dumb enough to try and describe the mathematics, using imaginary
syntax.. Sorry, I can see it makes no sense. Perhaps this will: (no syntax
now, just describing how many 'tags' needed)

We have 5 areas:

leftbox
rightbox
main
special_big
special_small

Theese will each need all the usual stuff as 'h1 font size' for each 5, 'h2
font size' for each 5 and so on.

Second, I was trying to describe how some need padding, border, etc for all
four sides (Not just h1, but left padding, right padding, etc), marked
individually, and so on.

The main thing in my nonsense was that all there is to work with is one of
those 5 'subsets'; When coding, you could chose if your object belonged to
leftbox, rightbox, main, special_big, or special_small, and within this you
then could choose say 'h1'. I cannot remember the syntax but I will create a
complete set if u agree and understand..

When creating the CSS, u could then have individual looks for each of the 5
subsets. Typically all would be more or less the same, but as I tried to
explain; the system would be closed standard hereafter, but any needed
versatility would not be lost.

One extra subset for the top-bar would be needed.

> 
> > If I make any sense to anyone, I would take on the task of 
> creating a
> > _complete_ set of such names, so that that part of the 
> project was finito
> > and done with. 
> 
> Go ahead! Write something up and submit it to the list for 
> discussion. Any
> help is good help :-)

Thanks for the backup - I'll get to it - Only I am kinda new to all this
hacking, so please confirm that I am on solid ground here - I make the above
rules in a CSS where all is just black & white & Arial, and submit it on
this channel? Have u understood what I am trying to do, and would it be of
any use?

Thanks,
Frits

> 
> Regards,
> Karsten
> -- 
> fishfarm - Karsten Dambekalns
> Echternstr. 73 - 38100 Braunschweig
> 
> Tel. +49 531 1232902  mailto:k.d...@fi...
> Fax. +49 531 1232906  http://www.fishfarm.de/
> -----------------------------------------------------
> 

Re: [Phpwebsite-developers] Database Design Suggestions

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

> 1. All primary keys should be integer (size, indexing speed,
comparability).
> This may cause issues for heavily populated tables (forums, etc), though
we
> can design around it.

I agree that there should be an integer primary key for every table.  I
don't understand your concern with large forums.  The indexing is still more
efficient with integers.

As far as database abstraction goes, let me cast my vote for PEAR.  Smarty
uses PEAR (although not for databases), phplib will be integrated into PEAR,
and I believe PEAR will become the standard, whether phpWebSite adopts it or
not--it's in the PHP distribution already.  Having reviewed the classes, I
believe they will serve us well.

--Todd