phpwebsite-developers — For our development team.

Re: [Phpwebsite-developers] Re-writing module for Fallout

[Verdon V. <ve...@ve...>]

I've noticed that none of the modules in fallout CVS use the PHPWS_Item  
or PHPWS_Manager classes. Is there a reason for this? Are they only  
there for backwards compatibility now? I've written modules with  
classes that extend these and modules that don't, depending on my need.  
If I am re-writing (moreso than converting) one of my mods for fallout,  
should I move away from taking advantage of these core classes?

verdon


On 8-Mar-06, at 11:13 AM, Verdon Vaillancourt wrote:

> Thanks Matt,
>
> I'll poke around Blog, and I'm sure I'll be back in touch ;)
> verdon
>
>
> On 8-Mar-06, at 10:53 AM, Matthew McNaney wrote:
>
>> On Wed, 2006-03-08 at 10:42 -0500, Verdon Vaillancourt wrote:
>>
>>> which module would you
>>> recommend for analysing as an example of how to re-write my own?
>>
>> I would look at the Blog module as an example of 'from scratch'. I  
>> tend
>> to use it to test features.
>>
>> As for upgrading an old module, the only one I have done is  
>> Photoalbum,
>> which is what the Converting doc covers.
>>
>> I would glad to offer advice via email or in the chat room.
>>
>> -- Matthew McNaney
>> Electronic Student Services
>> Appalachian State University
>> http://phpwebsite.appstate.edu
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>> language
>> that extends applications into web and mobile media. Attend the live  
>> webcast
>> and join the prime developer group breaking into this new coding  
>> territory!
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Phpwebsite-developers mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the live  
> webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>
>

Re: [Phpwebsite-developers] Re-writing module for Fallout

[Verdon V. <ve...@ve...>]

Thanks Matt,

I'll poke around Blog, and I'm sure I'll be back in touch ;)
verdon


On 8-Mar-06, at 10:53 AM, Matthew McNaney wrote:

> On Wed, 2006-03-08 at 10:42 -0500, Verdon Vaillancourt wrote:
>
>> which module would you
>> recommend for analysing as an example of how to re-write my own?
>
> I would look at the Blog module as an example of 'from scratch'. I tend
> to use it to test features.
>
> As for upgrading an old module, the only one I have done is Photoalbum,
> which is what the Converting doc covers.
>
> I would glad to offer advice via email or in the chat room.
>
> --  
> Matthew McNaney
> Electronic Student Services
> Appalachian State University
> http://phpwebsite.appstate.edu
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the live  
> webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>
>

Re: [Phpwebsite-developers] Re-writing module for Fallout

[Matthew M. <ma...@tu...>]

On Wed, 2006-03-08 at 10:42 -0500, Verdon Vaillancourt wrote:

> which module would you 
> recommend for analysing as an example of how to re-write my own?

I would look at the Blog module as an example of 'from scratch'. I tend
to use it to test features.

As for upgrading an old module, the only one I have done is Photoalbum,
which is what the Converting doc covers.

I would glad to offer advice via email or in the chat room.

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

[Phpwebsite-developers] Re-writing module for Fallout

[Verdon V. <ve...@ve...>]

Hi List,

I'm trying to take a few tentative steps towards converting/re-writing 
my phpwsBusinesses mod for phpws 1.x. I'd really like to have it ready 
in time for the next milestone release. I can't find too much info to 
go on, but /docs/Converting_Modules.txt has provided a few pointers. No 
luck yet, but a starting point :)

I guess my question is, is there any other documentation other than 
what's in the /fallout/docs directory, and which module would you 
recommend for analysing as an example of how to re-write my own? My 
module would like to take advantage of the item class as well as they 
key class and image class. I've taken a quick look through some of the 
included modules and see a somewhat diverse approach. Any idea which 
would be a 'best practices' example.

thanks,
verdon

Re: [Phpwebsite-developers] Layout and theme changes in Fallout

[Verdon V. <ve...@ve...>]

This sounds sensible. I like the box model too :)

In that manner, if I wish, I can id things in my theme.tpl file along  
the lines of leftCol, centerCol, rightCol and can get quite specific in  
my css by using selectors like

#leftCol .box-title h1, #rightCol .box-title h1 {do something}
#centerCol .box-title h1 {do something different}

verdon

On 7-Mar-06, at 10:00 AM, Matthew McNaney wrote:

