Pagetool

Hi G=FCnther, hi all,

On Sat, 2 Mar 2002, Gunther Dippe <dippe@...> wrote
>Hi all,
>
>I didn't say that we're not going to use style sheets (in response to Jami=
e)
>but try to keep the one/ones we use simple.

I do agree with KISS, wherever possible.


>Maybe we should also consider i.e. if version 3 of NS/IE or compatible is =
the
>minimum requirement. It could also be specified that CSS1 capable browsers
>are required but that would in fact disqualify most of them :-(
>

Yes, I don't think there is ANY browser available that is 100% correct=20
when it comes to rendering CSS1. Most of the major ones, IE6, NN6,=20
Opera6 and so on are _almost_ there now, but earlier versions........


>And I frankly don't know whether at least simple positioning of textblocks
>and pictures (media) works well with different browsers (to avoid tables).=
 If
>I read Jamie's and Dave's conversation correctly it doesn't seem to be the
>case.
>

It works more or less OK in newer browsers AFAIK.

>Style sheets are of course more than getting font sizes correct but to tell
>you the truth the standard settings in Pt 1 doesn't do a good jobb when us=
ing
>MacOS/NS 4+. If this is hard to work out, what problems are around the cor=
ner
>then?
>

I don't have NS 4+ on Mac to test with. What values is style.php=20
currently setting, and what values do you think it should be setting?=20
Set $debug=3DTRUE in style.php and call the script with your browser to=20
see the current values. The first lien produced is very useful to see=20
how phpSniff categorises the browser you are using.

>There are compatibility listings on the net what works with different
>browsers, versions and plattforms and maybe it is better to create a list =
of
>tags what works with most browsers and use it as the base for Pt 2 if we
>don't adopt Jamie's suggestion and use different style sheets depending on
>browser used?
>
>We'll end up with maybe 5 or 6 of them and then hope that the sniffer does=
 a
>good job of identifying the browser (and also hope that users of Opera don=
't
>pretend to be anything else but Opera).
>


Most versions of Opera render HTML and CSS better than the corresponding=20
IE version. So I don't see that as a major problem.



>IT is a very immature phenomenon in many respects especially when not even
>simple standards like CSS1 are implemented after more than 5 years in some
>browsers. This makes life miserable for the developer community.
>

I'm not miserable! I'm enjoying the challenge <grin>


>Dave!
>I know that freshmeat produce 20% content and 80% "code" to get that conte=
nt
>correct in browsers but my point was that it seems to work.


My point was also that a lot of the code was actually broken, and the=20
code could in fact be reduced in size while still maintaining the look=20
across many browsers.

> For the rest I
>agree with you :-)


Great! :-)


So the core of Pagetool 2 should be:
User/group creation and permissions management
Basic editing of php/ html pages that are stored in the database
Pages produced by reference to a file based template.
Uploading/deletion of media
Basic editing of a single style sheet?

And plugins should extend that functionality to include the browser=20
dependant dynamic stylesheet that I have visualised in my head :-)
And also a browser dependant choice of the template to use as well.


Plugins need to be able to alter ALL areas of Pagetool, including the=20
admin interface.


And I do feel, moving slightly off the subject of style sheets, that=20
configuration of these things should be done in the ONE place for each=20
set of configuration option. for example ALL html produced should come=20
from template files, ALL $ptconf[] values from the database (OK,=20
exception here for the database user/password etc vars <grin>), ALL=20
styles from, maybe a file based template system for the basic system,=20
and a database system for the more advanced style system.

That's it for now. I think this thread could run and run, with all of us=20
agreeing, almost, in principle but having differing views about=20
implementation. <grin>

--=20
Cheers,

  d  a  v  e

<snipped style sheet conversation>
>
>
> So the core of Pagetool 2 should be:
> User/group creation and permissions management
> Basic editing of php/ html pages that are stored in the database
> Pages produced by reference to a file based template.
> Uploading/deletion of media

