phpwebsite-developers — For our development team.

Re: [Phpwebsite-developers] Developer docs update

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

I normally only indent (2) spaces, but have forced myself to follow the PEAR
standard, which is (4) spaces.  I think we should use the PEAR coding
standards.  http://pear.php.net will get you to the standards.

--Todd

[Phpwebsite-developers] Database Design Suggestions

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

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.

2. (Please...) Sequences instead of autoincs. Not only are they more
portable, but they allow you to do things like double-click protection, and
are more conservative of key-space.

more to follow ....

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

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

U may :)

> -----Oprindelig meddelelse-----
> Fra: Mike Windsor [mailto:wi...@ce...]
> Sendt: 29. marts 2001 20:54
> Til: php...@li...
> Emne: Re: [Phpwebsite-developers] Template system (Smarty)
> 
> 
> If I may,
> 
> > In that sense, I definitely feel that a "theme editor" would be very
> > welcome. Don't forget that there will be many phpWebSite 
> users that don't
> > even know HTML. Actually, the guy I am currently setting up 
> phpWebSite for
> > is one of them.
> >
> > Anyway, even if we don't include an editor, going the 
> "templatized themes
> > definition" direction will probably prove to be much less 
> of a hassle to
> > manage. Which of the following is better:
> 
> Could a theme editor be made a "plugin" as well?
> 
> winzor
> 

I was trying to propose this earlier. Only - It should come with a custom
theme, made specially to be compatible with this plugin, to avoid
complications (to keep it short)

Frits

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

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

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

If I may,

> In that sense, I definitely feel that a "theme editor" would be very
> welcome. Don't forget that there will be many phpWebSite users that don't
> even know HTML. Actually, the guy I am currently setting up phpWebSite for
> is one of them.
>
> Anyway, even if we don't include an editor, going the "templatized themes
> definition" direction will probably prove to be much less of a hassle to
> manage. Which of the following is better:

Could a theme editor be made a "plugin" as well?

winzor

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

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

Sorry if I seemed offensive in my previous posting, and sorry to =
everyone,
if this gets to narrow for a mailinglist :)

> -----Oprindelig meddelelse-----
> Fra: Alain Fontaine [mailto:al...@va...]
> Sendt: 29. marts 2001 20:39
> Til: php...@li...
> Emne: RE: [Phpwebsite-developers] Template system (Smarty)
>=20
>=20
> Hi there,
>=20
> > -----Message d'origine-----
> > De : php...@li...
> >=20
> [mailto:php...@li...]De=20
> la part de
> > Frits Jensen
> > Envoy=E9 : jeudi 29 mars 2001 20:12
> > =C0 : 'php...@li...'
> > Objet : SV: [Phpwebsite-developers] Template system (Smarty)
> >
> [cut]
>=20
> [quote]
> Totally agree! "This tarball works. U want more? Code!"
> [/quote]
>=20
> Okay, if we follow this direction, and that is what the main=20
> part of your
> mail expresses, we will just hand out a text editor, the PHP=20
> source, the
> mySQL source and a Linux distribution to the guy and say: This is
> phpWebSite. Want more? Code!.

Sorry - u couldnt get me more wrong. My concern was to make a finished
product that came with upgrades, opposed to beta on beta with potential =
for
expansion. This would mean somewhat limited versions, but versions =
where the
user did not have to code. _Only_ if this wasn't enough for the user, =
my
staement was; Code! I want a complete and working system that can be =
build
on, not an ongoing beta - that's what I was trying to express.

> Or even better, send them an E-mail with the URL's to php and=20
> mysql, and
> tell them that this is all they need to have their portal=20
> site :). I agree
> that this is ridiculus, but where I want get to is this:
>=20
> It's all about finding the "right middle-way".
>=20
> As far as I know, our target audience are people who don't really =
feel
> comfortable fiddling around in style sheets, HTML, let alone=20
> PHP code. I
> guess, unless I am really mistaken, that we want phpWebSite=20
> to be a Portal
> Application in the "Windows" sense, e.g. "point&click, setup.exe,
> click-click" and there you have your own customized portal site.
>=20
> In that sense, I definitely feel that a "theme editor" would be very
> welcome. Don't forget that there will be many phpWebSite=20
> users that don't
> even know HTML. Actually, the guy I am currently setting up=20
> phpWebSite for
> is one of them.
>=20
> Anyway, even if we don't include an editor, going the=20
> "templatized themes
> definition" direction will probably prove to be much less of=20
> a hassle to
> manage. Which of the following is better:
>=20
> * 10 themes equals 10 directories, each having 15 files
> or:
> * 10 themes equals ONE directory, having 15 slightly more=20
> complex files
>=20

Karsten just expressed MHO :)

> The first possibility means 150 entities to manage, the=20
> second means 15
> entities. It's clear that both from a developer's point of=20
> view, AND from
> the user's point of view, the second possibility is the way=20
> to go. In any
> way, we will end up with an "easier to manage" factor equalling
> approximately the number of themes. The more themes we have,=20
> the more the
> second solution will become easier to manage/update.
>=20
> I can somehow understand the points you make about including the =
theme
> editor (although I don't agree with all of them). However, I=20
> cannot agree
> with you on the fact that it would be better to have the "10=20
> themes =3D=3D 10
> directories" structure. That is not dynamic, not manageable, and not
> challenging. The last point is something we shouldn't forget:=20
> Most of us are
> doing this because it is fun, and because we want to learn.=20
> If it weren't
> for that, we could simply start creating static portal sites=20
> and keep our
> lives busy updating them using Frontpage 2000.
>=20
> No offense taken, and these are just my personal views on the=20
> matter :)
>=20
> Alain

