[geeklog-devtalk] geeklog-devel digest, Vol 1 #466 - 12 msgs

[geeklog-devel-request at lists.geeklog.net]

Send geeklog-devel mailing list submissions to
	geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
	geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
	geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."


Today's Topics:

   1. Controls in GL2 (Tony Bibbs)
   2. Re: Simon or a replace of? (Blaine Lang)
   3. Re: Controls in GL2 (Blaine Lang)
   4. Re: Controls in GL2 (Tony Bibbs)
   5. Re: Controls in GL2 (Blaine Lang)
   6. Re: Controls in GL2 (Tony Bibbs)
   7. Globals in GL2 (Tony Bibbs)
   8. Re: Globals in GL2 (Justin Carlson)
   9. Re: Globals in GL2 (dwight at trumbower.com)
  10. Re: Globals in GL2 (Vincent Furia)
  11. Re: Globals in GL2 (Justin Carlson)
  12. Re: Globals in GL2 (Tony Bibbs)

--__--__--

Message: 1
Date: Tue, 21 Dec 2004 13:33:16 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: [geeklog-devel] Controls in GL2
Reply-To: geeklog-devel at lists.geeklog.net

As you are all aware, there are a number of controls that could be used 
for various things.  For example, for a date form field you could have a 
simple text field, or a series of drop downs (one for month, day and 
year) or something more complicated like a dropdown calendar.

There are probably a number of different various of types of controls 
that could be used for all the different types of data that Geeklog 
plugins will use.  We should allow for those to be customized with 
little to no hassle, no?

Only reason I am asking is I think we may want to consider having a 
control factory that does this work for us.  It would, upon request, 
take requests for a specific control, create it, set the default data 
and return the corresponding HTML and/or Javascript (/me cringes).  The 
idea is we'd simply have a folder where GL2 admins could drop new or 
custom controls, change a template or two and have it working.

...or am I over complicated things.

--Tony

--__--__--

Message: 2
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Simon or a replace of?
Date: Tue, 21 Dec 2004 15:00:29 -0500
Reply-To: geeklog-devel at lists.geeklog.net

Tony,

I've been using some of the CSS standards that Simon and I came up with and 
have been refining them as part of my plugin development over the past year. 
More specifically, I have published the recommendations to the 
geeklog-modules list a few weeks back.

My present work on a new Forum Plugin version will in fact be able to use 
one set of templates and just use the CSS for themeing. This will work 
unless someone needs to modify a template file for one theme only. But most 
sites actually only use one theme.

Simon has a much larger list of CSS declaration standards that were being 
developed as part of a new GL Theme project we were working on. This can be 
the base of the discussions and planning for GL2. Simon wanted to out 
toghether a design guide I believe.

Blaine
----- Original Message ----- 
From: "Tony Bibbs" <tony at tonybibbs.com>
To: <geeklog-devel at lists.geeklog.net>
Sent: Tuesday, December 21, 2004 9:37 AM
Subject: Re: [geeklog-devel] Simon or a replace of?


Simon Lord wrote:


> No problem.  Technically Blaine and I have done this already, what's

> missing is pretty much what you're looking for and that's a rough

> draft for the design document.  Basically we need to define a suite of

> classes which will be attached to specific things such as story title,

> story text, title background etc.


If you could send those past notes and/or supporting code that would be
great.  One noteworthy design decision is that MVCnPHP-based plugins
will allow plugins to keep their templates within their own directory
structure.  Use of MVCnPHP is optional, but strongly encouraged.  We'll
still need to figure out how to get around non-MVC/procedural plugins.


>

> After that we just need to figure out how much of the site we want

> done using div's as opposed to tables...


Hopefully as much as possible.

--Tony
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


--__--__--

Message: 3
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Controls in GL2
Date: Tue, 21 Dec 2004 15:10:30 -0500
Reply-To: geeklog-devel at lists.geeklog.net