I thik media should be a plugin too! In fact I think it could be two
plugins - one plugin that doesn't use ftp - it writes the images to disk
(this for people with root access to their machines - perhaps that don't
want FTP because it's insecure) and another media plugin that uses FTP.

> Basic editing of a single style sheet?

To be debated... :-).

>
> And plugins should extend that functionality to include the browser
> dependant dynamic stylesheet that I have visualised in my head :-) And
> also a browser dependant choice of the template to use as well.
>
>
> Plugins need to be able to alter ALL areas of Pagetool, including the
> admin interface.

Yes - I hope with hooks we can do this.

>
>
> And I do feel, moving slightly off the subject of style sheets, that
> configuration of these things should be done in the ONE place for each
> set of configuration option. for example ALL html produced should come
> from template files,

yes!
>ALL $ptconf[] values from the database (OK,
> exception here for the database user/password etc vars <grin>),

well, maybe with an option to pull them from a file ...
>ALL
> styles from, maybe a file based template system for the basic system,
> and a database system for the more advanced style system.
yes.

AND, all language contained in separate language files!

>
> That's it for now. I think this thread could run and run, with all of
> us  agreeing, almost, in principle but having differing views about
> implementation. <grin>

Yes, one of the days I may even have enough time left over after wrting
email to add some more code to Pagetool 2 :-).

Jamie

>
> --
> Cheers,
>
>  d  a  v  e
>
> _______________________________________________
> Pagetool-devel mailing list
> Pagetool-devel@...
> https://lists.sourceforge.net/lists/listinfo/pagetool-devel

Hi all,
Stylesheets are supposed to make life simpler :-) but it seems that the more 
we bury our heads into it the harder it gets.

