*** Dries wrote:
FAPI and the Schema API: next steps (*) - A plan to get some more CCK/Views into core (*)
*** Jeff Eaton and chx replied:
I do not think we (Eaton+me) will have more ideas for FAPI, all the common grunts were solved w/ FAPI3, not until D6 is out, modules are ported and projects are ongoing will the flaws come to light. Let's get back to FAPI at the spring Drupalcon (Toronto?).
Yep, I'm with Karoly on this one. There are some cleanup bits and things we didn't necessarily have time for in FAPI3 (making form_set_values() and form_set_error() simpler, etc) but those are tweaks and polishing moves rather than architectural shifts.
It will take time, time for porting and exploration and envelope- pushing, to make it clear what changes the next generation will need.
Well, I have some issues still. Two simple examples: 1. Say I want to build a "submission throttle module". A user is not allowed to submit more than x forms per hour. If I want to make this module truly generic, I want to make it configurable. Specifically, I want to compile a list of all the forms in the system, and let the administrator enable/disable the forms that should be added to the pool of forms to be throttled. For example, I might include the 'create story form', the 'create comment form', the forms of the privatemsg module, and the guestbook module's form. However, I might want to exclude the search form, and the edit comment form -- I want people to be able to search and edit their comments as much as they want. 2. Take the action module. Right now, we have a hardcoded list of operations that you can attach actions too. While that's nice, imagine a world where you would be able to attach actions to *any* form. All of a sudden, I'd be able to tap into the search form, the sending of private messages, the creation of views, the adding of node types. You name it. The current FAPI does not allow me to build either. So while we have all the power to manipulate *individual* forms, there are no good tools or mechanisms to introduce tools that operate on a large number of forms. For this work, each form needs (i) a human-readable name that can be shown on a configuration page and (ii) all submit buttons require some semantic meta data as well. Right now, 'Submit' can be both 'create' or 'update'. Specifically, I want to be able to work with forms without having to know anything about them. I'd like to see us add some semantic metadata to them. Some of this metadata should be (i) human- readable, some of it should be (ii) machine-readable and (iii) some of it should be both. Thoughts? -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
For this work, each form needs (i) a human-readable name that can be shown on a configuration page and (ii) all submit buttons require some semantic meta data as well. Right now, 'Submit' can be both 'create' or 'update'.
The interface changes in Drupal 6 removed generic "Submit" labels on buttons, and made the labels more specific about the action. This truly does not help a bit in the meta data representation, because the labels are localized, so they are not predictable identifiable. Gabor
Gabor Hojtsy wrote:
The interface changes in Drupal 6 removed generic "Submit" labels on buttons, and made the labels more specific about the action. This truly does not help a bit in the meta data representation, because the labels are localized, so they are not predictable identifiable.
At what point will we move to having the "#value" of submit buttons set the "op" value and "#title" set the label?
David Strauss wrote:
Gabor Hojtsy wrote:
The interface changes in Drupal 6 removed generic "Submit" labels on buttons, and made the labels more specific about the action. This truly does not help a bit in the meta data representation, because the labels are localized, so they are not predictable identifiable.
At what point will we move to having the "#value" of submit buttons set the "op" value and "#title" set the label?
I would say "When HTML can tell the difference".
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dries Buytaert schrieb:
*** Dries wrote:
FAPI and the Schema API: next steps (*) - A plan to get some more CCK/Views into core (*)
*** Jeff Eaton and chx replied:
I do not think we (Eaton+me) will have more ideas for FAPI, all the common grunts were solved w/ FAPI3, not until D6 is out, modules are ported and projects are ongoing will the flaws come to light. Let's get back to FAPI at the spring Drupalcon (Toronto?).
Yep, I'm with Karoly on this one. There are some cleanup bits and things we didn't necessarily have time for in FAPI3 (making form_set_values() and form_set_error() simpler, etc) but those are tweaks and polishing moves rather than architectural shifts.
It will take time, time for porting and exploration and envelope-pushing, to make it clear what changes the next generation will need.
Well, I have some issues still. Two simple examples:
1. Say I want to build a "submission throttle module". A user is not allowed to submit more than x forms per hour. If I want to make this module truly generic, I want to make it configurable. Specifically, I want to compile a list of all the forms in the system, and let the administrator enable/disable the forms that should be added to the pool of forms to be throttled. For example, I might include the 'create story form', the 'create comment form', the forms of the privatemsg module, and the guestbook module's form. However, I might want to exclude the search form, and the edit comment form -- I want people to be able to search and edit their comments as much as they want.
Am I confused for thinking that you could do that in Drupal 4.7? You only need to look at that configurable list of yours in hook_form_alter and increment a counter in a custom submit handler that you add and query that counter in thook_form_alter. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGuamwfg6TFvELooQRAvleAJ9KbuVECyAUiZBZ9ulSpYJt2WhpnACeNxWQ LTqi7dHybUb2+m2aLWCthkg= =hazq -----END PGP SIGNATURE-----
Yeah, I thought so too. On the view op, get the name of the form and add it to your list in the database so it can be configured, and then on the validate op, check it against the flood count or whatever. The latest release of the captcha module does this for choosng which forms to put the captchas on. Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dries Buytaert schrieb:
*** Dries wrote:
FAPI and the Schema API: next steps (*) - A plan to get some more CCK/Views into core (*) *** Jeff Eaton and chx replied: I do not think we (Eaton+me) will have more ideas for FAPI, all the common grunts were solved w/ FAPI3, not until D6 is out, modules are ported and projects are ongoing will the flaws come to light. Let's get back to FAPI at the spring Drupalcon (Toronto?). Yep, I'm with Karoly on this one. There are some cleanup bits and things we didn't necessarily have time for in FAPI3 (making form_set_values() and form_set_error() simpler, etc) but those are tweaks and polishing moves rather than architectural shifts.
It will take time, time for porting and exploration and envelope-pushing, to make it clear what changes the next generation will need. Well, I have some issues still. Two simple examples:
1. Say I want to build a "submission throttle module". A user is not allowed to submit more than x forms per hour. If I want to make this module truly generic, I want to make it configurable. Specifically, I want to compile a list of all the forms in the system, and let the administrator enable/disable the forms that should be added to the pool of forms to be throttled. For example, I might include the 'create story form', the 'create comment form', the forms of the privatemsg module, and the guestbook module's form. However, I might want to exclude the search form, and the edit comment form -- I want people to be able to search and edit their comments as much as they want.
Am I confused for thinking that you could do that in Drupal 4.7? You only need to look at that configurable list of yours in hook_form_alter and increment a counter in a custom submit handler that you add and query that counter in thook_form_alter.
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGuamwfg6TFvELooQRAvleAJ9KbuVECyAUiZBZ9ulSpYJt2WhpnACeNxWQ LTqi7dHybUb2+m2aLWCthkg= =hazq -----END PGP SIGNATURE-----
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
On 8/8/07, Sean Robertson <seanr@ngpsoftware.com> wrote:
Yeah, I thought so too. On the view op, get the name of the form and add it to your list in the database so it can be configured, and then on the validate op, check it against the flood count or whatever. The latest release of the captcha module does this for choosng which forms to put the captchas on.
The current Captcha (5.x-3.0-rc1) [1] and Shortform [2] each attempt to do this in very interesting ways. Shortform's form inspector alone makes me love the module (though it needs a release!). I say "attempt" because the lack of unique form IDs prevents them from working reliably. So, I would like some more unique form IDs, but I know those should be filed as bugs on the individual projects - not as something against FormAPI. Regards, Greg [1] http://drupal.org/project/captcha [2] http://drupal.org/project/shortform -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
On 08 Aug 2007, at 16:24, Greg Knaddison - GVS wrote:
Yeah, I thought so too. On the view op, get the name of the form and add it to your list in the database so it can be configured, and then on the validate op, check it against the flood count or whatever. The latest release of the captcha module does this for choosng which forms to put the captchas on.
The current Captcha (5.x-3.0-rc1) [1] and Shortform [2] each attempt to do this in very interesting ways. Shortform's form inspector alone makes me love the module (though it needs a release!).
Except that the CAPTCHA module displays "contact_mail_page" instead of "The site-wide contact form". Exposing internal form IDs to users is not the best option, IMO. Some metadata could make this more user- friendly. -- Dries Buytaert :: http://www.buytaert.net/
Why not add a parameter to hook_forms called 'title'. Then module authors could give human readable names to their forms. Seems it should be relatively easy to do, looking at the code. Dries Buytaert wrote:
On 08 Aug 2007, at 16:24, Greg Knaddison - GVS wrote:
Yeah, I thought so too. On the view op, get the name of the form and add it to your list in the database so it can be configured, and then on the validate op, check it against the flood count or whatever. The latest release of the captcha module does this for choosng which forms to put the captchas on.
The current Captcha (5.x-3.0-rc1) [1] and Shortform [2] each attempt to do this in very interesting ways. Shortform's form inspector alone makes me love the module (though it needs a release!).
Except that the CAPTCHA module displays "contact_mail_page" instead of "The site-wide contact form". Exposing internal form IDs to users is not the best option, IMO. Some metadata could make this more user-friendly.
-- Dries Buytaert :: http://www.buytaert.net/
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
or simpler still require (or at least allow) $form['#title'] for each form? Or some similar top-level property? -Peter On 8/8/07, Sean Robertson <seanr@ngpsoftware.com> wrote:
Why not add a parameter to hook_forms called 'title'. Then module authors could give human readable names to their forms. Seems it should be relatively easy to do, looking at the code.
That's actually what I meant, sorry. Peter Wolanin wrote:
or simpler still require (or at least allow) $form['#title'] for each form? Or some similar top-level property?
-Peter
On 8/8/07, Sean Robertson <seanr@ngpsoftware.com> wrote:
Why not add a parameter to hook_forms called 'title'. Then module authors could give human readable names to their forms. Seems it should be relatively easy to do, looking at the code.
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
On Aug 8, 2007, at 4:06 PM, Peter Wolanin wrote:
or simpler still require (or at least allow) $form['#title'] for each form? Or some similar top-level property?
-Peter
This gets nasty very quickly. Retrieving one form, whose ID you know, and displaying its human-readable title, is fine. But figuring out whether there is another form, somewhere on your site, that you want to perform the same operation on? That's nasty. It's similar to the problem that we faced with theme functions in Drupal 5: overriding a theme function was easy ... once you figured out it was there. But figuring out *what theme functions existed for overriding* was an exercise in using regexes. In the D6 theme system, we solved this by creating a theme function registry. If you don't announce your 'foo' theme function in hook_theme(), you can't call theme('foo'). That makes the cached theme registry a reliable place to obtain information about theme functions. FormAPI, if it's to be used in the way that Dries seems to be talking about, needs this sort of system. otherwise, we're stuck with 'cool hacks,' like modules that hook_form_alter() everything while you browse around the site, and save a list of all the Form IDs they see pass by. That's way less than ideal. --Jeff
I'm all for that. I like the way the theme hook works now. Jeff Eaton wrote:
On Aug 8, 2007, at 4:06 PM, Peter Wolanin wrote:
or simpler still require (or at least allow) $form['#title'] for each form? Or some similar top-level property?
-Peter
This gets nasty very quickly. Retrieving one form, whose ID you know, and displaying its human-readable title, is fine. But figuring out whether there is another form, somewhere on your site, that you want to perform the same operation on? That's nasty.
It's similar to the problem that we faced with theme functions in Drupal 5: overriding a theme function was easy ... once you figured out it was there. But figuring out *what theme functions existed for overriding* was an exercise in using regexes. In the D6 theme system, we solved this by creating a theme function registry. If you don't announce your 'foo' theme function in hook_theme(), you can't call theme('foo'). That makes the cached theme registry a reliable place to obtain information about theme functions.
FormAPI, if it's to be used in the way that Dries seems to be talking about, needs this sort of system. otherwise, we're stuck with 'cool hacks,' like modules that hook_form_alter() everything while you browse around the site, and save a list of all the Form IDs they see pass by. That's way less than ideal.
--Jeff
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
On 08 Aug 2007, at 22:48, Sean Robertson wrote:
Why not add a parameter to hook_forms called 'title'. Then module authors could give human readable names to their forms. Seems it should be relatively easy to do, looking at the code.
Uhm, that's _exactly_ what I proposed. Except that only a title might not be enough -- I also want to tap into the 'action' (i.e. previews vs save, create vs update). Please carefully re-read my first e-mail. :) -- Dries Buytaert :: http://www.buytaert.net/
My apologies, I skimmed through it in a bit of a hurry. Nevertheless, what you and I are both interested in does not seem to be so complicated that it could appear before D6 (correct me if I'm wrong). Dries Buytaert wrote:
On 08 Aug 2007, at 22:48, Sean Robertson wrote:
Why not add a parameter to hook_forms called 'title'. Then module authors could give human readable names to their forms. Seems it should be relatively easy to do, looking at the code.
Uhm, that's _exactly_ what I proposed. Except that only a title might not be enough -- I also want to tap into the 'action' (i.e. previews vs save, create vs update). Please carefully re-read my first e-mail. :)
-- Dries Buytaert :: http://www.buytaert.net/
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
On Aug 8, 2007, at 3:48 PM, Sean Robertson wrote:
Why not add a parameter to hook_forms called 'title'. Then module authors could give human readable names to their forms. Seems it should be relatively easy to do, looking at the code.
Yes, absolutely. This is a very easy change to make -- but it only works for forms that go through hook_forms().
Dries Buytaert wrote:
Except that the CAPTCHA module displays "contact_mail_page" instead of "The site-wide contact form". Exposing internal form IDs to users is not the best option, IMO. Some metadata could make this more user-friendly.
IMO, in Drupal 7 we should consider a form registry similar to the theme registry. Also, and this could probably be patched for Drupal 6 -- but perhaps the theme registry should be including metadata information, such as a description. Of course, that info is also in the PHP doc, so it'd be data duplication.
Sorry, coming in late catching up to Emails. Regarding what Dries said, it seems we need a form registry whether mandatory (declaratory/explicit) or deduced (implicit). We seem to already have one that Heine wrote, Form Store: http://drupal.org/project/form_store There is also Form Corral http://drupal.org/project/formcorral These may be good starting points ...
Khalid Baheyeldin wrote:
Sorry, coming in late catching up to Emails.
Regarding what Dries said, it seems we need a form registry whether mandatory (declaratory/explicit) or deduced (implicit).
We seem to already have one that Heine wrote, Form Store: http://drupal.org/project/form_store
There is also Form Corral http://drupal.org/project/formcorral
These may be good starting points ...
Anything that is after the fact will, IMO, not be nearly as useful. What we want, I believe, is to retool hook_form to work similarly to hook_theme. For that matter, I also had a patch that created a hook registry, which had some other really interesting effects, but I wasn't convinced there was a great deal of performance improvement there, so I didn't work on it aggressively. In fact, I did that prior to the theme registry, and decided there were massive benefits to the theme version; whereas the hook version had pretty minor benefits. Likewise, a form registry would allow us to do some pretty powerful things with forms. For example, automatic registration of theme functions for forms. Right now, I predict this is going to be a bit of an issue in Drupal 6, because all forms can have theme functions, but only theme functions that actually exist can be overridden easily. (It's possible to register them the hard way, it just takes more effort on the part of the themer). That's something that can be fixed a couple of ways, but registering forms is one way. It would also allow more advanced form browsing, opening the way for themers to use interactive tools to help with forms. That's a HUGE problem in Drupal right now; the form api is very, very powerful, and it's completely opaque to people whose primary skillset is HTML/CSS. This is something we should do very early for Drupal 7.
On Aug 8, 2007, at 5:47 AM, Dries Buytaert wrote:
1. Say I want to build a "submission throttle module". A user is not allowed to submit more than x forms per hour. If I want to make this module truly generic, I want to make it configurable. Specifically, I want to compile a list of all the forms in the system, and let the administrator enable/disable the forms that should be added to the pool of forms to be throttled. For example, I might include the 'create story form', the 'create comment form', the forms of the privatemsg module, and the guestbook module's form. However, I might want to exclude the search form, and the edit comment form -- I want people to be able to search and edit their comments as much as they want.
2. Take the action module. Right now, we have a hardcoded list of operations that you can attach actions too. While that's nice, imagine a world where you would be able to attach actions to *any* form. All of a sudden, I'd be able to tap into the search form, the sending of private messages, the creation of views, the adding of node types. You name it.
hook_form_alter() can add a #validate and a #submit handler to every form that passes its way. Set the per-user per-form throttle count, and add a configurable action to the mix, and it's possible. The real limitation in this regard isn't FAPI, but the Action system's lack of clean configurable conditional support. Even that can be worked around by making a standalone configurable action, not unlike the 'if a node contains these words...' action.
The current FAPI does not allow me to build either. So while we have all the power to manipulate *individual* forms, there are no good tools or mechanisms to introduce tools that operate on a large number of forms.
hook_form_alter catches every form; modules like form_defaults do this in a generic fashion and do it really well. The limitation is not so much operating on every form, but operating on *select subsets* of forms, because there is no central repository that can be used to list all the forms in the system.
For this work, each form needs (i) a human-readable name that can be shown on a configuration page and (ii) all submit buttons require some semantic meta data as well. Right now, 'Submit' can be both 'create' or 'update'.
This is a good case for hook_forms() being a requirement, not an optional mechanism. Right now, users can just call drupal_get_form ('lovely_delicious_bacon') and FAPI will go about its business happily, checking for a lovely_delicious_bacon() function, then checkig hook_forms() to see if lovely_delicious_bacon was really mapped to my_module_bacon_form(). If we were to make even the simple forms require the use of hook_forms (), we would have a very simple transition and an easy place to put descriptive metadata. ("What kind of form is this? What module does it belong to?" Etc.)
Specifically, I want to be able to work with forms without having to know anything about them. I'd like to see us add some semantic metadata to them. Some of this metadata should be (i) human- readable, some of it should be (ii) machine-readable and (iii) some of it should be both.
This is always going to be tough, and if it works at all it's going to be shockingly verbose to work in more than a handful of cases. Wouldn't something like fQuery be a better fit? hook_form_alter() everything, then scan it for patterns that match... --Jeff
On Wed, 8 Aug 2007 08:57:14 -0500, Jeff Eaton <jeff@viapositiva.net> wrote:
This is a good case for hook_forms() being a requirement, not an optional mechanism. Right now, users can just call drupal_get_form ('lovely_delicious_bacon') and FAPI will go about its business happily, checking for a lovely_delicious_bacon() function, then checkig hook_forms() to see if lovely_delicious_bacon was really mapped to my_module_bacon_form().
If we were to make even the simple forms require the use of hook_forms (), we would have a very simple transition and an easy place to put descriptive metadata. ("What kind of form is this? What module does it belong to?" Etc.)
... what separate .inc file does it live in... ;-) --Larry Garfield
Specifically, I want to be able to work with forms without having to know anything about them. I'd like to see us add some semantic metadata to them. Some of this metadata should be (i) human- readable, some of it should be (ii) machine-readable and (iii) some of it should be both.
Indeed that would be the first catch to make writing a clean UI for the action configuration. However - the action would need further information about the form such as a list of available form elements, so that the action can alter them. So we either need more metadata describing the form elements (puh..) or the action has to simulate executing drupal_get_form, which would require knowledge about the needed arguments. As jeff said, tough... Anyway, a neat idea! -fago
On 8/8/07, Jeff Eaton <jeff@viapositiva.net> wrote:
On Aug 8, 2007, at 5:47 AM, Dries Buytaert wrote:
For this work, each form needs (i) a human-readable name that can be shown on a configuration page and (ii) all submit buttons require some semantic meta data as well. Right now, 'Submit' can be both 'create' or 'update'.
This is a good case for hook_forms() being a requirement, not an optional mechanism. Right now, users can just call drupal_get_form ('lovely_delicious_bacon') and FAPI will go about its business happily, checking for a lovely_delicious_bacon() function, then checkig hook_forms() to see if lovely_delicious_bacon was really mapped to my_module_bacon_form().
If we were to make even the simple forms require the use of hook_forms (), we would have a very simple transition and an easy place to put descriptive metadata. ("What kind of form is this? What module does it belong to?" Etc.)
This would add another step to building forms and fragment the form code. Keeping a form's code all in one place is good and makes forms easier to code. Another possibility is using consistent function names for forms. This is how I removed the index of update functions that used to exist in update.php, I required the update function names to follow a pattern and finding all of them was done easily. -- Neil Drumm http://delocalizedham.com
On Aug 9, 2007, at 5:30 PM, Neil Drumm wrote:
Another possibility is using consistent function names for forms. This is how I removed the index of update functions that used to exist in update.php, I required the update function names to follow a pattern and finding all of them was done easily.
This is probably a tricky one; I tend towards the expressiveness of lookup tables and arbitrary function names rather than strict naming conventions, but I realize that I might be in the minority. ;) I wanted to use <form_id>_builder() or <form_id>_form() as our standard 'constructor' function names, but the use of <form_id>() ultimately won out a while back. --Jeff
On 9-Aug-07, at 6:49 PM, Jeff Eaton wrote:
On Aug 9, 2007, at 5:30 PM, Neil Drumm wrote:
Another possibility is using consistent function names for forms. This is how I removed the index of update functions that used to exist in update.php, I required the update function names to follow a pattern and finding all of them was done easily.
This is probably a tricky one; I tend towards the expressiveness of lookup tables and arbitrary function names rather than strict naming conventions, but I realize that I might be in the minority. ;) I wanted to use <form_id>_builder() or <form_id>_form () as our standard 'constructor' function names, but the use of <form_id>() ultimately won out a while back.
<form_id>_form() would be more consistent with <form_id>_validate() and <form_id>_submit(). A workshop student brought up this point of confusion in Chicago. Too late to change it for D6 though, I guess. -Angie
For this work, each form needs (i) a human-readable name that can be shown on a configuration page and (ii) all submit buttons require some semantic meta data as well. Right now, 'Submit' can be both 'create' or 'update'.
Specifically, I want to be able to work with forms without having to know anything about them. I'd like to see us add some semantic metadata to them. Some of this metadata should be (i) human- readable, some of it should be (ii) machine-readable and (iii) some of it should be both.
Such a directory of forms is basically a web services API for the whole site. One can throw POSTS into any of the forms and programmatically retrieve data, change data, etc. We'll also need some better method for authentication besides cookie (maybe http://drupal.org/project/tokenauth), and ideally get the "output format" issue licked (http://drupal.org/node/145551). Lets discuss those elsewhere, and focus this discussion on the forms directory.
On 08 Aug 2007, at 18:27, Moshe Weitzman wrote:
Specifically, I want to be able to work with forms without having to know anything about them. I'd like to see us add some semantic metadata to them. Some of this metadata should be (i) human- readable, some of it should be (ii) machine-readable and (iii) some of it should be both.
Such a directory of forms is basically a web services API for the whole site. One can throw POSTS into any of the forms and programmatically retrieve data, change data, etc.
Exactly. And it's currently not as easy as it should/could be. We need some metadata that helps us introspect the forms, and that helps a tool discover how to operate the form without having to know all the nitty details about the data it's working with. We need to abstract that away. For example: if there are 3 submit handlers (3 buttons; one for preview, one to upload a file, and one to submit the form) how do I know which handler to call to save the data? -- Dries Buytaert :: http://www.buytaert.net/
participants (15)
-
Angela Byron -
David Strauss -
Dries Buytaert -
Earl Miles -
fago -
Gabor Hojtsy -
Gerhard Killesreiter -
Greg Knaddison - GVS -
Jeff Eaton -
Khalid Baheyeldin -
Larry Garfield -
Moshe Weitzman -
Neil Drumm -
Peter Wolanin -
Sean Robertson