:)

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

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

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

On Thu, Mar 29, 2001 at 08:38:48PM +0200, Alain Fontaine wrote:

> * 10 themes equals 10 directories, each having 15 files
> or:
> * 10 themes equals ONE directory, having 15 slightly more complex files

I would say: The FIRST!

> The first possibility means 150 entities to manage, the second means 15
> entities. It's clear that both from a developer's point of view, AND from
> the user's point of view, the second possibility is the way to go. In any
> way, we will end up with an "easier to manage" factor equalling
> approximately the number of themes. The more themes we have, the more the
> second solution will become easier to manage/update.

Well, basically a theme is a theme because it defines it's own layout,
colours, whatever. What if I created a theme with a new template for left
blocks. This template needed some images. And the corresponding stylesheet
doesn't need borders around the blocks. If I were to put my files into THE
theme directory, there sure would something get messed up.

And what about theme_xyz.tar.gz? How would you know that you can safely
unpack this? You wouldn't...

So I would say: Dynamic stylesheets are a must, even it it is only for
setting the font-size depending on the user agent (one could probably use
some regex to put a  placeholder in a stylesheet produced by some third
party CSS editor automatically). One directory per theme is a must. To keep
things simple ("Hey, these files belong to the xyz theme. Cool") and
manageable. You wouldn't want to change the colors for all themes anyway,
eh? How would they be different afterwards?

Just MHO,
Karsten
--=20
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] Developer docs update

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

On Tue, Mar 27, 2001 at 08:03:20PM +0200, Alain Fontaine wrote:

> * Use underscores in function names
> Why ? If ever phpWebSite will be developed in an OO approach, why not use
> the "java style" of function and variable naming ? setThisThat(),
> getThisThat(), displayStuff() etc look much better to me than
> set_this_that() and so on :)

Well, I think we will stick with the underscores. See some other emails for
some reasons. Basically: PHP does it this way (mysql_query, etc.), so we do
it as well. This just isn't Java :-) And most of the code is written that
way already.

> *Try to avoid unnecessary file unclusions (see config.php and mainfile.ph=
p)
> This is of course always true, as an unnecessary file inclusion is always=
 to
> be avoided per definition :). However, using include_once() and
> require_once() could help avoiding problems a bit.

True, *_once() should help. But we should nevertheless try to remove as many
of these calls as possible, I think.

> For the rest, I think the documentation and guidelines you put up will be
> invaluable to the development team - good work.

Thanks! I hope some more people looked at the suggested coding style and all
agree to it. There is one more thing: I wrote "using tabwidth 8" which is
(IMHO) the emacs default setting and preferred by K&R and the linux core
hackers and many more. Do all agree on that? And what about the curly braces
thing? Do we really put them on an otherwise empty line? I wrote that
because I had the impression it was done that way in the code until now. I
prefer putting the opening one last on the line, and the closing one first,
as follows:

foo() {
  bla
}

What do you think about that? (See /usr/src/linux/Documentation/CodingStyle
if available on your computer for some even more detailed piece about coding
style :-)

Did anybody ever try to use GNU indent on PHP source code? Does that work?

Regards,
Karsten
--=20
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] Template system (Smarty)

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

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 m=
ore
> 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 futu=
re
> expansions. Pardon my tone =3D)

You are making a point here. Third-Party CSS editors would get disturbed by
placeholders in the CSS tenplate file. Hmmm....

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

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... :-)

> 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:
>=20
> leftbox.h1 =3D...
> rightbox.h1 =3D...
> article.h1 =3D...
> special_big.h1 =3D...
> special_small.h1 =3D...
> top_bar.h1 =3D...
> [...]
> and so on...

Ok, I got that... Though you probably mean leftbox.h1 {...}

> leftbox_menu_padding.left =3D...
> leftbox_menu_padding.right =3D...
> leftbox_menu_padding.bottom =3D...
> leftbox_menu_padding.top =3D...
> leftbox_menu_padding.left =3D...
>=20
> rightbox_menu_padding.left =3D...
> rightbox_menu_padding.right =3D...
>=20
> and so on...

What are those for? Or do you mean leftbox_menu { padding-left: ...
padding-right:... } ?!?

> 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.=20

Go ahead! Write something up and submit it to the list for discussion. Any
help is good help :-)

Regards,
Karsten
--=20
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] Template system (Smarty)

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

Hi there,

> -----Message d'origine-----
> De : php...@li...
> [mailto:php...@li...]De la part de
> Frits Jensen
> Envoyé : jeudi 29 mars 2001 20:12
> À : 'php...@li...'
> Objet : SV: [Phpwebsite-developers] Template system (Smarty)
>
[cut]

[quote]
Totally agree! "This tarball works. U want more? Code!"
[/quote]

Okay, if we follow this direction, and that is what the main part of your
mail expresses, we will just hand out a text editor, the PHP source, the
mySQL source and a Linux distribution to the guy and say: This is
phpWebSite. Want more? Code!.
Or even better, send them an E-mail with the URL's to php and mysql, and
tell them that this is all they need to have their portal site :). I agree
that this is ridiculus, but where I want get to is this:

It's all about finding the "right middle-way".