If I pick one site which actually seems to work (I'll be hanged for this but 
that's ok :-)  when it comes to font sizes and a general layout then it's 
freshmeat. Mac, PC, Linux, different browsers and versions - it works! 
Sourceforge isn't nearly as good as freshmeat in my opinion.

So what's the magic?
They use <small>, <font size="+1">, <h2>, <b>, <table...> and a few other 
tags. I have investigated at least a couple of typical pages.

So start to KISS is probably the summary of the above.

We've been discussing this for a long time and it seems that we get tangled 
into different complex solutions.
I would go for a very simple generic stylesheet and leave the rest to the 
users (admins) of Pt.

I get a feeling that too much effort is put into this work compared to 
everything else that has to be done with Pt 2.

These are of course my opinions and I'm aware that you might not agree.
I know about admins who purposely build their sites not only for IE on 
Windows but also version 5.5 and above because they realized the complexity 
of CSS (there are other reasons too). I don't work in an environment where 
this is allowed (not yet) and I'll never accept it anyway.

We may compare our style sheet discussion to what's still a problem with 
publishing software like Quark, InDesign, PageMaker etc. They are still not 
perfect and have their quirks despite the fact that postscript is well 
defined.

Cheers
Günther

On Friday 01 March 2002 16:37, you 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 style.php.
>
> >>> And what's with all that JavaScript in the HEAD? What's wrong with
> >>> style.php to produce different stylesheets for Mac or PC???????
> >>> <grin>
> >>
> >>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:
> >>
> >>generic.css
> >>ie-4-mac.css
> >>ie-4-pc.css
> >>netscape-4.css
> >>netscape-6.css
> >>
> >>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 into
> >  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 interface.
>
> 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 forms, etc.
>
> 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.
>
> 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.
>
> 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.
>
> thoughts?
>
> Jamie
>
> > Maybe you should send this style stuff back to the list so everyone
> > else  can comment.
> > --
> > Cheers,
> >
> >  d  a  v  e
>
> _______________________________________________
> Pagetool-devel mailing list
> Pagetool-devel@...
> https://lists.sourceforge.net/lists/listinfo/pagetool-devel

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


My continuation of the conversation a lot further down........

>>>>
>>>> And what's with all that JavaScript in the HEAD? What's wrong with
>>>> style.php to produce different stylesheets for Mac or PC???????
>>>> <grin>
>>>
>>>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:
>>>
>>>generic.css
>>>ie-4-mac.css
>>>ie-4-pc.css
>>>netscape-4.css
>>>netscape-6.css
>>>
>>>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 into
>>  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 interface.
>
>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 forms, etc.
>

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>

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

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

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

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


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!

>Jamie
>>
>>
>> Maybe you should send this style stuff back to the list so everyone
>> else  can comment.
>> --

And here it is <grin>
>
>
-- 
Cheers,

  d  a  v  e

Hi G=FCnther,

On Fri, 1 Mar 2002, Gunther Dippe <dippe@...> wrote
>Hi all,
>Stylesheets are supposed to make life simpler :-) but it seems that the mo=
re
>we bury our heads into it the harder it gets.
>
>If I pick one site which actually seems to work (I'll be hanged for this b=
ut
>that's ok :-)  when it comes to font sizes and a general layout then it's
>freshmeat.

Mmmmm, interesting. But see:


<url:http://validator.w3.org/check?uri=3Dhttp%3A%2F%2Ffreshmeat.net%2F&char
set=3D%28detect+automatically%29&doctype=3DInline&ss=3D&sp=3D&outline=3D>

The above is a VERY big download, just in case you're on dialup!

> Mac, PC, Linux, different browsers and versions - it works!

And the freshmeat home page is 130KB in size, just for the html. Just=20
the text that's visible, the actual content is only 33KB!!

>
>Sourceforge isn't nearly as good as freshmeat in my opinion.
>
>So what's the magic?
>They use <small>, <font size=3D"+1">, <h2>, <b>, <table...> and a few other
>tags. I have investigated at least a couple of typical pages.
>
>So start to KISS is probably the summary of the above.
>

I'd definitely agree with KISS, but the problem we are trying to solve=20
is anything but S!

>We've been discussing this for a long time and it seems that we get tangled
>into different complex solutions.
>I would go for a very simple generic stylesheet and leave the rest to the
>users (admins) of Pt.
>

But that doesn't give the admins the option of doing something,=20
something that is currently complicated and very time consuming, it=20
doesn't give them a better way of solving the difficult problem. The=20
admin doesn't have to use the Pagetool style sheet at all (maybe it=20
could be a plugin?) as the MJ designer doesn't, or we could hold their=20
hand a bit, and maybe show them a new, more powerful, maybe easier (once=20
you get your head around it), way to do things.

>I get a feeling that too much effort is put into this work compared to
>everything else that has to be done with Pt 2.
>

Pt2 is currently not much more than a load of vague ideas and concepts=20
in our heads. (Except for Jamies' initial files of course) These=20
discussions do help to focus and solidify the thought process. Better to=20
discuss these things now than spend hours coding and then find it isn't=20
all going to work. I've found it interesting at some of the questions=20
users have asked, can pagetool do this, can it do that. If we can think=20
of ways that Pagetool can do this and can do that then it is providing a=20
solution.

>These are of course my opinions and I'm aware that you might not agree.

:-) It would be a VERY boring world if we all agreed all the time.

>I know about admins who purposely build their sites not only for IE on
>Windows but also version 5.5 and above because they realized the complexity
>of CSS (there are other reasons too).

I don't quite understand that paragraph. I _think_ you mean they ONLY=20
design for IE5.5up on Win and everyone else be dammed. Yes?

> I don't work in an environment where
>this is allowed (not yet) and I'll never accept it anyway.
>


Viewable via ANY browser on ANY platform and via ANY bandwidth. Yep,=20
agree with all that.

>We may compare our style sheet discussion to what's still a problem with
>publishing software like Quark, InDesign, PageMaker etc. They are still not
>perfect and have their quirks despite the fact that postscript is well
>defined.
>

As is HTML4.01, CSS1, CSS2, and now XHTML1.0 And look at the mess=20
Frontpage or Dreamweaver can make of them!

