From: Todd O. <to...@da...> - 2001-04-24 01:52:20
|
We need to decide on the following standards: What file extension will we use for included files? included.php, included.inc, included.inc.php, etc. What file extension will we use for classes? included.class, included.class.php, etc.? Does anyone have a comprehensive set of CSS descriptors we should use? ex. .big, .red, .bigred, .path, .smallnav, etc. ezPublish has a good start. Should we use theirs? This will be a standard for the core and module programmers. --Todd P.S. Can we change the term plug-ins to modules? |
From: Alain F. <al...@va...> - 2001-04-24 07:02:04
|
Hello Todd, One note about the file extensions to use. We will have to pay attention to them for security reasons. Most PHP configurations are setup to only parse the .PHP extension. Now imagine a config.inc file that contains database passwords and what not else... if you call it from the browser, it is sent in clear text because PHP doesn't parse the .inc extension. It might be obvious but I preferred to point it out nevertheless. As for the CSS selectors and classes, shouldn't we first try to think about the layout and then deduct what selectors we will need? If we are first setting the selectors, we will maybe be limited in our layout and design choices because we might not have "enough" selectors. Or we will have too many, with some never being used at all? Regards, Alain > -----Message d'origine----- > De : php...@li... > [mailto:php...@li...]De la part de > Todd Owen > Envoyé : mardi 24 avril 2001 03:50 > À : php...@li... > Objet : [Phpwebsite-developers] Additional Standards > > > We need to decide on the following standards: > > What file extension will we use for included files? > included.php, included.inc, included.inc.php, etc. > > What file extension will we use for classes? > included.class, included.class.php, etc.? > > Does anyone have a comprehensive set of CSS descriptors we should use? > ex. .big, .red, .bigred, .path, .smallnav, etc. > ezPublish has a good start. Should we use theirs? > This will be a standard for the core and module programmers. > > --Todd > > P.S. Can we change the term plug-ins to modules? > > > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > |
From: Jason C. <cam...@xp...> - 2001-04-24 10:34:01
|
(This is just my opinion) Once the the core dev group is named, then they could discuss getting the database and other features in place so the rest of the groups can get other things developed. Its all down-hill once the main core of the system is established. Once that happens, then the theme system, language system, etc will all fall into place. Once all the teams are named, they could start establishing feature sets, etc for their individual module group (auth, theme system, etc). I'm working on a new way of writing the plug-ins (modules). But I'm just working with concept ideas and other things until the major parts of phpWebSite II are decided. Theme system, language routines, etc etc will all have to be some what in place for anyone on the plug-in team to be able to really finalize coding on alot of the plug-ins (modules). Todd and I were discussing that the plug-ins (modules) could/should have their own template and language file. Thats almost a given for some if not all of the plug-ins (modules). So, that part of the plug-in code would have to be written once the theme (template) and language systems are in place. > Hello Todd, > > One note about the file extensions to use. We will have to pay > attention to them for security reasons. Most PHP configurations are > setup to only parse the .PHP extension. Now imagine a config.inc file > that contains database passwords and what not else... if you call it > from the browser, it is sent in clear text because PHP doesn't parse > the .inc extension. It might be obvious but I preferred to point it out > nevertheless. > > As for the CSS selectors and classes, shouldn't we first try to think > about the layout and then deduct what selectors we will need? If we are > first setting the selectors, we will maybe be limited in our layout and > design choices because we might not have "enough" selectors. Or we will > have too many, with some never being used at all? > > Regards, > > Alain > >> -----Message d'origine----- >> De : php...@li... >> [mailto:php...@li...]De la part >> de Todd Owen >> Envoyé : mardi 24 avril 2001 03:50 >> À : php...@li... >> Objet : [Phpwebsite-developers] Additional Standards >> >> >> We need to decide on the following standards: >> >> What file extension will we use for included files? >> included.php, included.inc, included.inc.php, etc. >> >> What file extension will we use for classes? >> included.class, included.class.php, etc.? >> >> Does anyone have a comprehensive set of CSS descriptors we should use? >> ex. .big, .red, .bigred, .path, .smallnav, etc. >> ezPublish has a good start. Should we use theirs? >> This will be a standard for the core and module programmers. >> >> --Todd >> >> P.S. Can we change the term plug-ins to modules? >> >> >> >> >> _______________________________________________ >> 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 -- Jason Campbell Xplozive Media Technologies www.xplozivemedia.com phpWebSite Developer |
From: Jason C. <cam...@xp...> - 2001-04-24 10:17:29
|
Todd, After we discussed a few of the things on the phone, I was thinking about having the current plug-ins stay as plugins. That would make it backward compatiable which is one thing in the Road Map. So if thats true, we leave the plug-ins as plug-ins and make a new group called "modules" and anything new we go towards being modules which will be a new "hybrid" of the current plug-in system. I've got the referrer as a plug-in NICE and clean now with everything for it in one file in its own plug-in directory using functions (which might change for the OOP way) and it works just fine. We can get rid of passing too many variables in the URL by using global variables for the features of the "modules". And for some reason I just mixed using "plug-ins" and modules but oh well :) > We need to decide on the following standards: > > What file extension will we use for included files? > included.php, included.inc, included.inc.php, etc. > > What file extension will we use for classes? > included.class, included.class.php, etc.? > > Does anyone have a comprehensive set of CSS descriptors we should use? > ex. .big, .red, .bigred, .path, .smallnav, etc. > ezPublish has a good start. Should we use theirs? > This will be a standard for the core and module programmers. > > --Todd > > P.S. Can we change the term plug-ins to modules? > > > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers -- Jason Campbell Xplozive Media Technologies www.xplozivemedia.com phpWebSite Developer |
From: Karsten D. <k.d...@tu...> - 2001-04-24 11:10:14
|
On Mon, Apr 23, 2001 at 09:49:50PM -0400, Todd Owen wrote: > Does anyone have a comprehensive set of CSS descriptors we should use? > ex. .big, .red, .bigred, .path, .smallnav, etc. > ezPublish has a good start. Should we use theirs? > This will be a standard for the core and module programmers. We (that is Frits Jensen, W.D. Sumilang and Karsten Dambekalns) are in the process of developing a suggestion for this topic. If you all could be patient a few more days, we will likely have something to submit here... 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: Aaron A. <aa...@wc...> - 2001-04-24 13:09:24
|
In my experience, using a semantic naming convention works best for CSS .class names (that is, your descriptors should denote functionality). Example:=20 .smaller =3D INCORRECT .copyright =3D CORRECT .big5 =3D INCORRECT .subtitle =3D CORRECT Not only is it easier for someone to understand a site's style at a glance, but a semantic naming convention will help identify content for future XML applications. Thoughts? --- Aaron Adams From: Karsten Dambekalns <k.d...@tu...> Organization: fishfarm Reply-To: php...@li... Date: Tue, 24 Apr 2001 13:08:41 +0200 To: php...@li... Subject: Re: [Phpwebsite-developers] Additional Standards On Mon, Apr 23, 2001 at 09:49:50PM -0400, Todd Owen wrote: > Does anyone have a comprehensive set of CSS descriptors we should use? > ex. .big, .red, .bigred, .path, .smallnav, etc. > ezPublish has a good start. Should we use theirs? > This will be a standard for the core and module programmers. We (that is Frits Jensen, W.D. Sumilang and Karsten Dambekalns) are in the process of developing a suggestion for this topic. If you all could be patient a few more days, we will likely have something to submit here... 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-04-24 13:24:25
|
Re: [Phpwebsite-developers] Additional StandardsHello, I absolutely agree. Sorry for the shortness of the mail, but there's nothing more to add :) -----Message d'origine----- De : php...@li... [mailto:php...@li...]De la part de Aaron Adams Envoyé : mardi 24 avril 2001 15:08 À : php...@li... Objet : Re: [Phpwebsite-developers] Additional Standards In my experience, using a semantic naming convention works best for CSS .class names (that is, your descriptors should denote functionality). Example: .smaller = INCORRECT .copyright = CORRECT .big5 = INCORRECT .subtitle = CORRECT Not only is it easier for someone to understand a site's style at a glance, but a semantic naming convention will help identify content for future XML applications. Thoughts? --- Aaron Adams From: Karsten Dambekalns <k.d...@tu...> Organization: fishfarm Reply-To: php...@li... Date: Tue, 24 Apr 2001 13:08:41 +0200 To: php...@li... Subject: Re: [Phpwebsite-developers] Additional Standards On Mon, Apr 23, 2001 at 09:49:50PM -0400, Todd Owen wrote: > Does anyone have a comprehensive set of CSS descriptors we should use? > ex. .big, .red, .bigred, .path, .smallnav, etc. > ezPublish has a good start. Should we use theirs? > This will be a standard for the core and module programmers. We (that is Frits Jensen, W.D. Sumilang and Karsten Dambekalns) are in the process of developing a suggestion for this topic. If you all could be patient a few more days, we will likely have something to submit here... 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: clayton c. <cc...@ca...> - 2001-04-24 15:04:58
|
> We need to decide on the following standards: > > What file extension will we use for included files? > included.php, included.inc, included.inc.php, etc. i suggest included.inc.php - the php at the end for security, and the inc to let us know what it is > What file extension will we use for classes? > included.class, included.class.php, etc.? probably .class.php . we dont want to confuse people with Java background. > Can we change the term plug-ins to modules? +1 |
From: Todd O. <to...@da...> - 2001-04-25 00:40:17
|
Great. I'm all for ending each code file with (.php). It allows vi to get the syntax highlighting done automatically. Will we use .tpl for templates or how about .tpl.html? --Todd |
From: Brian W. B. <br...@ap...> - 2001-05-01 17:06:58
|
> What file extension will we use for included files? > included.php, included.inc, included.inc.php, etc. I vote for included.inc.php > > What file extension will we use for classes? > included.class, included.class.php, etc.? and included.class.php > Does anyone have a comprehensive set of CSS descriptors we should use? ex. > .big, .red, .bigred, .path, .smallnav, etc. > ezPublish has a good start. Should we use theirs? > This will be a standard for the core and module programmers. Contact Brian Lambeth regarding this - I have no problem adopting the ezPublish CSS descriptors (especially since the current CSS descriptors leave *a lot to be desired*) ;) > P.S. Can we change the term plug-ins to modules? Originally, we choose the term "plug-in" to differentiate ourselves from Nuke's "Add-ons" and felt the term implied a certain ease of use. At a certain level I don't care, but don't think the term "plug-in" is bad (maybe because it smells so fresh?) I say let's post a survey and go with the majority... -- Brian W. Brown Internet Systems Architect, ESS Student Development Room 269, John Thomas Hall Appalachian State University Boone, NC 28608 vox: 828-262-7124 fax: 828-262-2585 |