As far as I know, our target audience are people who don't really feel
comfortable fiddling around in style sheets, HTML, let alone PHP code. I
guess, unless I am really mistaken, that we want phpWebSite to be a Portal
Application in the "Windows" sense, e.g. "point&click, setup.exe,
click-click" and there you have your own customized portal site.

In that sense, I definitely feel that a "theme editor" would be very
welcome. Don't forget that there will be many phpWebSite users that don't
even know HTML. Actually, the guy I am currently setting up phpWebSite for
is one of them.

Anyway, even if we don't include an editor, going the "templatized themes
definition" direction will probably prove to be much less of a hassle to
manage. Which of the following is better:

* 10 themes equals 10 directories, each having 15 files
or:
* 10 themes equals ONE directory, having 15 slightly more complex files

The first possibility means 150 entities to manage, the second means 15
entities. It's clear that both from a developer's point of view, AND from
the user's point of view, the second possibility is the way to go. In any
way, we will end up with an "easier to manage" factor equalling
approximately the number of themes. The more themes we have, the more the
second solution will become easier to manage/update.

I can somehow understand the points you make about including the theme
editor (although I don't agree with all of them). However, I cannot agree
with you on the fact that it would be better to have the "10 themes == 10
directories" structure. That is not dynamic, not manageable, and not
challenging. The last point is something we shouldn't forget: Most of us are
doing this because it is fun, and because we want to learn. If it weren't
for that, we could simply start creating static portal sites and keep our
lives busy updating them using Frontpage 2000.

No offense taken, and these are just my personal views on the matter :)

Alain

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

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

> -----Oprindelig meddelelse-----
> Fra: Karsten Dambekalns [mailto:k.d...@fi...]
> Sendt: 29. marts 2001 18:27
> Til: php...@li...
> Emne: Re: [Phpwebsite-developers] Template system (Smarty)
> 
> 
> On Thu, Mar 29, 2001 at 05:04:43PM +0200, Alain Fontaine wrote:
> 
> > Using a browser-based interface to change the styles is 
> indeed a cool idea.
> > Oh wait, wasn't it me who initially suggested that ?  hehe 
> :)). Seriously,
> > it wouldn't be too hard to integrate it. A little 
> brainstorming if you
> > permit:
> 
> Sure :-) That's what we are all doing all the time...

Brainstorming cool, but browser-based interface to change the styles don't
appear as being smart in reality; This project never will be static, and
therefore version number of themes, php, editor and level of edit will
always be an issue. What good is one, if not compatible with another? You
agree that not all will be possible to edit through this editor, but the
options with CSS are virtually endless, so this will be an ongoing issue.
PhpWebsite should not be a CSS editor, nor include one (or an attempt). If
anyone wants to write CSS, they should use one of the many fine editors
around. This, for the only reason that it is way better to have a complete
and working PhpWebsite than an incomplete try on a somewhat complete
package; If anyone wants to change the code in the tarball, PhpWebsite
should not also come with a custom built php-editor, if you know what I mean
;) A project that is supposed to give defined workspace to the end user can
only have a certain level of fleksability. Does the user want more, the user
must code, only this way the project can work - by setting limits of
capability. Dont forget that you are coding for the people, so that the
people do not have to code. Having said this, it would only be great if
someone coded a plugin to be *working with a custom build theme*, creating a
DIYS theme package this way, but this should be an option like the weather
plugin, functioning and coded independently within the given frames of a
plugin..

> 
> > 1. Ideally, all styles would need to be stored in one 
> single .css file. That
> > makes management and automation easier. Let's call it 
> theme.css. The real
> > filename would actually be theme.css.php because the styles 
> would be defined
> > dynamically through PHP and database calls.

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

> 
> I would like to have it as a template: Just write a "normal" 
> stylesheet, and
> afterwards replace all values which should be adjustable through the
> webinterface by placeholders.
> 
> > 2. Every style (ID, tag overload, or class) that is used in 
> phpWebSite would
> > need to be defined in that file.
> 
> Yes. We should try to define the style to be usd before 
> writing any new
> template or stylesheet.

What is tagged and what is classes and ID's, and where these are used,
should be stated clearly, so that anyone not satisfied with the available
styles could have easy access to make his/her own in an editor. Btw; If I
where to decide, way more of the coding should have classes attached, making
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.

> 
> > 3. The admin interface should have a "preview style" 
> feature so that one can
> > check the result immediately.
> 
> Would be good.

Using a third party CSS editor, this option already exists - don't invent
the wheel again :)

> 
> > 4. One should be able to define more than one theme. This 
> means that we'd
> > need a "themes" table, and a "themesdetail" table that 
> defines the values
> > for the individual styles, per theme.
> 
> Eh? One will be able to have as many themes as he/she wants, 
> right? Ah, I
> should think a minute longer, before starting to write... If 
> we have dynamic
> CSS, we nedd to have the values in the database, and in that 
> database we
> would need an entry for each value/theme pair. Did I get you right?
> 
> Hmm, let's see. We could define some standard themes (with 
> templates and
> stylesheet template), for which such entries in the database 
> would come
> shrink-wrapped. Now there would be two possibilities for future theme
> contributors: Create a customizable theme, in that case they 
> would have to
> follow some basic rules, and would have to provide a SQL snippet to
> introduce their template to the database (like plugins do). 
> Or they could
> decide to write a fixed theme, this would not be customizable 
> through the
> webinterface, but would'nt need the database either.
> 
> We probably need some more thinking on that subject.