Tony,

I personally am using more JS all the time for form validation and if GL2 is 
going to be positioned for corporate use as well then JS support is more 
then likely well supported in their browsers. We can also look to consider 
looking at IE7 https://sourceforge.net/projects/ie7/

I like the idea of having re-usable functions for generating listboxes for 
example. There is always a lot of common code to generate the HTML for the 
list.
Date fields as well with a drop down calendar are nice - I use that often 
now.

The other idea is to implement PEAR::HTML_QuickForm.

We would just need to allow developers to fully extend the elements easily.

Blaine

----- Original Message ----- 
From: "Tony Bibbs" <tony at tonybibbs.com>
To: <geeklog-devel at lists.geeklog.net>
Sent: Tuesday, December 21, 2004 2:33 PM
Subject: [geeklog-devel] Controls in GL2


As you are all aware, there are a number of controls that could be used
for various things.  For example, for a date form field you could have a
simple text field, or a series of drop downs (one for month, day and
year) or something more complicated like a dropdown calendar.

There are probably a number of different various of types of controls
that could be used for all the different types of data that Geeklog
plugins will use.  We should allow for those to be customized with
little to no hassle, no?

Only reason I am asking is I think we may want to consider having a
control factory that does this work for us.  It would, upon request,
take requests for a specific control, create it, set the default data
and return the corresponding HTML and/or Javascript (/me cringes).  The
idea is we'd simply have a folder where GL2 admins could drop new or
custom controls, change a template or two and have it working.

...or am I over complicated things.

--Tony
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


--__--__--

Message: 4
Date: Tue, 21 Dec 2004 14:22:42 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Controls in GL2
Reply-To: geeklog-devel at lists.geeklog.net

Blaine Lang wrote:


>Tony,

>

>I personally am using more JS all the time for form validation and if GL2 is 

>going to be positioned for corporate use as well then JS support is more 

>then likely well supported in their browsers. We can also look to consider 

>looking at IE7 https://sourceforge.net/projects/ie7/

>  

>

Inserting client-side JS for validation shouldn't be a problem.  I was 
more concerned with JS in controls (i.e. drop down calendar)


>I like the idea of having re-usable functions for generating listboxes for 

>example. There is always a lot of common code to generate the HTML for the 

>list.

>  

>

Flexy includes most if not all the functions for generating standard 
HTML controls.  I'm more after customized versions of controls (date 
control, time control, editor controls, etc)


>Date fields as well with a drop down calendar are nice - I use that often 

>now.

>  

>

Yeah, I agree, this is more the type of scenario I was getting at.


>The other idea is to implement PEAR::HTML_QuickForm.

>

>We would just need to allow developers to fully extend the elements easily

>

Actually Flexy used QuickForm for a while and then got rid of it.  Quick 
form was more for implementing entire forms via PHP code and wasn't 
really intended or use in template engines.  Flexy allows you to stub 
out, for example, your list box in the template and the code that 
generates it is in the view.  I have an example of this one or more of 
the views in the sample code that you and Dirk are yet to get working 
(sorry, shameless dig).

--Tony


--__--__--

Message: 5
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Controls in GL2
Date: Tue, 21 Dec 2004 15:38:30 -0500
Reply-To: geeklog-devel at lists.geeklog.net

Tony wrote:

> I have an example of this one or more of the views in the sample code that 

> you and Dirk are yet to get working

(sorry, shameless dig).

Are you referring to the Hunting Log?
Both Dirk and I got that running after you released the version that had 
better control over the Paths.
We both replied to the list on this - I still had the Windows issue with a ; 
instead of a : in the include_path.

Those forms were pretty basic (by design I know).

Blaine
----- Original Message ----- 
From: "Tony Bibbs" <tony at tonybibbs.com>
To: <geeklog-devel at lists.geeklog.net>
Sent: Tuesday, December 21, 2004 3:22 PM
Subject: Re: [geeklog-devel] Controls in GL2


