Re: Gallery 3.1.x form definitions

--===============4215656405642931308==
Content-Type: multipart/alternative; boundary=f46d0447a1cb0b7ba804da93da3e

--f46d0447a1cb0b7ba804da93da3e
Content-Type: text/plain; charset=ISO-8859-1

I agree.  Forms are inherently tied to the browser so they belong in the
controller.  The main reasons why we used helpers for this were to avoid
the problem that all functions in controllers are directly accessible so
now with K3 we can put them back in the controller.


On Wed, Apr 17, 2013 at 7:20 AM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:

> 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
>
>
> ------------------------------------------------------------------------------
> 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
> __[ 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 ]
>

--f46d0447a1cb0b7ba804da93da3e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div style>I agree. =A0Forms are inherently tied to th=
e browser so they belong in the controller. =A0The main reasons why we used=
 helpers for this were to avoid the problem that all functions in controlle=
rs are directly accessible so now with K3 we can put them back in the contr=
oller.</div>

</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
 Apr 17, 2013 at 7:20 AM, Shad Laws <span dir=3D"ltr">&lt;<a href=3D"mailto=
:shad-xpYdmXCiSuZWk0Htik3J/[email protected]" target=3D"_blank">shad-xpYdmXCiSuZWk0Htik3J/[email protected]</a>&gt;</span> wrot=
e:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hey everyone,<div><br></div><div>I&#39;m sta=
rting to gear up for the big K2 Forge -&gt; K3 Formo conversion, and have a=
 question: would it bother anyone to put all form definitions in controller=
s?</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. =A0While=
 I realize it may bug a few folks to have all form info in controllers (for=
m handling with pure MVC separation isn&#39;t straightforward), I find it s=
impler to have the code that defines the fields sitting in the same place a=
s the code that uses those field definitions to validate and/or implement u=
ser 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. =A0We can leave them public and g=
ive them non-action names.</div><div><br></div><div>So, my proposal is to d=
o 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">=A0 $=
form =3D $this-&gt;get_edit_form();</font></div><div><font face=3D"courier =
new, monospace">=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">=A0 // validate the form, process its inputs.</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 get_edit_form() {</font></div><div><font face=3D"=
courier new, monospace">=A0 // define and return the form, whose action is =
save</font></div>



<div><font face=3D"courier new, monospace">=A0 return $form;</font></div><d=
iv><font face=3D"courier new, monospace">}</font></div><div><br></div><div>=
Thoughts?</div><div><br></div><div>Take care,</div><div>Shad</div>
<br>-----------------------------------------------------------------------=
-------<br>
Precog is a next-generation analytics platform capable of advanced<br>
analytics on semi-structured data. The platform includes APIs for building<=
br>
apps and a phenomenal toolset for data science. Developers can use<br>
our toolset for easy data analysis &amp; visualization. Get a free account!=
<br>
<a href=3D"http://www2.precog.com/precogplatform/slashdotnewsletter" target=
=3D"_blank">http://www2.precog.com/precogplatform/slashdotnewsletter</a><br=
>__[ g a l l e r y - d e v e l ]_________________________<br>
<br>
[ list info/archive --&gt; <a href=3D"http://gallery.sf.net/lists.php" targ=
et=3D"_blank">http://gallery.sf.net/lists.php</a> ]<br>
[ gallery info/FAQ/download --&gt; <a href=3D"http://gallery.sf.net" target=
=3D"_blank">http://gallery.sf.net</a> ]<br></blockquote></div><br></div>

--f46d0447a1cb0b7ba804da93da3e--


--===============4215656405642931308==
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
--===============4215656405642931308==
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 ]
--===============4215656405642931308==--