The amount of themes should be read by the number of directories in the
'Themes' directory. The only dynamic thing in selecting a theme would be
selecting to where the themes-variable should point (To which directory).
This way themes can expand endless - I mean, one could include soundeffects
if for an obscure reason this was a wish in the future :) The structure
would be ready, you see. In the code _Everything_ possible needs to be
tagged (have a class / ID)- No exeptions, then it is up to the theme
creators to use all the possibilities or not, in a given theme. 

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

leftbox.h2 =...
rightbox.h2 =...
article.h2 =...
special_big.h2 =...
special_small.h2 =...
top_bar.h2 =...

and so on...

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

This way coders knew what they could (should) use when tagging, and there
would be plenty to play with for the designers, though ensuring a
homonognius (English is my second language, ok:) )look and ease of design.
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. 

Then, when coding and making themes from now on and forever, you knew what
you had to work with...

> 
> > 5. It would be nice if the advanced user would not be 
> limited to using the
> > admin interface. The advanced user should be able to 
> manually apply his
> > hand-crafted .css file.
> 
> This would be possible through the stylesheet template 
> approach mentioned
> above: Just edit the CSS template, and you're set.
> 
> > 6. How do we go about defining a style's values? The 
> problem is that you can
> > [...]
> 
> We should limit the customizable things to some set of 
> options we define.
> Full Stop. If needed, the user/admin can edit the stylesheet template
> directly.

This is where I go for the plugin-idea mentioned above..

> > 7. If we are going to make it as dynamic: how about 
> performance? We'd need
> > to investigate caching/compiling options.
> 
> If we take the stylesheet template approach I layed out 
> above, and we decide
> for using Smarty the cacheing/compiling would be done through 
> those. Nothing
> to worry about :-)
> 
> > 8. Also, having that degree of "dynamicity" (?) would allow 
> us to make a
> > very customizable phpWebSite in which the site visitor 
> could create his own
> > style sheet definitions !
> 
> The abilty to choose a theme is enough, I would say. No nedd 
> to give every
> user the ability to customize the freely selectable theme 
> even more, right?
> And I would suspect this to introduce (some) performance issues.

Totally agree! "This tarball works. U want more? Code!"

> 
> > 9. For every style definition, the editor should show where 
> a particular
> > style is used, so that the user immediately sees at what 
> places his changes
> > are going to have an effect. It's a PITA to edit a style 
> for one place just
> > to find out that the very same style is used on 5 other 
> pages, and messes
> > everything up on those.
> 
> This would be nice, but we should lay that responsibility 
> into the hands of
> theme authors. A simple static HTML table showing where which 
> style is used,
> should be sufficient.
> 
> > Okay, enough for now. Waiting for comments/suggestions/ideas :)
> 
> Satisfied? :-)
> 
> 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/
> -----------------------------------------------------
> 
> 
Hope I made sense, 
humble greetings earthlings,
Frits

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

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

Hi,

[several parts of your original mail snipped away for better readability]

> > 4. One should be able to define more than one theme. This means
> that we'd
> > need a "themes" table, and a "themesdetail" table that defines
> the values
> > for the individual styles, per theme.
>
> Eh? One will be able to have as many themes as he/she wants, right? Ah, I
> should think a minute longer, before starting to write... If we
> have dynamic
> CSS, we nedd to have the values in the database, and in that database we
> would need an entry for each value/theme pair. Did I get you right?

Yes, that is exactly what I meant. That means that we basically need two
tables?
Well, the .CSS file I have in mind would look like this:

.bigTitle {
font-face: {bigTitleFontFace};
color: {bigTitleColor};
...
}

Typical SQL query to build the CSS file:

select theme_detail.StyleName, theme_detail.StyleValue
from
themes, themes_detail
where
themes.ThemeID = theme_detail.refThemeID
AND
themes.ThemeID = 1

Return: rowset containing two rows whose contents would be, for instance:

StyleName   -- StyleValue
================================
bigTitleFontFace  -- Arial
bigTitleColor  -- black

and so on. These would then be injected into Smarty, using assign().
Actually, as you can use arrays as parameters to assign(), you could easily
assign the complete reurned recordset to Smarty:

$Smarty->Assign($arrStyles), $arrStyles being constructed like this:

$arrStyles = array();
while($row = mysql_fetch_row($rs) )
{
  array_push( $arrStyles[$row[0]] , $row[1] );
}

Right ? :) If I'm not wrong, this will give us an associative array, like
for instance:

$arrStyles['bigTitleFontFace'] == "Arial"
$arrStyles['bigTitleColor'] == "black"

And that's what Smarty likes pretty well to do its job... :)

> We should limit the customizable things to some set of options we define.
> Full Stop. If needed, the user/admin can edit the stylesheet template
> directly.

I agree. That will keep the idea in the "possible to implement" category of
developments :).

> If we take the stylesheet template approach I layed out above,
> and we decide
> for using Smarty the cacheing/compiling would be done through
> those. Nothing
> to worry about :-)

True !

> The abilty to choose a theme is enough, I would say. No nedd to give every
> user the ability to customize the freely selectable theme even
> more, right?
> And I would suspect this to introduce (some) performance issues.

Yes, that will definitely introduce performance issues... except if we would
use dynamic templates. Let me explain: Every user, as soon as he creates his
account, has his "own" templated CSS file that is included whenever he logs
in. So instead of having one Smarty template called "styles.tpl.php", we
would have many, created as soon as the user logs in: styles-<userID>.tpl.
For instance: styles-valain.tpl, styles-godzilla.tpl, and so on. There will
basically not be much overhead. What needs to be done?