> Hey,
>
> I have made some style sheet changes for Fallout:
> http://res.stddev.appstate.edu/cvs/fallout/themes/default/
>
> http://res.stddev.appstate.edu/cvs/fallout/themes/default/theme.tpl
> As you can see, there are now style sheet links inside the theme.tpl  
> (as
> I said it would). The {STYLE} tag is still present for module includes.
> These go first to allow theme styles to overwrite them.
>
> You will also notice that the style.css in just an include file. This  
> is
> something that really stuck with me from the training. The theme  
> framing
> is in position, basic holds my font, spacing, borders, etc., and  
> default
> holds my colors. Before this commit, all my work was in just two files.
>
> I ran into one small snag. NakedDisplay in Layout (usually used for
> pop-ups) would use a little header file with your style settings. Since
> those settings were removed, the pop-up blocks were devoid of style. To
> compensate, you can create a "blank.tpl" file in your theme and layout
> will use it instead. If it is not present, layout uses its default
> template.
>
> One more quick discussion. I have been trying to simplify the box model
> but I believe I will have to stick to this format:
>
> <div class="box">
>   <div class="box-title"><h1>Title</h1></div>
>   <div class="box-content">Content here</div>
> </div>
>
> I can't style just the h1 because sometimes modules will insert other
> data in the title bar. Blog, for example, has the author and date in  
> the
> title header. If I controlled the font with box-title alone, those
> entries would inherit the style. If I classed the h1, then I would have
> to create a class for the other elements as well. I also need the
> box-content because there isn't a suitable replacement. I can't use
> p.box-content because the content may have a <p> tag itself.
>
> I think the current box model is a good balance between simplicity and
> control.
>
> Thanks all,
> Matt
>
> --  
> Matthew McNaney
> Electronic Student Services
> Appalachian State University
> http://phpwebsite.appstate.edu
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the live  
> webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>
>

[Phpwebsite-developers] Layout and theme changes in Fallout

[Matthew M. <ma...@tu...>]

Hey,

I have made some style sheet changes for Fallout:
http://res.stddev.appstate.edu/cvs/fallout/themes/default/

http://res.stddev.appstate.edu/cvs/fallout/themes/default/theme.tpl
As you can see, there are now style sheet links inside the theme.tpl (as
I said it would). The {STYLE} tag is still present for module includes.
These go first to allow theme styles to overwrite them.

You will also notice that the style.css in just an include file. This is
something that really stuck with me from the training. The theme framing
is in position, basic holds my font, spacing, borders, etc., and default
holds my colors. Before this commit, all my work was in just two files.

I ran into one small snag. NakedDisplay in Layout (usually used for
pop-ups) would use a little header file with your style settings. Since
those settings were removed, the pop-up blocks were devoid of style. To
compensate, you can create a "blank.tpl" file in your theme and layout
will use it instead. If it is not present, layout uses its default
template.

One more quick discussion. I have been trying to simplify the box model
but I believe I will have to stick to this format:

<div class="box">
  <div class="box-title"><h1>Title</h1></div>
  <div class="box-content">Content here</div>
</div>

I can't style just the h1 because sometimes modules will insert other
data in the title bar. Blog, for example, has the author and date in the
title header. If I controlled the font with box-title alone, those
entries would inherit the style. If I classed the h1, then I would have
to create a class for the other elements as well. I also need the
box-content because there isn't a suitable replacement. I can't use
p.box-content because the content may have a <p> tag itself.

I think the current box model is a good balance between simplicity and
control.

Thanks all,
Matt

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

[Phpwebsite-developers] CSS rework

[Matthew M. <ma...@tu...>]

Hello all,

I attending a css seminar the last two days. I mistakenly assumed I
would walk away with nothing. I was wrong.

Keeping our current discussions in mind and using what I learned, I am
going to assess the current default theme for Fallout. Look for some
changes in CVS.

One major change I am considering is the default content of {STYLE} in
the theme. In previous emails I wrote about the theme.ini file and the
persistent, preferred, and alternate style sheets. You know, there
REALLY isn't a reason to have Layout have to worry about this. Let the
theme developer enter that information. I need to add media style sheets
anyway. This will simplify the theme.ini, prevent some unneeded
processing, and I won't have to worry about media tags. Module style
sheets will still be called in the {STYLE} tag.

I will let y'all know when I commit the changes.

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

[Phpwebsite-developers] Wysiwyg

[Shaun M. <sh...@ae...>]