Blaine Lang wrote:


>Tony,

>

>I personally am using more JS all the time for form validation and if GL2 

>is

>going to be positioned for corporate use as well then JS support is more

>then likely well supported in their browsers. We can also look to consider

>looking at IE7 https://sourceforge.net/projects/ie7/

>

>

Inserting client-side JS for validation shouldn't be a problem.  I was
more concerned with JS in controls (i.e. drop down calendar)


>I like the idea of having re-usable functions for generating listboxes for

>example. There is always a lot of common code to generate the HTML for the

>list.

>

>

Flexy includes most if not all the functions for generating standard
HTML controls.  I'm more after customized versions of controls (date
control, time control, editor controls, etc)


>Date fields as well with a drop down calendar are nice - I use that often

>now.

>

>

Yeah, I agree, this is more the type of scenario I was getting at.


>The other idea is to implement PEAR::HTML_QuickForm.

>

>We would just need to allow developers to fully extend the elements easily

>

Actually Flexy used QuickForm for a while and then got rid of it.  Quick
form was more for implementing entire forms via PHP code and wasn't
really intended or use in template engines.  Flexy allows you to stub
out, for example, your list box in the template and the code that
generates it is in the view.  I have an example of this one or more of
the views in the sample code that you and Dirk are yet to get working
(sorry, shameless dig).

--Tony

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel 


--__--__--

Message: 6
Date: Tue, 21 Dec 2004 15:14:02 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Controls in GL2
Reply-To: geeklog-devel at lists.geeklog.net

Oh yeah (short memory).  Anyway, here's the flexy snippet to populate a 
drop down:

$this->getDropDown('getAllCloudCover', 'HlHunt->cloudCoverId', ''
            , $this->hunt->getCloudCoverId(),'lovId', 'shortName');

That's a function on one of the base views I wrote which gets translated 
to this:

protected function getDropDown($dropDownName, $htmlFieldName, $queryArgs 
= '' , $setValue = ''
        , $idAttribute = '', $displayAttribute = '')
    {
        $resultArray = array();
        $dao = DAOFactory::getDAO();
        if (is_array($queryArgs) AND (count($queryArgs) > 0)) {
            $objArray = $dao->find($dropDownName, $queryArgs);
        } else {
            $objArray = $dao->find($dropDownName);
        }
        $idGetMethod = 'get' . ucwords($idAttribute);
        $displayGetMethod = 'get' . ucwords($displayAttribute);
        foreach ($objArray as $curObj) {
            $resultArray[$curObj->$idGetMethod()] = 
$curObj->$displayGetMethod();
        }
        $this->flexyElements[$htmlFieldName] = new 
HTML_Template_Flexy_Element;
        $this->flexyElements[$htmlFieldName]->setOptions($resultArray);
        if (!empty($setValue)) {
            $this->flexyElements[$htmlFieldName]->setValue($setValue);
        }
    }

Here's the actual field in the flexy template:

<select name="HlHunt->cloudCoverId" tabindex="30"></select>

Seems like a lot of code but since it all gets compiled by flexy, its 
quite fast.

--Tony

Blaine Lang wrote:


>Tony wrote:

>  

>

>>I have an example of this one or more of the views in the sample code that 

>>you and Dirk are yet to get working

>>    

>>

>(sorry, shameless dig).

>

>Are you referring to the Hunting Log?

>Both Dirk and I got that running after you released the version that had 

>better control over the Paths.

>We both replied to the list on this - I still had the Windows issue with a ; 

>instead of a : in the include_path.

>

>Those forms were pretty basic (by design I know).

>

>Blaine

>----- Original Message ----- 

>From: "Tony Bibbs" <tony at tonybibbs.com>

>To: <geeklog-devel at lists.geeklog.net>

>Sent: Tuesday, December 21, 2004 3:22 PM

>Subject: Re: [geeklog-devel] Controls in GL2