1. Create the styles-<userID>.tpl template file when a new user account is
created. This file would simply be a copy of the "stock" styles template, to
have something to start with. Or, we could ask the user to select among
several available pre-made styles.
2. Let Smarty handle the rest. Instead of writing
Smarty->fetch("styles.tpl"), we'd use
Smarty->fetch($userstyle) where $userstyle is, for instance,
styles-valain.tpl, that is, dynamically built:

$userstyle = "styles." . $UserID . ".tpl";

Smarty's handling of compiling and caching would do the rest, basically. Got
the idea ? That's basically "user-customizable templates".. :)

>
> Satisfied? :-)

Of course. You ? :)

Greetings,

Alain

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

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

On Thu, Mar 29, 2001 at 05:04:43PM +0200, Alain Fontaine wrote:

> Using a browser-based interface to change the styles is indeed a cool ide=
a.
> Oh wait, wasn't it me who initially suggested that ?  hehe :)). Seriously,
> it wouldn't be too hard to integrate it. A little brainstorming if you
> permit:

Sure :-) That's what we are all doing all the time...

> 1. Ideally, all styles would need to be stored in one single .css file. T=
hat
> makes management and automation easier. Let's call it theme.css. The real
> filename would actually be theme.css.php because the styles would be defi=
ned
> dynamically through PHP and database calls.

I would like to have it as a template: Just write a "normal" stylesheet, and
afterwards replace all values which should be adjustable through the
webinterface by placeholders.

> 2. Every style (ID, tag overload, or class) that is used in phpWebSite wo=
uld
> need to be defined in that file.

Yes. We should try to define the style to be usd before writing any new
template or stylesheet.

> 3. The admin interface should have a "preview style" feature so that one =
can
> check the result immediately.

Would be good.

> 4. One should be able to define more than one theme. This means that we'd
> need a "themes" table, and a "themesdetail" table that defines the values
> for the individual styles, per theme.

Eh? One will be able to have as many themes as he/she wants, right? Ah, I
should think a minute longer, before starting to write... If we have dynamic
CSS, we nedd to have the values in the database, and in that database we
would need an entry for each value/theme pair. Did I get you right?

Hmm, let's see. We could define some standard themes (with templates and
stylesheet template), for which such entries in the database would come
shrink-wrapped. Now there would be two possibilities for future theme
contributors: Create a customizable theme, in that case they would have to
follow some basic rules, and would have to provide a SQL snippet to
introduce their template to the database (like plugins do). Or they could
decide to write a fixed theme, this would not be customizable through the
webinterface, but would'nt need the database either.

We probably need some more thinking on that subject.

> 5. It would be nice if the advanced user would not be limited to using the
> admin interface. The advanced user should be able to manually apply his
> hand-crafted .css file.

This would be possible through the stylesheet template approach mentioned
above: Just edit the CSS template, and you're set.

> 6. How do we go about defining a style's values? The problem is that you =
can
> [...]

We should limit the customizable things to some set of options we define.
Full Stop. If needed, the user/admin can edit the stylesheet template
directly.

> 7. If we are going to make it as dynamic: how about performance? We'd need
> to investigate caching/compiling options.

If we take the stylesheet template approach I layed out above, and we decide
for using Smarty the cacheing/compiling would be done through those. Nothing
to worry about :-)

> 8. Also, having that degree of "dynamicity" (?) would allow us to make a
> very customizable phpWebSite in which the site visitor could create his o=
wn
> style sheet definitions !

The abilty to choose a theme is enough, I would say. No nedd to give every
user the ability to customize the freely selectable theme even more, right?
And I would suspect this to introduce (some) performance issues.

> 9. For every style definition, the editor should show where a particular
> style is used, so that the user immediately sees at what places his chang=
es
> are going to have an effect. It's a PITA to edit a style for one place ju=
st
> to find out that the very same style is used on 5 other pages, and messes
> everything up on those.

This would be nice, but we should lay that responsibility into the hands of
theme authors. A simple static HTML table showing where which style is used,
should be sufficient.

> Okay, enough for now. Waiting for comments/suggestions/ideas :)

Satisfied? :-)

Regards,
Karsten
--=20
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] Template system (Smarty)

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

Hello,

I wonder why all the talking about "storing templates in the database" comes
from; I surely hope it isn't because I somehow mentioned the idea in one of
my previous posts.. :)

As a matter of fact, it would be pretty stupid to store the whole template
in the database. Why? Because that's not what databases are for. Let me
explain: how many times will phpWebSite need to run "typical database
functions" on the templates themselves, like: finding a text in the
template, creating the "sum of all templates", finding a "template's
detail", and so on ? Never, right.

It's exactly the same story as with images. Although you can store the whole
binary stream of an image into mySQL, there's very little or absolutely no
sense in doing so.

Storing the template's filename is indeed what is needed. Anyway, as Todd
says, you will get far better performance by using the filesystem for this.
And it's not only about performance, it's also easier to manage the
templates when they are simple text files.

Using a browser-based interface to change the styles is indeed a cool idea.
Oh wait, wasn't it me who initially suggested that ?  hehe :)). Seriously,
it wouldn't be too hard to integrate it. A little brainstorming if you
permit:

1. Ideally, all styles would need to be stored in one single .css file. That
makes management and automation easier. Let's call it theme.css. The real
filename would actually be theme.css.php because the styles would be defined
dynamically through PHP and database calls.
2. Every style (ID, tag overload, or class) that is used in phpWebSite would
need to be defined in that file.
3. The admin interface should have a "preview style" feature so that one can
check the result immediately.
4. One should be able to define more than one theme. This means that we'd
need a "themes" table, and a "themesdetail" table that defines the values
for the individual styles, per theme.
5. It would be nice if the advanced user would not be limited to using the
admin interface. The advanced user should be able to manually apply his
hand-crafted .css file.
6. How do we go about defining a style's values? The problem is that you can
have a varying number of style attributes. A ".bigTitle" CSS class can have
a single "font-size" attribute, or it can have a dozen attributes:
font-family, font-size, color, margin-left, and so on. There are a couple of
possibilities. The first one is the easy one. For every style used, -we-
define the attributes that can be edited through the admin interface. For
instance, we define that for the .bigTitle class, only font-color and
font-family can be set using the tool. The second possibility would be to
create a complete CSS editor, allowing the site administrator to dynamically
add, edit and remove style attributes. Then again, either we assume that the
site admin has good CSS knowledge and knows what he is doing, OR we create a
"user assisting" interface that shows the site administrator what attributes
are available for this or that class, and what values this or that attribute
can have. You see, this completely dynamic version would certainly require
a -lot- of work and come pretty close to a full-featured CSS editor, because
we'd somehow need to classify the various styles so that the 'system' knows
what atributes and values are available.
7. If we are going to make it as dynamic: how about performance? We'd need
to investigate caching/compiling options.
8. Also, having that degree of "dynamicity" (?) would allow us to make a
very customizable phpWebSite in which the site visitor could create his own
style sheet definitions !
9. For every style definition, the editor should show where a particular
style is used, so that the user immediately sees at what places his changes
are going to have an effect. It's a PITA to edit a style for one place just
to find out that the very same style is used on 5 other pages, and messes
everything up on those.

Okay, enough for now. Waiting for comments/suggestions/ideas :)

> -----Message d'origine-----
> De : php...@li...
> [mailto:php...@li...]De la part de
> Todd Owen
> Envoyé : jeudi 29 mars 2001 16:31
> À : php...@li...
> Objet : Re: [Phpwebsite-developers] Template system (Smarty)
>
>
> Karsten, that was exactly what I was talking about !  I agree that the
> templates and style sheets (generically called themes) should be stored in
> the filesystem and not in the database for performance issues.  An browser
> based form to edit the style sheets also makes sense and avoid uploading.
>
> --Todd
>
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>
>

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

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

Karsten, that was exactly what I was talking about !  I agree that the
templates and style sheets (generically called themes) should be stored in
the filesystem and not in the database for performance issues.  An browser
based form to edit the style sheets also makes sense and avoid uploading.

--Todd

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

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

On Wed, Mar 28, 2001 at 08:25:31PM -0500, Todd Owen wrote:

> I didn't mean I wanted to have dynamic style sheets, although that would =
be
> an interesting concept.  I just wanted to make sure we used style sheets
> first, then templates (i.e. no font tags in the template).

That is an absolute need, given that we want to be XHTML compliant (there
aren't any font tags anymore, are there?).

To lay out what I imagine for the use of templates:

We would have one template for the general page layout, having placeholders
for:
 - menu
 - left blocks
 - right blocks
 - main content
 - login box (or is this a "normal" block?)
 - little things as title, etc.

Then we would have a template that just defines one standard block. This
would just have:
 - title
 - content

This way one could change the general appearance of pws (phpWebSite that is,
not Personal Web Server :-) by just changing two files, and probably the
stylesheet. Or you stick with the general layout and just change the block
template to make them have rounded edges or diferent borders.

We could further make it possible for every block/plugon to have it's own
template. This couild be done through an additional field in the database:
if empty, use the standard block template, if not use the one in the
database.

Speaking of database: I think we should not store the templates in the
database. First because of speed issues, second because it is sufficient to
store the template name in the database, and third because storing the
templates as files makes them easier to edit.

The idea with having dynamic stylesheets is in fact very good. I implemented
that once in a somewhat experimental project, and it makes it possible to
avoid that fu***ng font-size problem regarding Win/Mac/Linux. On top of
that, we could give the admin the possibility to change the colours and
fonts of pws through a simple interface.

This way we have the best from both approaches: You can stick with the basic
layout and change things through a web interface. Or you can lay your hands
on the templates, to change things more drastically.

Just my 2 cents.

BTW: What about having a template for config.php? Add some form elements to
the setup and/or admin pages, write back config.php and voila: Browser based
setup. No more editing of config.php. And wouldn't it be possible to have
pws actually create the database? It would have to ask for "root" access to
the database once, it could immediately unset the corresponding vars after
creating the db. Or would you consider this too much a security risk? We
could make it optional, for those who care.

Regards,
Karsten

PS: Sorry for my always-too-long posts :-)
--=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)

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

Todd,

From what I can tell, Smarty pretty much does everything we discussed and 
even more for that matter with having a compiler.  I haven't looked at 
Smarty really anymore than an hour or two but have been reading the 
messages being written about it on the list.  It sounds like it would be 
something we could use thats for sure!

Jason Campbell
Xplozive Media Technologies


