Menu
▾
▴
phpwebsite-developers
|
From: Karsten D. <k.d...@tu...> - 2001-03-27 17:11:45
|
Hi everybody! I updated the developer docs at http://www.k-fish.de/krabutzig/phpwebsite/ I removed the function overview files, this is handled better by PHPDoc. Talking of which: I added some explanations how to write PHPDoc comments and wrote something about coding style. Take the part about the coding style with a grain of salt and send your comments about that (important issue) in for some discussion. We should settle on some/a good coding style as sson as possible. The new documentation has also been commited to CVS. I will do a new PHPDoc run today or tomorrow and put that up as well. 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 |
|
From: Alain F. <al...@va...> - 2001-03-27 18:03:32
|
Hi, A couple of comments: * 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 :) *Try to avoid unnecessary file unclusions (see config.php and mainfile.php) 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. *Templates I reiterate my suggestion that everyone takes a look at the Smarty templates system. I posted the URL in a previous mail. For the rest, I think the documentation and guidelines you put up will be invaluable to the development team - good work. > -----Message d'origine----- > De : php...@li... > [mailto:php...@li...]De la part de > Karsten Dambekalns > Envoyé : mardi 27 mars 2001 13:56 > À : phpWebsite dev > Objet : [Phpwebsite-developers] Developer docs update > > > Hi everybody! > > I updated the developer docs at > http://www.k-fish.de/krabutzig/phpwebsite/ > > I removed the function overview files, this is handled better by PHPDoc. > Talking of which: I added some explanations how to write PHPDoc > comments and > wrote something about coding style. > > Take the part about the coding style with a grain of salt and send your > comments about that (important issue) in for some discussion. We should > settle on some/a good coding style as sson as possible. > > The new documentation has also been commited to CVS. I will do a > new PHPDoc > run today or tomorrow and put that up as well. > > 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 > |
|
From: Jason C. <cam...@xp...> - 2001-03-27 18:26:14
|
Alan, Didn't see your last mention of Smarty Templates so I went looking for it on hotscripts and found it. It looks very interesting. I like how its done with a class and it uses PEAR to some degree. If we were to use PEAR for other functions (database) instead of ADODB or something else then I think Smarty Templates could be used, but I haven't looked at it enough yet but it does look promising.... Jason Campbell Xplozive Media Technologies > Hi, > > A couple of comments: > > * 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 :) > > *Try to avoid unnecessary file unclusions (see config.php and > mainfile.php) 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. > > *Templates > I reiterate my suggestion that everyone takes a look at the Smarty > templates system. I posted the URL in a previous mail. > > For the rest, I think the documentation and guidelines you put up will > be invaluable to the development team - good work. > >> -----Message d'origine----- >> De : php...@li... >> [mailto:php...@li...]De la part >> de Karsten Dambekalns >> Envoyé : mardi 27 mars 2001 13:56 >> À : phpWebsite dev >> Objet : [Phpwebsite-developers] Developer docs update >> >> >> Hi everybody! >> >> I updated the developer docs at >> http://www.k-fish.de/krabutzig/phpwebsite/ >> >> I removed the function overview files, this is handled better by >> PHPDoc. Talking of which: I added some explanations how to write >> PHPDoc >> comments and >> wrote something about coding style. >> >> Take the part about the coding style with a grain of salt and send >> your comments about that (important issue) in for some discussion. We >> should settle on some/a good coding style as sson as possible. >> >> The new documentation has also been commited to CVS. I will do a new >> PHPDoc >> run today or tomorrow and put that up as well. >> >> 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 >> > > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
|
From: Alain F. <al...@va...> - 2001-03-27 18:48:16
|
Hi Jason, Actually, Smarty uses PEAR but only in a very limited way, namely to handle some very optional "config file" support. Here's the real URL again for your reference : http://www.phpinsider.com/php/code/Smarty/ The authors are very responsive and supporting to user issues, too; I consider this as a strong point. > -----Message d'origine----- > De : php...@li... > [mailto:php...@li...]De la part de > Jason Campbell > Envoyé : mardi 27 mars 2001 20:35 > À : php...@li... > Objet : RE: [Phpwebsite-developers] Developer docs update > > > Alan, > > Didn't see your last mention of Smarty Templates so I went looking for it > on hotscripts and found it. It looks very interesting. I like how its > done with a class and it uses PEAR to some degree. If we were to > use PEAR > for other functions (database) instead of ADODB or something else then I > think Smarty Templates could be used, but I haven't looked at it > enough yet > but it does look promising.... > > Jason Campbell > Xplozive Media Technologies > > > > Hi, > > > > A couple of comments: > > > > * 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 :) > > > > *Try to avoid unnecessary file unclusions (see config.php and > > mainfile.php) 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. > > > > *Templates > > I reiterate my suggestion that everyone takes a look at the Smarty > > templates system. I posted the URL in a previous mail. > > > > For the rest, I think the documentation and guidelines you put up will > > be invaluable to the development team - good work. > > > >> -----Message d'origine----- > >> De : php...@li... > >> [mailto:php...@li...]De la part > >> de Karsten Dambekalns > >> Envoyé : mardi 27 mars 2001 13:56 > >> À : phpWebsite dev > >> Objet : [Phpwebsite-developers] Developer docs update > >> > >> > >> Hi everybody! > >> > >> I updated the developer docs at > >> http://www.k-fish.de/krabutzig/phpwebsite/ > >> > >> I removed the function overview files, this is handled better by > >> PHPDoc. Talking of which: I added some explanations how to write > >> PHPDoc > >> comments and > >> wrote something about coding style. > >> > >> Take the part about the coding style with a grain of salt and send > >> your comments about that (important issue) in for some discussion. We > >> should settle on some/a good coding style as sson as possible. > >> > >> The new documentation has also been commited to CVS. I will do a new > >> PHPDoc > >> run today or tomorrow and put that up as well. > >> > >> 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 > >> > > > > > > > > _______________________________________________ > > 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 > |
|
From: Jason C. <cam...@xp...> - 2001-03-27 18:53:39
|
Alain, Do you know of anyone currently using Smarty templates?? Any other projects?? I would like to see it in action in a real environment. Jason Campbell Xplozive Media Technologies > Hi Jason, > > > Actually, Smarty uses PEAR but only in a very limited way, namely to > handle some very optional "config file" support. > > Here's the real URL again for your reference : > http://www.phpinsider.com/php/code/Smarty/ > > The authors are very responsive and supporting to user issues, too; I > consider this as a strong point. > >> -----Message d'origine----- >> De : php...@li... >> [mailto:php...@li...]De la part >> de Jason Campbell >> Envoyé : mardi 27 mars 2001 20:35 >> À : php...@li... >> Objet : RE: [Phpwebsite-developers] Developer docs update >> >> >> Alan, >> >> Didn't see your last mention of Smarty Templates so I went looking for >> it on hotscripts and found it. It looks very interesting. I like how >> its done with a class and it uses PEAR to some degree. If we were to >> use PEAR >> for other functions (database) instead of ADODB or something else then >> I think Smarty Templates could be used, but I haven't looked at it >> enough yet >> but it does look promising.... >> >> Jason Campbell >> Xplozive Media Technologies >> >> >> > Hi, >> > >> > A couple of comments: >> > >> > * 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 :) >> > >> > *Try to avoid unnecessary file unclusions (see config.php and >> > mainfile.php) 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. >> > >> > *Templates >> > I reiterate my suggestion that everyone takes a look at the Smarty >> > templates system. I posted the URL in a previous mail. >> > >> > For the rest, I think the documentation and guidelines you put up >> > will be invaluable to the development team - good work. >> > >> >> -----Message d'origine----- >> >> De : php...@li... >> >> [mailto:php...@li...]De la >> >> part de Karsten Dambekalns >> >> Envoyé : mardi 27 mars 2001 13:56 >> >> À : phpWebsite dev >> >> Objet : [Phpwebsite-developers] Developer docs update >> >> >> >> >> >> Hi everybody! >> >> >> >> I updated the developer docs at >> >> http://www.k-fish.de/krabutzig/phpwebsite/ >> >> >> >> I removed the function overview files, this is handled better by >> >> PHPDoc. Talking of which: I added some explanations how to write >> >> PHPDoc >> >> comments and >> >> wrote something about coding style. >> >> >> >> Take the part about the coding style with a grain of salt and send >> >> your comments about that (important issue) in for some discussion. >> >> We should settle on some/a good coding style as sson as possible. >> >> >> >> The new documentation has also been commited to CVS. I will do a >> >> new PHPDoc >> >> run today or tomorrow and put that up as well. >> >> >> >> 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 >> >> >> > >> > >> > >> > _______________________________________________ >> > 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 |
|
From: Alain F. <al...@va...> - 2001-03-27 19:15:35
|
Hello, I don't know of any public site that is using Smarty, which doesn't mean there aren't any. Nevertheless, I am using it myself for the project I am currently developing, and one of my colleagues is using it for a "Yahoo style" site for Luxembourg, too, with great success so far. However, I can't say anything about speed/reliability and what else for high-traffic sites, as I don't know of any. Maybe you can contact the authors directly and ask for references ? Thanks ! > -----Message d'origine----- > De : php...@li... > [mailto:php...@li...]De la part de > Jason Campbell > Envoyé : mardi 27 mars 2001 21:02 > À : php...@li... > Objet : Re: [Phpwebsite-developers] Template system (Smarty) > > > Alain, > > Do you know of anyone currently using Smarty templates?? Any other > projects?? I would like to see it in action in a real environment. > > Jason Campbell > Xplozive Media Technologies > > > > Hi Jason, > > > > > > Actually, Smarty uses PEAR but only in a very limited way, namely to > > handle some very optional "config file" support. > > > > Here's the real URL again for your reference : > > http://www.phpinsider.com/php/code/Smarty/ > > > > The authors are very responsive and supporting to user issues, too; I > > consider this as a strong point. > > > >> -----Message d'origine----- > >> De : php...@li... > >> [mailto:php...@li...]De la part > >> de Jason Campbell > >> Envoyé : mardi 27 mars 2001 20:35 > >> À : php...@li... > >> Objet : RE: [Phpwebsite-developers] Developer docs update > >> > >> > >> Alan, > >> > >> Didn't see your last mention of Smarty Templates so I went looking for > >> it on hotscripts and found it. It looks very interesting. I like how > >> its done with a class and it uses PEAR to some degree. If we were to > >> use PEAR > >> for other functions (database) instead of ADODB or something else then > >> I think Smarty Templates could be used, but I haven't looked at it > >> enough yet > >> but it does look promising.... > >> > >> Jason Campbell > >> Xplozive Media Technologies > >> > >> > >> > Hi, > >> > > >> > A couple of comments: > >> > > >> > * 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 :) > >> > > >> > *Try to avoid unnecessary file unclusions (see config.php and > >> > mainfile.php) 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. > >> > > >> > *Templates > >> > I reiterate my suggestion that everyone takes a look at the Smarty > >> > templates system. I posted the URL in a previous mail. > >> > > >> > For the rest, I think the documentation and guidelines you put up > >> > will be invaluable to the development team - good work. > >> > > >> >> -----Message d'origine----- > >> >> De : php...@li... > >> >> [mailto:php...@li...]De la > >> >> part de Karsten Dambekalns > >> >> Envoyé : mardi 27 mars 2001 13:56 > >> >> À : phpWebsite dev > >> >> Objet : [Phpwebsite-developers] Developer docs update > >> >> > >> >> > >> >> Hi everybody! > >> >> > >> >> I updated the developer docs at > >> >> http://www.k-fish.de/krabutzig/phpwebsite/ > >> >> > >> >> I removed the function overview files, this is handled better by > >> >> PHPDoc. Talking of which: I added some explanations how to write > >> >> PHPDoc > >> >> comments and > >> >> wrote something about coding style. > >> >> > >> >> Take the part about the coding style with a grain of salt and send > >> >> your comments about that (important issue) in for some discussion. > >> >> We should settle on some/a good coding style as sson as possible. > >> >> > >> >> The new documentation has also been commited to CVS. I will do a > >> >> new PHPDoc > >> >> run today or tomorrow and put that up as well. > >> >> > >> >> 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 > >> >> > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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 mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > |
|
From: Alain F. <al...@va...> - 2001-03-27 20:32:27
|
Hi again, Here, straight from the author :) <-- Monte Ohrt says: --> The only ones I know of are ones we built. here are a couple. http://www.dailynebraskan.com http://www.torchonline.com <-- end quote --> > -----Message d'origine----- > De : php...@li... > [mailto:php...@li...]De la part de > Jason Campbell > Envoyé : mardi 27 mars 2001 21:02 > À : php...@li... > Objet : Re: [Phpwebsite-developers] Template system (Smarty) > > > Alain, > > Do you know of anyone currently using Smarty templates?? Any other > projects?? I would like to see it in action in a real environment. > > Jason Campbell > Xplozive Media Technologies > > > > Hi Jason, > > > > > > Actually, Smarty uses PEAR but only in a very limited way, namely to > > handle some very optional "config file" support. > > > > Here's the real URL again for your reference : > > http://www.phpinsider.com/php/code/Smarty/ > > > > The authors are very responsive and supporting to user issues, too; I > > consider this as a strong point. > > > >> -----Message d'origine----- > >> De : php...@li... > >> [mailto:php...@li...]De la part > >> de Jason Campbell > >> Envoyé : mardi 27 mars 2001 20:35 > >> À : php...@li... > >> Objet : RE: [Phpwebsite-developers] Developer docs update > >> > >> > >> Alan, > >> > >> Didn't see your last mention of Smarty Templates so I went looking for > >> it on hotscripts and found it. It looks very interesting. I like how > >> its done with a class and it uses PEAR to some degree. If we were to > >> use PEAR > >> for other functions (database) instead of ADODB or something else then > >> I think Smarty Templates could be used, but I haven't looked at it > >> enough yet > >> but it does look promising.... > >> > >> Jason Campbell > >> Xplozive Media Technologies > >> > >> > >> > Hi, > >> > > >> > A couple of comments: > >> > > >> > * 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 :) > >> > > >> > *Try to avoid unnecessary file unclusions (see config.php and > >> > mainfile.php) 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. > >> > > >> > *Templates > >> > I reiterate my suggestion that everyone takes a look at the Smarty > >> > templates system. I posted the URL in a previous mail. > >> > > >> > For the rest, I think the documentation and guidelines you put up > >> > will be invaluable to the development team - good work. > >> > > >> >> -----Message d'origine----- > >> >> De : php...@li... > >> >> [mailto:php...@li...]De la > >> >> part de Karsten Dambekalns > >> >> Envoyé : mardi 27 mars 2001 13:56 > >> >> À : phpWebsite dev > >> >> Objet : [Phpwebsite-developers] Developer docs update > >> >> > >> >> > >> >> Hi everybody! > >> >> > >> >> I updated the developer docs at > >> >> http://www.k-fish.de/krabutzig/phpwebsite/ > >> >> > >> >> I removed the function overview files, this is handled better by > >> >> PHPDoc. Talking of which: I added some explanations how to write > >> >> PHPDoc > >> >> comments and > >> >> wrote something about coding style. > >> >> > >> >> Take the part about the coding style with a grain of salt and send > >> >> your comments about that (important issue) in for some discussion. > >> >> We should settle on some/a good coding style as sson as possible. > >> >> > >> >> The new documentation has also been commited to CVS. I will do a > >> >> new PHPDoc > >> >> run today or tomorrow and put that up as well. > >> >> > >> >> 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 > >> >> > >> > > >> > > >> > > >> > _______________________________________________ > >> > 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 mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > |
|
From: Karsten D. <k.d...@tu...> - 2001-03-28 10:19:50
|
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 |
|
From: Todd O. <to...@da...> - 2001-03-28 22:11:46
|
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
|
|
From: Alain F. <al...@va...> - 2001-03-28 22:41:05
|
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 !
|
|
From: Todd O. <to...@da...> - 2001-03-29 01:21:54
|
> 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
|
|
From: Spiggy T. <th...@me...> - 2001-03-29 01:59:29
|
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
|
|
From: Jason C. <cam...@xp...> - 2001-03-29 03:25:17
|
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
|
|
From: Karsten D. <k.d...@tu...> - 2001-03-29 09:24:38
|
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 |
|
From: Todd O. <to...@da...> - 2001-03-29 14:32:01
|
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 |
|
From: Alain F. <al...@va...> - 2001-03-29 15:04:51
|
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 > > |
|
From: Karsten D. <k.d...@fi...> - 2001-03-29 16:39:54
|
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/ ----------------------------------------------------- |
|
From: Alain F. <al...@va...> - 2001-03-29 17:46:25
|
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
|
|
From: clayton c. <cc...@ca...> - 2001-03-29 19:00:25
|
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 .... |
|
From: Todd O. <to...@da...> - 2001-03-29 19:35:36
|
> 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 |
|
From: Jason C. <cam...@xp...> - 2001-03-29 19:39:34
|
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 |
|
From: clayton c. <cc...@ca...> - 2001-03-29 21:02:46
|
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 ... |
|
From: Todd O. <to...@da...> - 2001-03-29 21:27:02
|
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 |
|
From: Alain F. <al...@va...> - 2001-03-29 23:09:26
|
Hi, http://www.phpsecurepages.f2s.com/ This looks really good ! Take a look. Alain |
|
From: Karsten D. <k.d...@tu...> - 2001-03-30 12:00:52
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X