>

>

>Blaine Lang wrote:

>

>  

>

>>Tony,

>>

>>I personally am using more JS all the time for form validation and if GL2 

>>is

>>going to be positioned for corporate use as well then JS support is more

>>then likely well supported in their browsers. We can also look to consider

>>looking at IE7 https://sourceforge.net/projects/ie7/

>>

>>

>>    

>>

>Inserting client-side JS for validation shouldn't be a problem.  I was

>more concerned with JS in controls (i.e. drop down calendar)

>

>  

>

>>I like the idea of having re-usable functions for generating listboxes for

>>example. There is always a lot of common code to generate the HTML for the

>>list.

>>

>>

>>    

>>

>Flexy includes most if not all the functions for generating standard

>HTML controls.  I'm more after customized versions of controls (date

>control, time control, editor controls, etc)

>

>  

>

>>Date fields as well with a drop down calendar are nice - I use that often

>>now.

>>

>>

>>    

>>

>Yeah, I agree, this is more the type of scenario I was getting at.

>

>  

>

>>The other idea is to implement PEAR::HTML_QuickForm.

>>

>>We would just need to allow developers to fully extend the elements easily

>>

>>    

>>

>Actually Flexy used QuickForm for a while and then got rid of it.  Quick

>form was more for implementing entire forms via PHP code and wasn't

>really intended or use in template engines.  Flexy allows you to stub

>out, for example, your list box in the template and the code that

>generates it is in the view.  I have an example of this one or more of

>the views in the sample code that you and Dirk are yet to get working

>(sorry, shameless dig).

>

>--Tony

>

>_______________________________________________

>geeklog-devel mailing list

>geeklog-devel at lists.geeklog.net

>http://lists.geeklog.net/listinfo/geeklog-devel 

>

>_______________________________________________

>geeklog-devel mailing list

>geeklog-devel at lists.geeklog.net

>http://lists.geeklog.net/listinfo/geeklog-devel

>  

>



--__--__--

Message: 7
Date: Tue, 21 Dec 2004 15:30:42 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: [geeklog-devel] Globals in GL2
Reply-To: geeklog-devel at lists.geeklog.net

Today I have a config file similar to the 1.3.x one.  All values get 
loaded into an array, $glConf.  Now, OO purists would say that you 
should never have to use global variables in your objects...instead you 
should pass them along in either the constructor or in via the method 
call (which ever makes sense).

So my question is, are we purists or not?  I've got some code that uses 
"global $glConf;" and some that doesn't.  Just want to make sure we 
don't have any violent reaction to this.

--Tony

--__--__--

Message: 8
Date: Tue, 21 Dec 2004 15:37:53 -0600
From: Justin Carlson <justin.carlson at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Globals in GL2
Reply-To: geeklog-devel at lists.geeklog.net

Going from scratch, no use cutting corners. 
I vote to pass the conf array to the objects.


On Tue, 21 Dec 2004 15:30:42 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

> Today I have a config file similar to the 1.3.x one.  All values get

> loaded into an array, $glConf.  Now, OO purists would say that you

> should never have to use global variables in your objects...instead you

> should pass them along in either the constructor or in via the method

> call (which ever makes sense).

> 

> So my question is, are we purists or not?  I've got some code that uses

> "global $glConf;" and some that doesn't.  Just want to make sure we

> don't have any violent reaction to this.

> 

> --Tony

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

>


--__--__--

Message: 9
Date: Tue, 21 Dec 2004 16:54:08 -0500 (EST)
Subject: Re: [geeklog-devel] Globals in GL2
From: dwight at trumbower.com
To: geeklog-devel at lists.geeklog.net
Reply-To: geeklog-devel at lists.geeklog.net


> So my question is, are we purists or not?  I've got some code that uses

> "global $glConf;" and some that doesn't.  Just want to make sure we

> don't have any violent reaction to this.