>> function("test") and function($bla) are exactly the same to php as
>> long as $bla=="test", so there's no difference at all between
>> "hard-coding" the template name or getting it out of a database...
> 
> I agree.  But does the variable above cause Smarty to recompile the
> template?  If not, then great!  That was my only question.  Sorry to
> confuse cacheing with compiling--it did mean compiling.
> 
>> How about using variable (templated??) style sheets ?
>> H1 {font-family: <?echo $fonts?>}
> 
> I didn't mean I wanted to have dynamic style sheets, although that
> would be an interesting concept.  I just wanted to make sure we used
> style sheets first, then templates (i.e. no font tags in the template).
> 
>> I don't really follow you here... what exactly do you mean when you
>> say
> that
>> Smarty was designed to work on a file by file basis ?
> 
> I was trying to say that I envision a system that has a fundamental
> theme meaning nav bar on left, title up top, poll on right and articles
> in the center let's say.  This theme would carry through the site,
> without having a separate template file for each site category.  Does
> that make any sense? Jason can you help me out here, it's what we
> talked about by phone on Saturday?
> 
> --Todd
> 
> 
> 
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

[Phpwebsite-developers] Photos/Images in stories

[Raymond H. I. <ra...@hi...>]

Greetings,

I'm new to the list -- my apologies if this was discussed already... 

Has there been any discussion about adding image/photo support to the 
posting of stories in phpWebsite?  A friend of mine likes to review golf 
equipment and wants to include one or more photos in each story.  

Thanks,
Ray

[Phpwebsite-developers] php in css files (was Template system)

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

i have adopted the 'smart' stylesheet from geeklog. i include it like a
normal stylesheet. the php code checks for the browser/os and determines the
fontsizes.

function find($component)

 global $HTTP_USER_AGENT;
 $result = stristr($HTTP_USER_AGENT,$component);
 return $result;
}

if (find('Win') && (find('MSIE 4') || find('MSIE 5'))) {
        $font_medium='medium';
        $font_small='small';
        $font_smaller='x-small';
        $font_smallest='xx-small';
} else if (find('Win')) {
        $font_medium='large';
        $font_small='medium';
        $font_smaller='small';
        $font_smallest='x-small';
} else if (find('Mac')){
        $font_medium='x-large';
        $font_small='large';
        $font_smaller='medium';
        $font_smallest='small';
} else {
        $font_medium='large';
        $font_small='medium';
        $font_smaller='small';
        $font_smallest='x-small';
}
<style TYPE="text/css">
<!--
BODY,TD  { color: black; font-size: <?php echo $font_smaller; ?>;
font-family: verdana, arial, sans-serif }
H1   { color: black; font-size: <?php echo $font_medium; ?>; font-weight:
bold; font-family: verdana, arial, sans-serif }
H2   { color: black; font-size: <?php echo $font_small; ?>; font-weight:
bold; font-family: verdana, arial, sans-serif }

etc...

-->
</style>

this could be easily expanded to cover more vars

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

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

> function("test") and function($bla) are exactly the same to php as long as
> $bla=="test", so there's no difference at all between "hard-coding" the
> template name or getting it out of a database...

I agree.  But does the variable above cause Smarty to recompile the
template?  If not, then great!  That was my only question.  Sorry to confuse
cacheing with compiling--it did mean compiling.

> How about using variable (templated??) style sheets ?
> H1 {font-family: <?echo $fonts?>}

I didn't mean I wanted to have dynamic style sheets, although that would be
an interesting concept.  I just wanted to make sure we used style sheets
first, then templates (i.e. no font tags in the template).

> I don't really follow you here... what exactly do you mean when you say
that
> Smarty was designed to work on a file by file basis ?

I was trying to say that I envision a system that has a fundamental theme
meaning nav bar on left, title up top, poll on right and articles in the
center let's say.  This theme would carry through the site, without having a
separate template file for each site category.  Does that make any sense?
Jason can you help me out here, it's what we talked about by phone on
Saturday?

--Todd

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

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

Hello,

Although the developers would probably be able to better answer your
questions, I'll give it a try. Find my answers in the quote below.

> The above would stay cached for 60 minutes, but would the
> following have to
> be reparsed each run?
>
> index.tpl (unchanged)
>
> --index.php--
> ...
> $smarty->assign("Name",$name_from_query);
> $smarty->display("index.tpl");
> ...
>
> How about
> ...
> $smarty->display($template_name_from_database);
> // instead of hardcoded template string like index.tpl
> ...
>
> If the above would be cached, then Smarty should be considered
> VERY closely.
> Alain, can you find out about this?

Actually, the template engine involves two steps here... the "smarty
language" templates, e.g. HTML markup with special Smarty tags, are COMPILED
into native PHP code first, and then included into the calling file. This
means that you actually have two "buffers" you can control: the compilation,
and the real caching of the pure HTML file with data in it.

Compilation can be handled dynamically, e.g. Smarty can check if a file
needs re-compilation because of changes or not, but you can also de-activate
compilation completely once you have your final template versions. This then
gives a drastic performance boost as the parsing doesn't take place anymore.
In addition to this, you have the "real" concept of caching, e.g. storing
static versions of the files as pure HTML.

Now to your question if your database example would be cached ? Yes, I
suppose so, as Smarty's caching mechanism somehow relies on an MD5 checksum
it creates from the template name. However, be sure not to mistake caching
of output and compiling of templates.

On a side note, what's the difference for PHP if you "hard-code" a function
argument, or read it from a database ? :)
function("test") and function($bla) are exactly the same to php as long as
$bla=="test", so there's no difference at all between "hard-coding" the
template name or getting it out of a database... or am I overlooking
something here ? ;)