Just came across this tonight whilst catching up with wysiwyg  
editors. It's the nicest thing I've seen in ages on the net and works  
on all browsers including Safari and Opera 9. So, it's possible...

Demo  -  http://thoth.robrohan.com/editor/index.thx

More details - http://www.robrohan.com/client/index.cfm/2005/12/4/ 
Online-Word-Processor



Shaun
aegis design - http://www.aegisdesign.co.uk
aegis hosting - http://www.aegishosting.co.uk

Re: [Phpwebsite-developers] Fallout Selectors

[Greg M. <drk...@co...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew McNaney wrote:
> On Mon, 2006-02-27 at 23:00 -0700, Greg Morgan wrote:
> 
> Here is a quick definition list.
> 
> align-(center, left, right) :
> 
> bgcolor1-3 : 
> 
> bigger & smaller :
> 
> box, box-title, box-content :

> module styles :
> 
> img.float-left/right :
> no-bullet : 
> phpws_form :
> spoiler : 
> 

Please see below.

>>[theme_variables]
>>0 = LAYOUT_HEADER
>>1 = LAYOUT_FOOTER
>>2 = BOTTOM
>>3 = USERS_LOGIN_BOX
>>4 = NOTES_REMINDER
>>5 = CATEGORIES_ADMIN_MENU
>>6 = SEARCH_SEARCH_BOX
  7 = BODY
  8 = DEFAULT

Will adding these required variables here in the [theme_variables]
section confuse the layout system?

> 
> These values tell Layout what extra content sections you have in your
> theme. 
> Each theme MUST have BODY and DEFAULT. Beyond that, you can create a
> content section just by adding it to the numeric list. If these are not

Is the numeric order in the [theme_variables] section significant?

> put in, you cannot move content around the page and content will not
> anchor properly.
> 

> The theme variables that are prefixes by module names are anchors. The
> first time the above content was created, layout checks to see if it has
> an anchor, if it doesn't, it checks the theme.ini file for a module_name
> + content variable name. If it finds that variable, it places the
> content in that space. If it doesn't, it plops it into the DEFAULT theme
> variable.
> 

http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=En_Layout

Ok so I revised and dumped layout.txt and parts of this discussion into
the page above.  The selector catalog is still located here
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=En_default .
 I dumped my regex's from vim here
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=En_blueballs
. The main_page has also been redesigned
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Main_Page .

Interesting: as I was updating .txt files for the next 0.10.3 release
critical mass was achieved for the 0.9.x theming system.  As noted in
the email that started this thread I started to grep for all the
selectors and "touch" points for module development and theming in
fallout.  At present combining all the roles in the
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=En_Layout
page is a good thing so that the parts can be seen functioning as a
whole.  Here's what I sense so far then. A catalog of each of the
modules available theme variables must be defined.  It sounds like each
module page requires a section covering these variables for theme
designers.  So based on these emails

* LAYOUT module has two
* * HEADER  (LAYOUT_HEADER)
* * FOOTER  (LAYOUT_FOOTER)

* USERS module has one
* * LOGIN_BOX  (USERS_LOGIN_BOX)

* NOTES module has one
* * REMINDER  (NOTES_REMINDER)

* CATEGORIES module has one
* * ADMIN_MENU  (CATEGORIES_ADMIN_MENU)

* SEARCH module has one
* * SEARCH_BOX  (SEARCH_SEARCH_BOX)

* BOTTOM is just there so that phpWebSite has something to hold...well
never mind.

I might grep on 'Layout::add' to locate and catalog the variables?

Likewise, the selector variables, bgcolor1-3, need to be cataloged so
that designers know where to add their color, structure, and fonts to a
theme whereas the the theme variables would allow them to position the
content in the theme.

> This allows people to choose a theme and just have it work without
> having to move boxes afterward. It also gives the theme developer more
> room to style certain components (the menu for example).
> 
> 
> 
>>[persistant_style_sheet]
>>file = style.css
>>
>>[default_style_sheet]
>>file = default.css
>>title = Default Delite
>>
>>[alternate_style_sheet_1]
>>file = blue.css
>>title = Blue
> 
> 
> A persistent style sheet is always loaded. (yes I realize I misspelled
> it now)
> The default style sheet is then loaded.
> The alternate style sheets are loaded should the user want a different

> view. Firefox allows you to do this but if you want the change to
> "stick" you may have to download an extension.

"stick" as in http://www.stickdeath.com/frameset.htm ?  ;-)
I am not familiar with firefox "sticks".  I heard tell that they are
breaking IE's bones.

> 
> For now, I put positioning, font sizes, padding widths, etc. in the
> persistent style sheet. Color choices go into the default and alternate.
> You are not required to use this format, you could just use ONE style
> sheet if you wish. Default uses alternates as an example.

Greg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEBUg+xyxe5L6mr7IRAo+wAJ9fpbQ51WXdrfNVs94nt5Q7tNKa2ACfeHI9
LntrOHzsp62ty51njqBCQsc=
=zhby
-----END PGP SIGNATURE-----

Re: [Phpwebsite-developers] Fallout Selectors

[Shaun M. <sh...@ae...>]

On 28 Feb 2006, at 15:22, Matthew McNaney wrote:
>
> Originally I did that, however I had problems because the content  
> might
> contain the same tags. For example, the css would say
> div.box h3 {}
>
> and that would work fine for the title. However if the {content} had a
> h3 in it as well, I may not want it to use the same style.
> Also with div.box-title I could put background-color, background- 
> image,
> etc. in the div. Headings don't work that well with those type of
> stylings.
>
> The same goes for the content area. I may want to color it and styling
> on the <p> would cause goofiness.
>

Ah, I see. I guess I'm just more minimalist in my stylings.

>
>> The other thing that might be useful is adding insertion of a class
>> for a category into the top of a template so you could have different
>> css depending on the category. At the moment I don't think you can
>> return the category name without it being a link in 0.10.x.
>
> On category listings? Not sure if I get what you are saying.
>


No, I was thinking it would be useful in say pagemaster or announce.  
If you could <div class="{category}">...</div> around the content  
then you'd possibly be able to style the page/announcement to fit in  
with the category and provide a bit of diversity.


>
>> I'd also like to see some standard classes defined for menus (first,
>> last, selected, enabled, disabled etc) although perhaps those should
>> be in menuman and then overridden? And for elements such as dates and
>> bylines which are common across many modules.
>
> Good plan. Indicate where it is needed in code and I can implement.