Mmmm, it's a big problem, and if the might of MS and Macromedia can't=20
get it right, what hope have we? <grin>

Lot's of hope, I say!

<snipped original>

--=20
Cheers,

  d  a  v  e

> 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
>>style.php.
>>
>
>
> My continuation of the conversation a lot further down........
>
>>>>>
>>>>> And what's with all that JavaScript in the HEAD? What's wrong with
>>>>> style.php to produce different stylesheets for Mac or PC???????
>>>>> <grin>
>>>>
>>>>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:
>>>>
>>>>generic.css
>>>>ie-4-mac.css
>>>>ie-4-pc.css
>>>>netscape-4.css
>>>>netscape-6.css
>>>>
>>>>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
>>> into
>>>  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
>>> interface.
>>
>>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
>>forms, etc.
>>
>
> 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
their own.

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

> 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?
Not sure...
>
>>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.
>>
>>thoughts?
>>
>
>
> 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.

Jamie

>>Jamie
>>>
>>>
>>> Maybe you should send this style stuff back to the list so everyone
>>> else  can comment.
>>> --
>
> And here it is <grin>
>>
>>
> --
> Cheers,
>
>  d  a  v  e
>
> _______________________________________________
> Pagetool-devel mailing list
> Pagetool-devel@...
> https://lists.sourceforge.net/lists/listinfo/pagetool-devel

On Fri, 1 Mar 2002, Jamie McClelland <jmcclelland@...> wrote
>> On Fri, 1 Mar 2002, Jamie McClelland <jmcclelland@...> wrote
>>>Hi all - this is a converstation Dave and I were having off list about

the conversation was about styles

<snipped a load of the original>

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


But if you want to change the style of the entire site for all browsers 
then there are loads of files to update, and ensure continuity between 
all the different files as well. I thought one of the advantages of 
database driven sites was the ability to alter data once and have it 
apply across the whole site. Edit the Pagetool header and your whole 
site changes. With multiple files you have to edit each file to alter 
the font size or colour for one style declaration.


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

Actually I  found I wanted to use admin styles in some of the recent 
admin type plugins I've written, specifically the .message style. But 
there is currently no way to access it.



>These style sheets would have the browser variations all
>>

<snipped about one database call per person per day for the stylesheet>

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


Oops, the secrets out!

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


I _still_ haven't studied the code. I _must_ take a much closer look 
soon!

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


But we _could_ allow the plugin to add to the ONE SQL statement. Then 
MySQL does all the work of retrieving the data, which is what it is good 
at. So most of Pagetool is building up that one BIG SQL statement, 
plugins included. The statement is run, and data retrieved and 
configured as required and then spat out to browser via a template.

>> 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?
>Not sure...

I think it's easier to set the cache headers of the page produced.

style.php produces:

HTTP/1.1 200 OK
Date: Sat, 02 Mar 2002 14:40:59 GMT
Server: Apache/1.3.22 (Win32) PHP/4.0.6
X-Powered-By: PHP/4.0.6
Cache-Control: must-revalidate, max-age=86400, s-max-age=86400
Last-modified: Sat, 02 Mar 2002 14:40:59 GMT
Expires: Sun, 03 Mar 2002 14:40:59 GMT
Connection: close
Transfer-Encoding: chunked
Content-Type: text/css

where as index.php produces:

HTTP/1.1 200 OK
Date: Sat, 02 Mar 2002 14:42:18 GMT
Server: Apache/1.3.22 (Win32) PHP/4.0.6
X-Powered-By: PHP/4.0.6
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html


and a standard index.html produces:

HTTP/1.1 200 OK
Date: Sat, 02 Mar 2002 14:47:08 GMT
Server: Apache/1.3.22 (Win32) PHP/4.0.6
Last-Modified: Tue, 13 Feb 2001 20:20:29 GMT
ETag: "0-440-3a89970d"
Accept-Ranges: bytes
Content-Length: 1088
Connection: close
Content-Type: text/html


