Menu
▾
▴
SV: [Phpwebsite-developers] Template system (Smarty)
|
From: Frits J. <FJ...@uv...> - 2001-03-29 18:12:16
|
> -----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 |