Depends what your goal is. Fast practical code or easy to maintain code. :)

--__--__--

Message: 10
Date: Tue, 21 Dec 2004 16:56:48 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Globals in GL2
Reply-To: geeklog-devel at lists.geeklog.net

I hate that configuration array.  It's the worst part about installing
Geeklog.  I think we should look for better solutions if we can (a
configuration class/struct, something in the DB that gets cached to
disk?, an xml file?).

-Vinny


On Tue, 21 Dec 2004 15:37:53 -0600, Justin Carlson
<justin.carlson at gmail.com> wrote:

> Going from scratch, no use cutting corners.

> I vote to pass the conf array to the objects.

> 

> 

> On Tue, 21 Dec 2004 15:30:42 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

> > Today I have a config file similar to the 1.3.x one.  All values get

> > loaded into an array, $glConf.  Now, OO purists would say that you

> > should never have to use global variables in your objects...instead you

> > should pass them along in either the constructor or in via the method

> > call (which ever makes sense).

> >

> > So my question is, are we purists or not?  I've got some code that uses

> > "global $glConf;" and some that doesn't.  Just want to make sure we

> > don't have any violent reaction to this.

> >

> > --Tony

> > _______________________________________________

> > geeklog-devel mailing list

> > geeklog-devel at lists.geeklog.net

> > http://lists.geeklog.net/listinfo/geeklog-devel

> >

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

>


--__--__--

Message: 11
Date: Tue, 21 Dec 2004 16:03:30 -0600
From: Justin Carlson <justin.carlson at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Globals in GL2
Reply-To: geeklog-devel at lists.geeklog.net


> Depends what your goal is. Fast practical code or easy to maintain code. :)


Expand please. Which way do you consider harder to maintain, or less practical?

--__--__--

Message: 12
Date: Tue, 21 Dec 2004 16:08:55 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Globals in GL2
Reply-To: geeklog-devel at lists.geeklog.net

I don't care how the user interfaces with the configuration.  I think we 
all agreed some time ago that most of the configuration would be 
web-based.  But, regardless of stored format (xml, DB, etc), the data 
needs to be in a structure we can read.  Seems an array is Ok for that, no?

--Tony


Vincent Furia wrote:


>I hate that configuration array.  It's the worst part about installing

>Geeklog.  I think we should look for better solutions if we can (a

>configuration class/struct, something in the DB that gets cached to

>disk?, an xml file?).

>

>-Vinny

>

>

>On Tue, 21 Dec 2004 15:37:53 -0600, Justin Carlson

><justin.carlson at gmail.com> wrote:

>  

>

>>Going from scratch, no use cutting corners.

>>I vote to pass the conf array to the objects.

>>

>>

>>On Tue, 21 Dec 2004 15:30:42 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

>>    

>>

>>>Today I have a config file similar to the 1.3.x one.  All values get

>>>loaded into an array, $glConf.  Now, OO purists would say that you

>>>should never have to use global variables in your objects...instead you

>>>should pass them along in either the constructor or in via the method

>>>call (which ever makes sense).

>>>

>>>So my question is, are we purists or not?  I've got some code that uses

>>>"global $glConf;" and some that doesn't.  Just want to make sure we

>>>don't have any violent reaction to this.

>>>

>>>--Tony

>>>_______________________________________________

>>>geeklog-devel mailing list

>>>geeklog-devel at lists.geeklog.net

>>>http://lists.geeklog.net/listinfo/geeklog-devel

>>>

>>>      

>>>

>>_______________________________________________

>>geeklog-devel mailing list

>>geeklog-devel at lists.geeklog.net

>>http://lists.geeklog.net/listinfo/geeklog-devel

>>

>>    

>>

>_______________________________________________

>geeklog-devel mailing list

>geeklog-devel at lists.geeklog.net

>http://lists.geeklog.net/listinfo/geeklog-devel

>  

>




--__--__--

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


End of geeklog-devel Digest