I'll dig out where I use them but certainly in Announce and Article  
for bylines and almost everywhere a date is it tends to be smalltext.

Shaun
aegis design - http://www.aegisdesign.co.uk
aegis hosting - http://www.aegishosting.co.uk

Re: [Phpwebsite-developers] Fallout Selectors

[Matthew M. <ma...@tu...>]

On Tue, 2006-02-28 at 14:57 +0000, Shaun Murray wrote:

> The boxes are usually then just...
> 
> <div class="box">
>    <h3>{title}</h3>
>    {content}
> </div>

Originally I did that, however I had problems because the content might
contain the same tags. For example, the css would say
div.box h3 {}

and that would work fine for the title. However if the {content} had a
h3 in it as well, I may not want it to use the same style.
Also with div.box-title I could put background-color, background-image,
etc. in the div. Headings don't work that well with those type of
stylings.

The same goes for the content area. I may want to color it and styling
on the <p> would cause goofiness. 

> I do the same for modules too, just adding eg. <div  
> class="announce">...</div> around a template. It'd actually be useful  
> if those were there by default in fallout for me anyway.

Good point. I was doing that, then I started slacking off :P I think it
should be a standard. I'll try to get back in the habit.

> The other thing that might be useful is adding insertion of a class  
> for a category into the top of a template so you could have different  
> css depending on the category. At the moment I don't think you can  
> return the category name without it being a link in 0.10.x.

On category listings? Not sure if I get what you are saying.


> I'd also like to see some standard classes defined for menus (first,  
> last, selected, enabled, disabled etc) although perhaps those should  
> be in menuman and then overridden? And for elements such as dates and  
> bylines which are common across many modules.

Good plan. Indicate where it is needed in code and I can implement.

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

Re: [Phpwebsite-developers] Fallout Selectors

[Shaun M. <sh...@ae...>]

On 28 Feb 2006, at 13:19, Matthew McNaney wrote:
>
> box, box-title, box-content : since box template files have been
> removed, I use these to style the content containers.

I've done that in the past myself with box styles although I tend to  
use descendent selectors instead of additional classes, just to add  
in some semantic structure, and it makes the CSS nicer too.

The boxes are usually then just...

<div class="box">
   <h3>{title}</h3>
   {content}
</div>


I do the same for modules too, just adding eg. <div  
class="announce">...</div> around a template. It'd actually be useful  
if those were there by default in fallout for me anyway.

