Gallery 3.1.x form definitions

--===============4748239357146291798==
Content-Type: multipart/alternative; boundary=089e01494226e7881d04da8f3021

--089e01494226e7881d04da8f3021
Content-Type: text/plain; charset=UTF-8

Hey everyone,

I'm starting to gear up for the big K2 Forge -> K3 Formo conversion, and
have a question: would it bother anyone to put all form definitions in
controllers?

In Gallery 3.0.x, there are two patterns I see:
- form validation/implementation in controller, form definition in
controller (often in a private function that's called by the main
controller action)
- form validation/implementation in controller, form definition in helper
(in a public function that's called by the main controller action)

Personally, I prefer the former configuration.  While I realize it may bug
a few folks to have all form info in controllers (form handling with pure
MVC separation isn't straightforward), I find it simpler to have the code
that defines the fields sitting in the same place as the code that uses
those field definitions to validate and/or implement user input.

Also, in K3 we don't need to make controller functions private to hide them
from url access.  We can leave them public and give them non-action names.

So, my proposal is to do something like this in the controller:

public function action_edit() {
  $form = $this->get_edit_form();
  // spit out the form
}

public function action_save() {
  // validate the form, process its inputs.
}

public function get_edit_form() {
  // define and return the form, whose action is save
  return $form;
}

Thoughts?

Take care,
Shad

--089e01494226e7881d04da8f3021
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey everyone,<div><br></div><div>I&#39;m starting to gear up for the big K2=
 Forge -&gt; K3 Formo conversion, and have a question: would it bother anyo=
ne to put all form definitions in controllers?</div><div><br></div><div>

In Gallery 3.0.x, there are two patterns I see:</div><div>- form validation=
/implementation in controller, form definition in controller (often in a pr=
ivate function that&#39;s called by the main controller action)</div><div>

- form validation/implementation in controller, form definition in helper (=
in a public function that&#39;s called by the main controller action)</div>=
<div><br></div><div>Personally, I prefer the former configuration. =C2=A0Wh=
ile I realize it may bug a few folks to have all form info in controllers (=
form handling with pure MVC separation isn&#39;t straightforward), I find i=
t simpler to have the code that defines the fields sitting in the same plac=
e as the code that uses those field definitions to validate and/or implemen=
t user input.</div>

<div><br></div><div>Also, in K3 we don&#39;t need to make controller functi=
ons private to hide them from url access. =C2=A0We can leave them public an=
d give them non-action names.</div><div><br></div><div>So, my proposal is t=
o do something like this in the controller:</div>

<div><br></div><div><font face=3D"courier new, monospace">public function a=
ction_edit() {</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 $form =3D $this-&gt;get_edit_form();</font></div><div><font face=3D"cou=
rier new, monospace">=C2=A0 // spit out the form</font></div>

<div><font face=3D"courier new, monospace">}</font></div><div><font face=3D=
"courier new, monospace"><br></font></div><div><font face=3D"courier new, m=
onospace">public function action_save() {</font></div><div><font face=3D"co=
urier new, monospace">=C2=A0 // validate the form, process its inputs.</fon=
t></div>

<div><font face=3D"courier new, monospace">}</font></div><div><font face=3D=
"courier new, monospace"><br></font></div><div><font face=3D"courier new, m=
onospace">public function get_edit_form() {</font></div><div><font face=3D"=
courier new, monospace">=C2=A0 // define and return the form, whose action =
is save</font></div>

<div><font face=3D"courier new, monospace">=C2=A0 return $form;</font></div=
><div><font face=3D"courier new, monospace">}</font></div><div><br></div><d=
iv>Thoughts?</div><div><br></div><div>Take care,</div><div>Shad</div>

--089e01494226e7881d04da8f3021--


--===============4748239357146291798==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
--===============4748239357146291798==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]
--===============4748239357146291798==--