So the style.php file shouldn't be requested again for 1 day. Similar 
cache header could be set for each Pagetool page, last modified could be 
the last modified time from the database for example. And Expires: could 
be set to a week or three in the future for pages you know aren't going 
to change much, but set to a few minutes for pages that are going to 
change regularly. It's not just the browsers cache that we are talking 
about here, it's also all the ISP caches that are between the user and 
the actual web server. See

http://www.mnot.net/cache_docs/

for loads of info!

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


So maybe there is a standard view of Pagetool config options and then an 
advanced view.


-- 
Cheers,

  d  a  v  e

> On Fri, 1 Mar 2002, Jamie McClelland <jmcclelland@...> wrote
>>> On Fri, 1 Mar 2002, Jamie McClelland <jmcclelland@...> wrote
>>>>Hi all - this is a converstation Dave and I were having off list
>>>>about
>
> the conversation was about styles
>
> <snipped a load of the original>
>
>>>
>>>
>>> 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
>>their own.
>>
>>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.
>>
>
>
> But if you want to change the style of the entire site for all browsers
>  then there are loads of files to update, and ensure continuity between
>  all the different files as well. I thought one of the advantages of
> database driven sites was the ability to alter data once and have it
> apply across the whole site. Edit the Pagetool header and your whole
> site changes. With multiple files you have to edit each file to alter
> the font size or colour for one style declaration.

Ahhh... now this is the crux of the matter. I think we are all in agreement
about the importance of using style sheets (sorry for misinterpreting your
email Gunther!) - even our designer swears by them. The real issue is the
user interface for modifying them. In my opinion, your suggestion is the
best, however, I don't think it is worth the time spent writing the code,
designing the interface, and the additional complexity both for us
developers and for the web site designers, who I suspect may ignore the
code and use their old style sheets (as Michael, our web designer, does
with pagetool 1).

Of course, the beauty of open source is that everyone can codes according
to their own itch. And if you build this and prove me wrong, well it won't
be the first time :-). Currently style.php is completely seperate from the
core code - and with Pagetool 2 we could probably even make it a plugin.
So, even though you haven't convinced me (yet), I look forward to seeing
this idea unfold.

>
>
>>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).
>>
>
> Actually I  found I wanted to use admin styles in some of the recent
> admin type plugins I've written, specifically the .message style. But
> there is currently no way to access it.

yes - a problem with Pagetool 1 that should be solved with Pagetool 2 (am
sounding like a broken record yet?).

>
>
>
>>These style sheets would have the browser variations all
>>>
>
> <snipped about one database call per person per day for the stylesheet>
>
>>
>>>>
>>>>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...
>>
>>>
>
>
> Oops, the secrets out!
>
>>> 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.
>
>
> I _still_ haven't studied the code. I _must_ take a much closer look
> soon!
>
>> 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, etc.
>>
>
>
> But we _could_ allow the plugin to add to the ONE SQL statement. Then
> MySQL does all the work of retrieving the data, which is what it is
> good  at. So most of Pagetool is building up that one BIG SQL
> statement,  plugins included. The statement is run, and data retrieved
> and
> configured as required and then spat out to browser via a template.


Hmmm... I don't think that would work, because the plugin code would be
retrieved from the first sql statement - so the first one would have to be
executed before the plugin code could be evaluated.