Saves adding a load of box styles usually.

The other thing that might be useful is adding insertion of a class  
for a category into the top of a template so you could have different  
css depending on the category. At the moment I don't think you can  
return the category name without it being a link in 0.10.x.


I'd also like to see some standard classes defined for menus (first,  
last, selected, enabled, disabled etc) although perhaps those should  
be in menuman and then overridden? And for elements such as dates and  
bylines which are common across many modules.


aegis design - http://www.aegisdesign.co.uk
aegis hosting - http://www.aegishosting.co.uk

Re: [Phpwebsite-developers] Fallout Selectors

[Matthew M. <ma...@tu...>]

On Mon, 2006-02-27 at 23:00 -0700, Greg Morgan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Through the magix of find; grep; vim regex tricks; and sort -u; a list
> of fallout default theme selectors has been created.
> http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=En_default

First of all, nice work. This list will let us decide of what the core
set of styles consist.

Here is a quick definition list.

align-(center, left, right) : a shortcut class to prevent inline styles
and align="left"

bgcolor1-3 : I figured these would be the replacements for bg_light and
such. Setting these three background colors set the colors for the site

bigger & smaller : makes the font bigger and smaller. again an attempt
at preventing inline styles

box, box-title, box-content : since box template files have been
removed, I use these to style the content containers.

module styles : specific styles associated with a module. These could
use a review.

img.float-left/right : again, to prevent inline styles

no-bullet : used in a ul to prevent bullets

phpws_form : id of any generic form made with the form class

spoiler : used in bb code. Hides text until moused over. Used in
comments

Ask about any others.

By the way, when I wrote the alternate style sheet blue, I was testing
it against the default. As a result, once I was sure it worked, I
stopped changing over the values. That is why blue still has some brown
in it.

> Moreover, what shall I make out of the theme.ini file?
> 
> [theme_variables]
> 0 = LAYOUT_HEADER
> 1 = LAYOUT_FOOTER
> 2 = BOTTOM
> 3 = USERS_LOGIN_BOX
> 4 = NOTES_REMINDER
> 5 = CATEGORIES_ADMIN_MENU
> 6 = SEARCH_SEARCH_BOX

These values tell Layout what extra content sections you have in your
theme. 
Each theme MUST have BODY and DEFAULT. Beyond that, you can create a
content section just by adding it to the numeric list. If these are not
put in, you cannot move content around the page and content will not
anchor properly.

BOTTOM is just a generic content area. The others are module specific.
In phpwebsite 0.10.x you use the $GLOBALS['content_var'] variable. In
Fallout, you just call a Layout function:
Layout::add('Some content');

If called like so, the content is appended to the BODY area. If however
you do this:
Layout::add('Some content', 'search', 'search_box');

it lets Layout know you want to have a movable element.

The theme variables that are prefixes by module names are anchors. The
first time the above content was created, layout checks to see if it has
an anchor, if it doesn't, it checks the theme.ini file for a module_name
+ content variable name. If it finds that variable, it places the
content in that space. If it doesn't, it plops it into the DEFAULT theme
variable.

This allows people to choose a theme and just have it work without
having to move boxes afterward. It also gives the theme developer more
room to style certain components (the menu for example).


> [persistant_style_sheet]
> file = style.css
> 
> [default_style_sheet]
> file = default.css
> title = Default Delite
> 
> [alternate_style_sheet_1]
> file = blue.css
> title = Blue

A persistent style sheet is always loaded. (yes I realize I misspelled
it now)
The default style sheet is then loaded.
The alternate style sheets are loaded should the user want a different
view. Firefox allows you to do this but if you want the change to
"stick" you may have to download an extension.

For now, I put positioning, font sizes, padding widths, etc. in the
persistent style sheet. Color choices go into the default and alternate.
You are not required to use this format, you could just use ONE style
sheet if you wish. Default uses alternates as an example.

Thanks Greg,
Matt

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

[Phpwebsite-developers] Fallout Selectors