>
> 2.  How should phpWebSite use templates?  We definately need to rely on
> style sheets first !!  Assuming we are, how should we look at templates?

How about using variable (templated??) style sheets ? :) I've done that
already. Something like:
H1 {font-family: <?echo $fonts?>}
is absolutely possible. I wonder if this could be done using smarty... yes,
I suppose so. That way the look&feel of the site could be completely stored
in the database, too, somehow using a table that associates the various
styles that are used with their values, and an easy admin interface to
change these values.

>
> I'm thinking of a simple template for the entire site, which would adjust
> the placement of blocks (i.e. nav bar, title, polls, articles,
> etc.).  These
> blocks would have their own HTML in the phpWebSite plug-in itself OR a
> separate plug-in template file.  The problem with this is whether or not
> caching would be done by Smarty.  I don't think it could cache this
> arrangement, but maybe it doesn't need to.

Don't forget in this regard that you can have multiple Smarty instances
doing the parsing/compiling etc, and that you can set the "cache" and
"recompile" options on a per-instance basis .... this basically means that
you can somehow switch on/off compiling and caching quite easily.

>
> The fundamental question is what are we looking to accomplish with
> templates?  I don't think phpWebSite is designed to be templated the way
> Smarty was conceived--that is on a file by file basis, but I
> still think it
> can be used to accomplish what we want, maybe even in its present
> form.  But
> what do we want--that is the question?
>

I don't really follow you here... what exactly do you mean when you say that
Smarty was designed to work on a file by file basis ?


Thanks, and talk to you soon !

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

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

I read ALL of the Smarty docs today and am VERY impressed with their
templating system; in fact, it's the best I've ever seen.  I only have two
concerns:

1.  I was not clear whether the templates would have to be re-parsed for
dynamic data.

--------- index.php --------
<?php
require("Smarty.class.php");
$smarty = new Smarty;
$smarty->assign("Name","Ned");
$smarty->display("index.tpl");
?>

--------- templates/index.tpl --------
<HTML> <TITLE>Hello</TITLE> <BODY>
    Hello, {$Name}!
</BODY> </HTML>

The above would stay cached for 60 minutes, but would the following have to
be reparsed each run?

index.tpl (unchanged)

--index.php--
...
$smarty->assign("Name",$name_from_query);
$smarty->display("index.tpl");
...

How about
...
$smarty->display($template_name_from_database);
// instead of hardcoded template string like index.tpl
...

If the above would be cached, then Smarty should be considered VERY closely.
Alain, can you find out about this?

2.  How should phpWebSite use templates?  We definately need to rely on
style sheets first !!  Assuming we are, how should we look at templates?

I'm thinking of a simple template for the entire site, which would adjust
the placement of blocks (i.e. nav bar, title, polls, articles, etc.).  These
blocks would have their own HTML in the phpWebSite plug-in itself OR a
separate plug-in template file.  The problem with this is whether or not
caching would be done by Smarty.  I don't think it could cache this
arrangement, but maybe it doesn't need to.

The fundamental question is what are we looking to accomplish with
templates?  I don't think phpWebSite is designed to be templated the way
Smarty was conceived--that is on a file by file basis, but I still think it
can be used to accomplish what we want, maybe even in its present form.  But
what do we want--that is the question?

--Todd

Re: [Phpwebsite-developers] News Feeds and News Syndication

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

Shame on yoy for not looking on the phpWebSite homepage  ;-)  Wade Weppler
has made a plugin for headlines and is very nice.  It's under
Downloads/Plugins


Mike


----- Original Message -----
From: "Geoff Staples" <Ge...@Ho...>
To: <php...@li...>
Sent: Wednesday, March 28, 2001 11:09 AM
Subject: [Phpwebsite-developers] News Feeds and News Syndication


> What has happened to the news feeds and news syndication service that were
> part of phpNuke? I notice they are not part of phpWebSite - current
release
> or CVS.
>
> Also, no one seems to be talking about these features.
>
> So, I'll make a statement: I believe these to be critical features of a
> system like phpWebSite.
>
> Any comments?
>
> Geoff
> Dallas,Texas
> www.Hostricity.com
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>
>

[Phpwebsite-developers] News Feeds and News Syndication

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

What has happened to the news feeds and news syndication service that were
part of phpNuke? I notice they are not part of phpWebSite - current release
or CVS.

Also, no one seems to be talking about these features.

So, I'll make a statement: I believe these to be critical features of a
system like phpWebSite.

Any comments?

Geoff
Dallas,Texas
www.Hostricity.com

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

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

On Tue, Mar 27, 2001 at 08:48:00PM +0200, Alain Fontaine wrote:

> Here's the real URL again for your reference :
> http://www.phpinsider.com/php/code/Smarty/
>=20
> The authors are very responsive and supporting to user issues, too; I
> consider this as a strong point.

That is true, it is an important point. After having looked at Smarty's
documentation a little longer than before, I quite like it. I see some
danger in the load of functionality it provides (we should try to keep the
templates as simple as possible, to make life easier for the users), but
this is something we can handle, I guess.

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

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

it made it =)

-----Oprindelig meddelelse-----
Fra: W.D.Sumilang [mailto:wa...@on...]
Sendt: 27. marts 2001 22:46
Til: php...@li...
Emne: [Phpwebsite-developers] Test


If this gets through... great... as my posts apparently haven't made
it to the list.

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


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