>
>>> 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? Not sure...
>
> I think it's easier to set the cache headers of the page produced.
>
> style.php produces:
>
> HTTP/1.1 200 OK
> Date: Sat, 02 Mar 2002 14:40:59 GMT
> Server: Apache/1.3.22 (Win32) PHP/4.0.6
> X-Powered-By: PHP/4.0.6
> Cache-Control: must-revalidate, max-age=86400, s-max-age=86400
> Last-modified: Sat, 02 Mar 2002 14:40:59 GMT
> Expires: Sun, 03 Mar 2002 14:40:59 GMT
> Connection: close
> Transfer-Encoding: chunked
> Content-Type: text/css
>
> where as index.php produces:
>
> HTTP/1.1 200 OK
> Date: Sat, 02 Mar 2002 14:42:18 GMT
> Server: Apache/1.3.22 (Win32) PHP/4.0.6
> X-Powered-By: PHP/4.0.6
> Connection: close
> Transfer-Encoding: chunked
> Content-Type: text/html
>
>
> and a standard index.html produces:
>
> HTTP/1.1 200 OK
> Date: Sat, 02 Mar 2002 14:47:08 GMT
> Server: Apache/1.3.22 (Win32) PHP/4.0.6
> Last-Modified: Tue, 13 Feb 2001 20:20:29 GMT
> ETag: "0-440-3a89970d"
> Accept-Ranges: bytes
> Content-Length: 1088
> Connection: close
> Content-Type: text/html
>
>
> So the style.php file shouldn't be requested again for 1 day. Similar
> cache header could be set for each Pagetool page, last modified could
> be  the last modified time from the database for example. And Expires:
> could  be set to a week or three in the future for pages you know
> aren't going  to change much, but set to a few minutes for pages that
> are going to  change regularly. It's not just the browsers cache that
> we are talking  about here, it's also all the ISP caches that are
> between the user and  the actual web server. See
>
> http://www.mnot.net/cache_docs/
>
> for loads of info!

Wow, you're not kidding. And well written too.

>
>>>
>>>>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.
>>>>
>>>>thoughts?
>>>>
>>>
>>>
>>> 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.
>>
>
>
> So maybe there is a standard view of Pagetool config options and then
> an  advanced view.

Yes!

Jamie
>
>
> --
> Cheers,
>
>  d  a  v  e
>
> _______________________________________________
> Pagetool-devel mailing list
> Pagetool-devel@...
> https://lists.sourceforge.net/lists/listinfo/pagetool-devel

Comments below at ***
>Hi all,
>
>I'm still on my style soap box! <grin>
>
>Have a look at these in various browsers:
>
>http://www.meyerweb.com/

*** terrible in NS 4.7/Mac, good in IE5/Mac, OK Konqueror 2.1/linux, 
OK NS 6.0/Linux but a bit positioning-distorted, the same with Opera 
6/Linux.

>
>and
>
>http://www.meyerweb.com/ui/about.html
>
>You won't even get the link to the second page if your browser does
>understand CSS correctly.
>
>And have a look at:
>
>http://mako4css.com/index.htm

If the conclusion that 96% of all browser are (almost) 100% CSS1 
compliant then I'm convinced. By the time Pt2 is out (in 9-12 
months?) then maybe there are only 1-2% left and that's good enough 
for me.

G=FCnther

>
>A load of good information, as well as good use IMHO of styles.
>
>I would like Pagetool to be able to produce sites such as these. OK in
>the older type browser they don't look quite as nice. But if we assume
>that older browsers are probably on older machines and also therefore on
>a slower connection, OK, OK, a load of assumptions I know, but the older
>browser can get at the content quicker than if the page had loads of
>nested tables and load of font tags. The newer browsers, 90% or so of
>web users apparently, are _almost_ CSS1 compliant, so with careful
>coding a style can be made to look similar across almost all browser but
>the content is available to ALL and with less load on the server due to
>the reduced size of the page.
>
>Jamie should really get his MJ designer in here as well so we can learn
>first hand from a designer (as opposed to us programmers) what his
>objections were and what we could do to make his life easier.
>
>I think I'm all done now. Spent my 2p. I'm going to go back to finishing
>that pt_check_links plugin.......
>
>--
>Cheers,
>
>  d  a  v  e
>
>_______________________________________________
>Pagetool-devel mailing list
>Pagetool-devel@...
>https://lists.sourceforge.net/lists/listinfo/pagetool-devel


-- 
------------------------------------------------------------------
G=FCnther Dippe (dippe@...)
National Center for Mathematics Education, G=F6teborg university, Sweden
NCM homepage: http://ncm.gu.se/
My homepage: http://ncm.gu.se/users/dippe/
------------------------------------------------------------------