[Greg M. <drk...@co...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Through the magix of find; grep; vim regex tricks; and sort -u; a list
of fallout default theme selectors has been created.
http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=En_default
What is the best way to get my arms around what each one is designed to
do?  Some selectors like toggle1 and toggle2 produce documentation hits
in various files.  Other selectors produce nothing.

Moreover, what shall I make out of the theme.ini file?

[theme_variables]
0 = LAYOUT_HEADER
1 = LAYOUT_FOOTER
2 = BOTTOM
3 = USERS_LOGIN_BOX
4 = NOTES_REMINDER
5 = CATEGORIES_ADMIN_MENU
6 = SEARCH_SEARCH_BOX

[persistant_style_sheet]
file = style.css

[default_style_sheet]
file = default.css
title = Default Delite

[alternate_style_sheet_1]
file = blue.css
title = Blue

Greg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEA+cQxyxe5L6mr7IRAq58AJ47yMwkM6SZZdI6LKFd883kE5pfagCfS4v3
WVkyeU30nDx4im2Cqn5suE8=
=Ex6U
-----END PGP SIGNATURE-----

[Phpwebsite-developers] Re: phpWebSite face lift

[<po...@mi...>]

> > We're pretty inconsistent with using th for table headers. I've been
> > generally putting them in where I can and losing the bold tags. In
> > theory we could lose the class=3D"bg_medium" and style the th more =
but
> > that will break compatibility.
>=20
> Agreed. I would like to get rid of redundancy.
I agree as well. I was just about to make such a change to 0.10.3, but I
think we need to decide how radical a change we want to make with the
current release, compared to Fallout.


> > Actually, I'm kind of leaning towards some breaks if we can =
introduce
> > semantic consistent layout.
>=20
> The question: is it too far in the game to do this? My feeling was =
that
> with Fallout we have an 'excuse' to break things. With 0.10.x, it may =
be
> view unfavorably.
I would like to take the opportunity to give you an idea of my plans =
with
the changes I have made so far. For 0.10.3 I will continue to implement =
the
consistent design I have already started. I don=92t know how many =
modules I
can change before the release candidate, but I'll try to get as far as
possible.

Once 0.10.3 is out, I think we should consider the possibility of going
further with this work. I my opinion it is not only a matter of adding =
new
styles. Some modules could benefit for a more user-friendly workflow. I
would suggest that we take one module at a time, and look closer into =
how we
can change the interface as well as the flow between input forms. I have
already started to make some prototypes, and if we can agree on the =
changes,
then we need to decide how we should go further with the changes. It =
would
involve some coding and I would no doubt need a lot of help. I would =
like to
stress out, that I have no plans for adding new features, and =
introducing
changes to the database layout. It is only a matter of how the workflow =
is
organised and how the different pages communicate with each other.

- Michael (TechElephant)

[Phpwebsite-developers] Re: phpWebSite face lift

[<po...@mi...>]

> I prefer the left / right approach. I know some people prefer title top
> and form bottom. Unfortunately, the table format makes the former easier
> and the latter almost impossible.
I agree 100% on this. But then again, it is a matter of taste. I'm open for
any suggestions so if the majority decides to go for the title top and form
bottom, then I'll change the design asap. My goal right now is to stick with
one design standard and implement it across all of the current 0.10.x
modules. That would give the consistent design that I would really like to
see in 0.10.x.


> We'll see how it pans out. I see from where both Shaun and Michael are
> coming. Shaun wants to ensure backward compatibility. Michael wants
> consistent form. You are both right. There is a balance between pleasing
> and annoying the user after an update. Ensure that balance tips towards
> the positive.
Once again I agree 100%. I think you will see that I try not to make any
radical changes when it comes to new styles. The one I have added so far is
optional. Developers shouldn't see any differences in the new layout,
besides forms changing to the grid layout. The old styles are still used,
and themes should work unchanged when 0.10.3 is released. Once I have added
the new classes to all of the lists and input forms it would add the
possibility of doing a more powerful styling.
 

> I don't suggest inline style but phpwebsite 0.10.x is kinda weak in this
> regard. You can't be sure people will adopt new classes in their style
> sheets and you don't want their view to radically change.
If you look at the changes I have made so far, the only inline styles I have
added is mainly replacements of html attributes. I have made this decision
because I like inline styles in preference of attributes, but then again, I
think it is a matter of taste. If anyone has some technical reasons why we
should stick with attributes then please let me know. Replacing the inline
styles with new classes would cause everyone to adapt them in the current
themes, and that would deviate from my intention of not making a radical
change to 0.10.x.


> Something I would like as a result of this discussion is a consensus of
> what Fallout should contain. I want a set of persistent styles that
> developers can count on. Like Michael mentioned, I would like to see
> Fallout ship with a theme set that can be edited some what like the
> ZenGarden site.
For me it is very important to remember, that Fallout is in the pipeline. If
0.10.x was the code base we should continue to work on, then I would have
done a great amount of work trying to convince everybody to give the design
an extensive face lift. But Fallout is soon to be a reality (did you get
this Matt?), and I hope that everyone agrees, that this is where we have the
change to set a new standard for the user interface and how it is going to
be styled.

- Michael (TechElephant)

Re: [Phpwebsite-developers] Re: phpWebSite face lift

[Shaun M. <sh...@ae...>]

On 27 Feb 2006, at 16:08, Matthew McNaney wrote:
>
> The question: is it too far in the game to do this? My feeling was  
> that
> with Fallout we have an 'excuse' to break things. With 0.10.x, it  
> may be
> view unfavorably.
>

ok. No breaking things until fallout. ;-)



