> On Fri, 1 Mar 2002, Jamie McClelland <jmcclelland@...> wrote
>>Hi all - this is a converstation Dave and I were having off list about
>>a site I'm involved with that turned into a conversation relevant to
>>the list, so I'm copying it back to you all for feedback. It's also
>>relevant to a comment Kermit made earlier about the complexity of
> My continuation of the conversation a lot further down........
>>>>> style.php to produce different stylesheets for Mac or PC???????
>>>>Ahh yes, that site was the one I used to test pagetool from the
>>>>beginning (before style.php). It's designed by another person (who
>>>>has been designing a number of pagetool sites). He took one look at
>>>>style.php and gave up because he thought it was too complicated.
>>>>For Pagetool 2 I've been thinking a lot about it because if you're
>>>>not into PHP, I think that reaction is going to be the norm. I know
>>>>this is less elegant, but what if style.php simply sniffed browsers
>>>>types, and then included a seperate .css file based on the results.
>>>>Then, you could have a folder of css files called:
>>>>etc. etc. It would be less elegant, because everytime you wanted to
>>>>change a style, you would have to change it in multiple style sheets
>>>>(ugh). But - it would be very straight forward and easy to
>>>>understand. Perhaps, there could be a way to simplify it if you want
>>>>(for example - just check for Mac vs. PC).
>>>>What do you think?
>>> Or produce style sheets in the way we currently produce pages. Log
>>> the admin and get a style sheet edit page showing the styles
>>> available for the browser they are using, both the text, and some
>>> example text
>>> and then the ability to add/delete/edit styles for that type of
>>> browser, and then a master list of all the styles....... words
>>> aren't working here, I'll try and do an example page to show you
>>> sort of what I mean. But basically the web designer wouldn't go
>>> anywhere near the files, just enter and configure styles via a web
>>I'm really torn with the elegance of having *everything* being database
>>driven. In some ways it makes things much simpler for us as developers
>>and it certainly is cleaner. However, there are two concerns I have:
>>1. Making it easier for web site developers: most of the web site
>>developers I know are designers first and coders second. They learned
>>style sheets and are used to them - and they are not much interested in
>>learning a new way of doing something. For example - MJ's lead designer
>>will do whatever it takes to disable any "feature" we have so that he
>>can edit is pc.css and mac.css style sheets like he always has because
>>he already has created these style sheets and just needs to make small
>>modifications for the new site and plop them in. No data entry, no web
> So maybe we need to make Pagetool able to read in a current html AND
> css site and produce a working Pagetool site. Reading the .html and
> .css files from disk (easy), parsing them and extracting the correct
> data (regular expression's again = difficult!), and dumping the data
> into the correct Pagetool tables (easy once you've got the _correct_
> data out of the files).
> If the user interface for the style sheets then mimicked the thought
> process of the CSS designer:
> - looks great in NN6 on mac (designer right, must do the first design
> on mac and also NOT in a MS browser ) - now what about ie4 on windows,
> mmm make all the fonts a bit smaller - ok - mmm, that alignment's out
> a bit there, adjust that border value there, and there, and there,
> mmm, ok - ie3 aghaghaghha, can't read a thing, ah, em's are px now, ok
> change all those em's to px, and change all those em values as well,
> and . . . . . . . . . . . .
> then EVEN the MJ designer could be persuaded to use the facilities
> Pagetool offered <grin>
I'm still not convinced on the simplicity argument here. To build something
tat would parse .css files would be complicated to code. And then, if the
designer wanted to make changes, they would either have to change the
original style sheets and then re-enter them into the database, or mess
with a (to be built) web interface.
This is a lot of coding that could be replaced with:
1. One simple css.php script that sniffs for browser type and redirects to
one of 3-4 stock style sheets.
2. 3-4 stock style sheets. I don't agree with Gunther's suggestion that we
don't use style sheets, but I do agree that we could simplify our style
sheets (just one text style and two header styles). The differences between
browsers would be included in the stock style sheets already (i.e. smaller
sizes for windows, em instead of px where appropriate).
Then the designer simply needs to modify the existing styles and/or add
This approach is also very easy to maintain - as new browser versions are
released - it simply requires one new line in style.php and a new style
sheet if necessary.
Now, I think we should continue to use the Pagetool 1 style.php code for
the admin interface (which web site designer shouldn't be changing anyway).
These style sheets would have the browser variations all
>>2. Less SQL calls - if only one person is accessing your site at a
>>time, then it doesn't make much difference whether it takes 2 sql calls
>>to produce the page or 3 calls. But if you have 20 people accessing
>>your site at the same time, then the difference is between 40 sql calls
>>and 60 sql calls - which can make a difference. And, the busy your site
>>is, the bigger the difference.
> The dynamic style sheet send out headers so it is cached by the browser
> for, currently, 24 hours (this could be increased). The call to get
> the stylesheet (para-phrased (is that the word?)) could be:
> SELECT * FROM styles WHERE browser='IE5up' AND os='win'
> Just the one sql call per person per day.
ahhh...I see you are right, so I guess the performance argument is moot :-).
>>For me - this is similar to the idea of keeping the pt_config.inc
>>values in the database as opposed to having them in a file.
> If we built up one BIG sql statement we could do ONE call per Pagetool
> page, I _think_. Currently there are five for a homepage with news:
> 1 SELECT for the page itself
> 2 SELECT for the header
> 3 SELECT for the sidebar
> 4 SELECT for the newsbar
> 5 SELECT for the footer
Yes! This is Pagetool-1 dirty secret. Shhhh...
> I _think_ we could do the one select, and then spit out the data.
> Plugins like pt_edit_this_page add a further select call, but in
> Pagetool 2 if that call could be added to the main call, then still
> only the one call.
Yes again - this is the way it's currently set up with Pagetool 2. The main
page and all related pages are called with one big sql statement. If a
plugin makes another sql statement, well, that can't be helped, but at
least we aren't making a separate call for each sidebar, footer, header,
> And if pages don't change much, cache headers could
> be set to that in any one session/day/week a user could get the page
> from his browsers cache depending on how he sets his cache. If a page
> has been edited recently we could send a different time cache header
> so that people got the latest page. The last modified cache header
> could be the time the page was last edited in Pagetool. Currently, as
> with all PHP pages, the browser receives cache information that means
> it go gets the page again on EVERY view, even if the user had been on
> that page in the last few seconds. This is all assuming I understand
> the way caching works of course :-)
I'm not cache expert myself - but if there ways we could use it to improve
response time it would surely be worth it. Would there be a way, for
example, to somehow cache the results of a sql call to the pt_config table?
>>Perhaps, with both issues, the best answer is to have the option - you
>>can switch on database styles or switch if off and use a regular style
>>sheet. Or, you can switch on database config options, or switch it off
>>and use a regular pt_config.inc file.
> The more options we give the more confusing it will be for the admin to
> get Pagetool up and running in the first instance, and the more
> complicated for us to program for all combinations of all options!
Yes true. But - for example in Pagetool 1, there are a number of advanced
options that can only be set by hand in the pt_config.inc file. They are
not available in the profile web interface. This way - it keeps it simple
for 90% of users that don't need it, but it is still available for 10% of
users who need it and aren't intimidated by a text file.
>>> Maybe you should send this style stuff back to the list so everyone
>>> else can comment.
> And here it is <grin>
> d a v e
> Pagetool-devel mailing list