Hi all,

I downloaded and tested FAQ-U too :-)
I like it and think it can be a great add-on to Pt.

A while ago I came across a nifty bookmark program.
The feature I really like is that you can create a link in your own toolbar 
and click it whenever you want to bookmark a page you're visiting. It then 
fills in the title and the url for you. You have to decide the category and 
then click add. That's it (it uses javascript though but still think it 
should be at least considered).

http://lbstone.com/apb/?version=1.0.01
I also been in contact with the developers and they responded quickly.
The one feature I miss is building the categories separately from adding the 
bookmarks but at least I can live with that since adding the bookmarks is so 
easy.

Cheers
Günther

On Saturday 02 March 2002 15:07, you wrote:
> Hi all,
>
> I've investigated further the FAQ-U script from
>
> http://codegrunt.com
>
> and I now have a version working locally that Pagetool can wrap around.
> By this I mean that it uses the Pagetool header/sidebar/footer. It does
> NOT have a unified log in with Pagetool.
>
> Should I upload this to http://www.pagetool.org so people can have a look?
> There are still areas that need modified, removing loads of FONT tags
> and replacing with Pagetool SPAN tags mostly, but the basic idea is
> there.
>
> Kory mentioned he would be willing to maintain the FAQ. I can email
> Kory, and anyone else willing to undertake FAQ maintenance, a
> username/password for the FAQ so they can have a look at the admin
> interface. Entry of data could even start, as the underlying database
> structure is not going to change.
>
> I could also make the modified script available as a, er, Pagetool
> Dropin (for want of a better word). Mmm, Plugins and Dropins. Good
> name?? I've also modified ssLinks from
>
> http://www.sslinks.co.uk/
>
> to work in a similar way. This could also be added to the
> http://www.pagetool.org site as the "Sites Using" section. That would allow
> users to add there own sites. And if there is a demand I could also make
> the ssLinks modified script available as another Pagetool Dropin.
>
> Both FAQ-U and ssLinks are GPL so there is no problems with licences as
> long as the original copyright is maintained.
>
> Comments?
> --
> Cheers,
>
>   d  a  v  e
>
> _______________________________________________
> Pagetool-devel mailing list
> Pagetool-devel@...
> https://lists.sourceforge.net/lists/listinfo/pagetool-devel

On Thu, 28 Feb 2002, "Kory Mohr, Frontier Broadband" 
<kory@...> wrote
>For what it's worth, I'd be happy to post a PHP-based FAQ app for Pagetool
>on my site.  Y'all have done so much for Pagetool users that it's the least
>I can do, if you're interested!  :-)
>


That would be great Kory. But I think it would be best if the FAQ was 
part of the http://www.pagetool.org site. If you want to take on the 
administration then that would be great!

There are a load of FAQ scripts at


<url:http://www.hotscripts.com/PHP/Scripts_and_Programs/FAQ_and_Knowledge
base/>

Some of them allow emailing of the entire FAQ as well. A weekly email to 
the pagetool-user list might be an idea! If you want to pick a script, 
that can be made to fit in to the look of http://www.pagetool.org, and we could 
put in on http://www.pagetool.org. Great :-) FAQEngine looked to be about the 
most complete, but may be overkill for what we need. Over to you 
Kory........


-- 
Cheers,

  d  a  v  e

On Thu, 28 Feb 2002, Gunther Dippe <dippe@...> wrote
>FYI:
>http://www.cert.org/advisories/CA-2002-05.html


And from:

http://security.e-matters.de/advisories/012002.html

Please notice, that you are not only vulnerable if you run scripts that=20
use uploaded files. You are vulnerable if you run any script! If you=20
have PHP only installed but there is no script on your server you are=20
not vulnerable.



Mmmmm, hopefully my ISP will now upgrade from 4.0.0!

Thanks for that G=FCnther.
--=20
Cheers,

  d  a  v  e