Shaun
aegis design - http://www.aegisdesign.co.uk
aegis hosting - http://www.aegishosting.co.uk

Re: [Phpwebsite-developers] Testing Safari compatibility without a Mac

[Shaun M. <sh...@ae...>]

On 27 Feb 2006, at 15:40, Verdon Vaillancourt wrote:

> You know what Mr. T would say...

I ain't gettin' on no plane fool?


Shaun
aegis design - http://www.aegisdesign.co.uk
aegis hosting - http://www.aegishosting.co.uk

Re: [Phpwebsite-developers] Re: phpWebSite face lift

[Verdon V. <ve...@ve...>]

On 27-Feb-06, at 11:08 AM, Matthew McNaney wrote:

>> Actually, I'm kind of leaning towards some breaks if we can introduce
>> semantic consistent layout.
>
> The question: is it too far in the game to do this? My feeling was that
> with Fallout we have an 'excuse' to break things. With 0.10.x, it may 
> be
> view unfavorably.
>
> Thanks Shaun,
> Matt
>
I would agree with this :)
verdon

Re: [Phpwebsite-developers] Testing Safari compatibility without a Mac

[Matthew M. <ma...@tu...>]

Wonderful, thank you.

We would like to get Macs in our department but... *sigh*

On Mon, 2006-02-27 at 15:17 +0000, Shaun Murray wrote:
> For those mad, poor, misguided developers that don't have a Mac but  
> need to test Safari layout issues...
> 
> http://www.snugtech.com/safaritest/
> 
> Type in a URL for the page to test and it gives you a screenshot of  
> the page as it would appear with Safari.
> 
> 
> 
> Shaun
> aegis design - http://www.aegisdesign.co.uk
> aegis hosting - http://www.aegishosting.co.uk
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

Re: [Phpwebsite-developers] Re: phpWebSite face lift

[Matthew M. <ma...@tu...>]

On Mon, 2006-02-27 at 13:42 +0000, Shaun Murray wrote:
> If you're using a table though, why not use th and td as the label  
> and value pair?

Well I use 'th' for column headings but not in rows:

  th  |  th
-------------
  td  |  td

but not

  th  |  td 
-------------
  th  |  td

If we decide that 'th' can take the place of label in form table, I'm
fine with it. You could do this though:
<div class="form-table">
<span class="label>Name</span><span>{INPUT}</span>
</div>

> We're pretty inconsistent with using th for table headers. I've been  
> generally putting them in where I can and losing the bold tags. In  
> theory we could lose the class="bg_medium" and style the th more but  
> that will break compatibility.

Agreed. I would like to get rid of redundancy.


> There's also the semantically correct way of using label and fieldset  
> but that's possibly an issue with some old browsers still. See http:// 
> www.themaninblue.com/writing/perspective/2004/03/24/

The form class in Fallout does that automatically. See the setLabel
function.


> Actually, I'm kind of leaning towards some breaks if we can introduce  
> semantic consistent layout.

The question: is it too far in the game to do this? My feeling was that
with Fallout we have an 'excuse' to break things. With 0.10.x, it may be
view unfavorably.

Thanks Shaun,
Matt

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

Re: [Phpwebsite-developers] Testing Safari compatibility without a Mac

[Verdon V. <ve...@ve...>]

You know what Mr. T would say...

;-) verdon


On 27-Feb-06, at 10:17 AM, Shaun Murray wrote:

