Re: [Phpgroupware-developers] HEAD/18 proposals/issues

[Dave Hall]

On Mon, 2006-02-20 at 13:43 -0600, Chris Weiss wrote:
> On 2/20/06, Dave Hall <address@hidden> wrote:
> >
> > * Removing upgrade scripts for pre 0.9.14.000, so if someone is running
> > 0.9.12 (released back in July 2001) they will first need to upgrade to
> > 0.9.14 (released November 2002).  This means we can remove some if
> > statements from the setup scripts.  I think if people haven't upgraded
> > in over 3 years they never will.
> 
> is this going to fix some issues or create them?  a handfull of if's
> is not realy a big deal.  a buttload of if's isn't that big a deal
> either.  Our setup program does not have a performance problem, except
> when trying to transcode really huge amounts of contacts from the
> older one and that's all in one if anyway.
> 

460 lines (or over 25%) of unneeded code from
phpgwapi/inc/tables_update.inc.php

I am sure some of the apps are in a similar situation.

There is also a lot of older stuff like:

if($GLOBALS['phpgw_setup']->alessthanb($setup_info['phpgwapi']['currentver'], 
'0.9.10pre7'))
        {
                $configtbl = 'config';
        }
        else
        {
                $configtbl = 'phpgw_config';
        }

which imho just reduces readability for no gain.  Stuff like this can be
removed if we decide on a reasonable base version for upgrades.  No one
expects to be able to have a seemless upgrade from Win 3.0 -> Vista.

> > * Removing tables, XHTML1.0, CSS2.  We are offering a groupware suite
> > not a restaurant, tables are for tabular data not layout.  Let keep the
> > markup clean and descriptive.  The CSS should control the layout.
> 
> remove tables, use css no problems there, all good stuff.
> I read something, forget exactly where, on how to choose the markup
> version for your project.  for XHTML it said something to effect of
> "unless you know why you want XHTML, you probably don't want it". 
> that's said, I don't know why *I* would want XHTML, I don't use XML
> tools to develop, i'm not interested in extending the markup language,
> I don't see the benifit, and the harm is evident from the hundreds fo
> sites claiming XHTML that are not compliant.
> 

I think you are referring to http://hixie.ch/advocacy/xhtml

The main reason is that we are transitioning to xml, xslt and so xhtml
output is a lot easier.  Yes IE7 won't support application/xml+xhtml
(along with some other important things), but we can work around that.  

I am not saying cos it is XML derived it must be the best thing since
gopher.  If we deal with the potential issues caused by using it will
make life a lot easier.  Currently we have tag soup from 2.0 through to
xhtml 1.0 trans.  Lets standardise on one of them.  IMHO the most future
proof of the list is xhtml 1.0 (personally i would opt for Strict, but i
will cop trans).

> > * Requiring a "modern browser" for some functionality.  It is already
> > the case that some parts of phpgw already rely on js being active.  I
> > think given we are in the 2nd half of the 1st decade of the 3rd
> > millennium that we can require JS.  All modern browsers allow
> > enabling/disabling it on a per domain basis.  Yes some people will using
> > NetFront/Opera [mobile/mini]/miniMo/lynx etc and they will get limited
> > functionality.  We should offer a simple almost text mode template for
> > these users, but they may not get 100% of the functionality.  When sync
> > is working smartphones can access the PIM apps via their native apps.
> 
> phpgw currently doesn't work in netfront and even mobile IE with
> pretty templates, but does work in whatever Opera they shoehorned into
> the Nokia 770, even gmail works on it :).  So, I don't see a
> difference here.
> 

http://europe.nokia.com/nokia/0,,75023,00.html Opera 8 :)

Send me your N770 and i will make sure HEAD runs perfectly on it ;)

> 
> > * Unicode everything should be unicode.  It makes life a lot easier.
> > PHP5.1 is also completely unicode safe.
> 
> but older php's are not.  Since most of our displayable content does
> not lie in php files this shouldn't really matter.

there are rare issues with php 4.[3-4].x and unicode, but we can deal
with those as we find them.  Having everything stored as utf8 will make
everyone's life a lot easier imho.

I plan to convert the en lang files shortly unless gugux objects.

Cheers

Dave
-- 
Dave Hall (aka skwashd)
API Coordinator
phpGroupWare
+-------------------------------------+-------------------------------+
| e address@hidden          | w phpgroupware.org            |
| j address@hidden                 | aim skwashd                   |
| icq 278064022                       | msn address@hidden       |
| sip address@hidden       | y! skwashd                    |
+-------------------------------------+-------------------------------+