Lunch time

I'm trying to add a "Lunch time" (13:00 to 14:30 every day from Jan 1st 
to Dec 31st over all rooms/resources) to our schedule in mrbs and it 
says "The selected options will create too many entries". Is there a way 
to define this kind of  booking?

Agustin

Re: Color bands in the day view

Hi,

> I was wondering if we could change the 'tdcell' function to accept a
> colour in hex format, such as #FFFFFF, so the user can specify a colour
> other than those in the colour codes?

I thought about this too, but I don't think it's the right way to go.
All style settings must be defined in the style sheet.

For an mrbs administrator, editing a color setting in mrbs.css instead of config.inc.php makes little difference.

But technically this opens many possibilities, like user-defined "skins", or support for PDAs.

Let's just give more meaningful names to the classes than just "A" to "J"...

----

Which means that the right design for the alternating stripes would be:
- Remove the $stripe_color setting I put in config.inc.php.
- Define 2 classes "even_rows" and "odd_rows".
- Define their colors in mrbs.css, by default both white (Unless there's a consensus for a light grey for odd rows?)
- Update day.php to pass the above two classes alternatively to tdcell().

What do you think about this?

Jean-François

----- Original Message ----- 
From: "Gavin Walker" <gavinw <at> thewalkerfamily.me.uk>
To: "Jean-Francois LARVOIRE" <jf.larvoire <at> free.fr>

Re: Color bands in the day view

Yes it would be good to define all the colors etc in the style sheet.

I previously tried to modify the colours via the style sheet, but
discovered that some colour definitions are made directly in the PHP/HTML
files, which makes it that much harder to upgrade to a new version of
MRBS, if you've made mods.

I think a goal to strive for is to make maintenance of the system as easy
as possible, both from a devloper point of view and an administrator point
of view. 

How about this:

* Define variable in the config.inc.php file for all style settings (eg
colours and fonts used throughout the system). This would include the
$color_odd_rows and $color_even_rows variables and the like as well as the
color definitions of the system overall (backgrounds, text colours,
links).

* Use those variable in the CSS file as well as in the PHP files where
colors need to be specified directly into the HTML

The result would be full use of the CSS (good for developers) but also all
the actual color definitions are in the user-editable config.inc.php file.

David.
--- Jean-Francois LARVOIRE <jf.larvoire <at> free.fr> wrote:
> I thought about this too, but I don't think it's the right way to go.
> All style settings must be defined in the style sheet.

School Setup help

Re: Color bands in the day view

There is a problem with this approach: The CSS file is not included on the
server side, but on the client side.

For the PHP variables to work in the style sheet, we'd have to rename it as
mrbs.css.php, and include config.inc.php inside it. I'm not sure of all the
consequences...

Jean-François

----- Original Message ----- 
From: "David Watts" <davidwwatts <at> yahoo.com>
To: "Jean-Francois LARVOIRE" <jf.larvoire <at> free.fr>; "MRBS"
<mrbs-general <at> lists.sourceforge.net>
Sent: Sunday, February 01, 2004 1:40 PM
Subject: Re: [MRBS-general] Color bands in the day view

> Yes it would be good to define all the colors etc in the style sheet.
>
> I previously tried to modify the colours via the style sheet, but
> discovered that some colour definitions are made directly in the PHP/HTML
> files, which makes it that much harder to upgrade to a new version of
> MRBS, if you've made mods.
>
> I think a goal to strive for is to make maintenance of the system as easy
> as possible, both from a devloper point of view and an administrator point
> of view.
>
> How about this:
>
> * Define variable in the config.inc.php file for all style settings (eg
> colours and fonts used throughout the system). This would include the
> $color_odd_rows and $color_even_rows variables and the like as well as the
> color definitions of the system overall (backgrounds, text colours,
> links).
>
> * Use those variable in the CSS file as well as in the PHP files where
> colors need to be specified directly into the HTML
>
> The result would be full use of the CSS (good for developers) but also all
> the actual color definitions are in the user-editable config.inc.php file.
>
> David.
> --- Jean-Francois LARVOIRE <jf.larvoire <at> free.fr> wrote:
> > I thought about this too, but I don't think it's the right way to go.
> > All style settings must be defined in the style sheet.
>
> > ----
> >
> > Which means that the right design for the alternating stripes would be:
> > - Remove the $stripe_color setting I put in config.inc.php.
> > - Define 2 classes "even_rows" and "odd_rows".
> > - Define their colors in mrbs.css, by default both white (Unless there's
> > a consensus for a light grey for odd rows?)
> > - Update day.php to pass the above two classes alternatively to
> > tdcell().
> >
> > What do you think about this?
>
>

Re: Color bands in the day view

On Sun, 2004-02-01 at 10:18, Jean-Francois LARVOIRE wrote:
> Hi,
> 
> > I was wondering if we could change the 'tdcell' function to accept a
> > colour in hex format, such as #FFFFFF, so the user can specify a colour
> > other than those in the colour codes?
> 
> I thought about this too, but I don't think it's the right way to go.
> All style settings must be defined in the style sheet.
> 
Agreed

> Let's just give more meaningful names to the classes than just "A" to "J"...
> 
Agreed, but perhaps instead of removing A to J, add additional colour
classes.  A to J are used to colour the booking reservations and act as
the key to the booking types.

> ----
> 
> Which means that the right design for the alternating stripes would be:
> - Remove the $stripe_color setting I put in config.inc.php.
> - Define 2 classes "even_rows" and "odd_rows".
> - Define their colors in mrbs.css, by default both white (Unless there's a consensus for a light grey for
odd rows?)
> - Update day.php to pass the above two classes alternatively to tdcell().
> 
> What do you think about this?

This is the way that I did it, so I would have to agree.  I also added
the code to week.php.  I would suggest leaving the defaults of both as
white.

Gavin

Re: Color bands in the day view

On Sun, 2004-02-01 at 12:40, David Watts wrote:
> Yes it would be good to define all the colors etc in the style sheet.
> 
> I previously tried to modify the colours via the style sheet, but
> discovered that some colour definitions are made directly in the PHP/HTML
> files, which makes it that much harder to upgrade to a new version of
> MRBS, if you've made mods.
> 
> I think a goal to strive for is to make maintenance of the system as easy
> as possible, both from a devloper point of view and an administrator point
> of view.

There is actually an open task to do this but it has not been worked on
yet - there have been other things to fix.

And yes, ease of administration and an easy means to upgrade have got to
be any projects goals or you get annoyed users or no users.

> 
> How about this:
> 
> * Define variable in the config.inc.php file for all style settings (eg
> colours and fonts used throughout the system). This would include the
> $color_odd_rows and $color_even_rows variables and the like as well as the
> color definitions of the system overall (backgrounds, text colours,
> links).
> 
> * Use those variable in the CSS file as well as in the PHP files where
> colors need to be specified directly into the HTML
> 

Unfortunately, as far as I know you can't use variables directly in a
CSS file as it will not be processed by the server.  So the code would
have to write the stylesheet data into the 'head' of each page as it
gets generated.  This shouldn't be a large processing overhead, though
it will increase the page size.

I think that this is worth pursuing but it will take time to implement
completely.

Also, as with javascript, support for CSS is browser dependent so simple
stylesheets which set colours seem to work okay.  If somebody wants to
significantly alter the interface (I understand that complete page
layout can be accomplished with CSS) then I thing that this should be
done using templates of the web pages.  The latter also allows for
"skins" and easy integration into a pre-existing web site's page layout.

Any comments?

Regards

Gavin

Re: javascript - requirement or not?

I have been pondering this issue and if you think about how the major
companies handle forms then this is generally on the server-side as,
presumably, this gives them greater flexibility and they get away from
the issues of which browser is being used.

I wonder if there is a sort of compromise situation with this, I realise
that this will mean some rewriting of the code but ...

1) Do all data entry checking on the server-side
   - then there is no chance of incorrect data because of badly
     behaved javascript
   - for example the only checking for the "Brief Description" in the
     Add/Edit page is using javascript

2) Do all action verification on the server-side
   - e.g. need to ensure deletion of entries is confirmed, currently
     without javascript it is not, however some other actions are.

3) Add an $enable_javascript variable to enable UI enhancements
   implemented in javascript, such as the proposal to highlight times
   on the day and week views.

4) All javascript should comply with the latest standards, i.e. be
supported by Mozilla and not necessarily backward compatible.
   - this will reduce the need to check every combination of browser
     and OS.
   - if possible this code should not break things for people using
     older browsers

This might give us the best of both worlds.  It gives us functionality
with or without javascript enabled and if it is enabled then the user
experience is enhanced.

Netscape 4 is on the decline, although it is still the standard for the
company I work for.  I recently had a discussion with a web author and
he said that the concesses these days is to go for standards compliance
and not worry about the older browser.  I don't thing that this is what
we would want to do with MRBS when we can still support the older
browser by moving to more server-side code.

Any comments?

Regards

Gavin

-----
From: Thierry B. <thierrybo <at> fr...> 
  Re: javascript - requirement or not?   
2004-01-31 14:20 

 Recently I said I like javascript because it is well suited for user
inputs
 control and light display handling, and the unnecessary need to have a
 round-trip between server and client. This is true if you control
client and
 server (ie. Intranet with same browser for all client).
 But for an open project like mrbs with many clients, I wonder if we
should
 not handle all this on the server side as said Gavin some days ago, and
 discard Javascript.
 -- 

Re: School Setup help

John

I have commited code to the project's cvs repository with instructions
for the use of "periods" in the INSTALL file.  There is not yet a file
release containing the code.

You can see a demo at
http://www.thewalkers.uklinux.net/mrbs/

I am not sure how many people have used it yet so there may still be
issues with it that my testing has not picked up.

If you decide to use it then please let me know how you get on.

Regards

Gavin.

On Sun, 2004-02-01 at 13:47, John Murf wrote:
> I've noticed a few posts about using mrbs for a school period based
> booking system but by not paying attention, I've managed to lose track
> of the plot! Nothing new there. Can someone remind me ........
>  
>  
> Is there a working system for this or is it still in prototype?
>  
> Can I download the code or is based on modifying the "standard" mbrs?
>  
> Are there any instructions specific to the school system and if so
> where are they?
>  
> Thanks in advance 
>  
> John Murphy
>  

Period data conversion

Hi

I have had a query from somebody who I believe is using the code that
Andy Morris has published to the list and who now wants to use the code
that I have commited for supporting periods.

There is a fundamental difference between the two ways of implementing
periods.  I use minutes between 12 noon and 1pm and the code that Andy
mailed out uses hours.

** The question to MRBS adminisrators is - Is there a need for me to try
to create code to convert from one system to the other?

Regards

Gavin.