> For those mad, poor, misguided developers that don't have a Mac but  
> need to test Safari layout issues...
>
> http://www.snugtech.com/safaritest/
>
> Type in a URL for the page to test and it gives you a screenshot of  
> the page as it would appear with Safari.
>
>
>
> Shaun
> aegis design - http://www.aegisdesign.co.uk
> aegis hosting - http://www.aegishosting.co.uk
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the live  
> webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>
>

[Phpwebsite-developers] Testing Safari compatibility without a Mac

[Shaun M. <sh...@ae...>]

For those mad, poor, misguided developers that don't have a Mac but  
need to test Safari layout issues...

http://www.snugtech.com/safaritest/

Type in a URL for the page to test and it gives you a screenshot of  
the page as it would appear with Safari.



Shaun
aegis design - http://www.aegisdesign.co.uk
aegis hosting - http://www.aegishosting.co.uk

Re: [Phpwebsite-developers] Re: phpWebSite face lift

[Shaun M. <sh...@ae...>]

On 27 Feb 2006, at 13:21, Matthew McNaney wrote:

> On Mon, 2006-02-27 at 09:36 +0100, Michael H. Rasmussen wrote:
>> Too much to copy :)
>
> Table forms:
> I do this as well. In Fallout there is a class called form-table. The
> labels for the form elements are class="label".

If you're using a table though, why not use th and td as the label  
and value pair?

We're pretty inconsistent with using th for table headers. I've been  
generally putting them in where I can and losing the bold tags. In  
theory we could lose the class="bg_medium" and style the th more but  
that will break compatibility.

>
> I prefer the left / right approach. I know some people prefer title  
> top
> and form bottom. Unfortunately, the table format makes the former  
> easier
> and the latter almost impossible.
>

True. Although I quite like definition lists for this purpose where  
the form is a pair of label/value. It falls apart when you've got  
something like menuman though. See http://www.clagnut.com/blog/241/

There's also the semantically correct way of using label and fieldset  
but that's possibly an issue with some old browsers still. See http:// 
www.themaninblue.com/writing/perspective/2004/03/24/


> We'll see how it pans out. I see from where both Shaun and Michael are
> coming. Shaun wants to ensure backward compatibility. Michael wants
> consistent form. You are both right. There is a balance between  
> pleasing
> and annoying the user after an update. Ensure that balance tips  
> towards
> the positive.
>

Actually, I'm kind of leaning towards some breaks if we can introduce  
semantic consistent layout.


> I don't suggest inline style but phpwebsite 0.10.x is kinda weak in  
> this
> regard. You can't be sure people will adopt new classes in their style
> sheets and you don't want their view to radically change.

I think we might get away with some visual breakage if we have a  
defined set of classes we use that people can quickly fix. It'd be a  
pity not to at this point.

>
> Something I would like as a result of this discussion is a  
> consensus of
> what Fallout should contain. I want a set of persistent styles that
> developers can count on. Like Michael mentioned, I would like to see
> Fallout ship with a theme set that can be edited some what like the
> ZenGarden site.
>

 From the other side, trying to get consistent element building into  
the code would also be useful going ahead. We can identify where we  
have problems applying a consistent look now because of module  
developers inconsistent UI design. And hopefully functions can be put  
in place to build things like menus, forms and lists so that module  
developers don't have to reinvent.


Shaun
aegis design - http://www.aegisdesign.co.uk
aegis hosting - http://www.aegishosting.co.uk

Re: [Phpwebsite-developers] Re: phpWebSite face lift

[Matthew M. <ma...@tu...>]

On Mon, 2006-02-27 at 09:36 +0100, Michael H. Rasmussen wrote:
> Too much to copy :)

Table forms:
I do this as well. In Fallout there is a class called form-table. The
labels for the form elements are class="label".

I prefer the left / right approach. I know some people prefer title top
and form bottom. Unfortunately, the table format makes the former easier
and the latter almost impossible.

We'll see how it pans out. I see from where both Shaun and Michael are
coming. Shaun wants to ensure backward compatibility. Michael wants
consistent form. You are both right. There is a balance between pleasing
and annoying the user after an update. Ensure that balance tips towards
the positive.

I don't suggest inline style but phpwebsite 0.10.x is kinda weak in this
regard. You can't be sure people will adopt new classes in their style
sheets and you don't want their view to radically change.

Something I would like as a result of this discussion is a consensus of
what Fallout should contain. I want a set of persistent styles that
developers can count on. Like Michael mentioned, I would like to see
Fallout ship with a theme set that can be edited some what like the
ZenGarden site.

Thanks for everyone's hard work,
Matt

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu