Re: Gallery 3.1.x form definitions

Chad Kieffer <[email protected]> Wed, 17 Apr 2013 09:32:56 -0600
Newsgroups gmane.comp.web.gallery.devel
Message-ID <[email protected]>
--===============1494485950819877893==
Content-Type: multipart/alternative;
	boundary=Apple-Mail-E7B487BE-7BE2-4DB5-9403-626455ADB26B
Content-Transfer-Encoding: 7bit


--Apple-Mail-E7B487BE-7BE2-4DB5-9403-626455ADB26B
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Your proposed approach seems reasonable and familiar to me.=20

- Chad

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

> Hey everyone,
>=20
> I'm starting to gear up for the big K2 Forge -> K3 Formo conversion, and h=
ave a question: would it bother anyone to put all form definitions in contro=
llers?
>=20
> In Gallery 3.0.x, there are two patterns I see:
> - form validation/implementation in controller, form definition in control=
ler (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)
>=20
> 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 M=
VC separation isn't straightforward), I find it simpler to have the code tha=
t defines the fields sitting in the same place as the code that uses those f=
ield definitions to validate and/or implement user input.
>=20
> Also, in K3 we don't need to make controller functions private to hide the=
m from url access.  We can leave them public and give them non-action names.=

>=20
> So, my proposal is to do something like this in the controller:
>=20
> public function action_edit() {
>   $form =3D $this->get_edit_form();
>   // spit out the form
> }
>=20
> public function action_save() {
>   // validate the form, process its inputs.
> }
>=20
> public function get_edit_form() {
>   // define and return the form, whose action is save
>   return $form;
> }
>=20
> Thoughts?
>=20
> 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 ]_________________________
>=20
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]

--Apple-Mail-E7B487BE-7BE2-4DB5-9403-626455ADB26B
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Your proposed approach seems reasonabl=
e and familiar to me.&nbsp;</div><div><br></div><div>- Chad</div><div><br>On=
 Apr 17, 2013, at 8:20 AM, Shad Laws &lt;<a href=3D"mailto:shad-xpYdmXCiSuZWk0Htik3J/[email protected]=
">shad-xpYdmXCiSuZWk0Htik3J/[email protected]</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><d=
iv>Hey everyone,<div><br></div><div>I'm starting to gear up for the big K2 Fo=
rge -&gt; K3 Formo conversion, and have a question: would it bother anyone t=
o 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 priv=
ate function that's called by the main controller action)</div><div>

- form validation/implementation in controller, form definition in helper (i=
n a public function that's called by the main controller action)</div><div><=
br></div><div>Personally, I prefer the former configuration. &nbsp;While I r=
ealize it may bug a few folks to have all form info in controllers (form han=
dling with pure MVC separation isn't straightforward), I find it simpler to h=
ave the code that defines the fields sitting in the same place as the code t=
hat uses those field definitions to validate and/or implement user input.</d=
iv>

<div><br></div><div>Also, in K3 we don't need to make controller functions p=
rivate to hide them from url access. &nbsp;We can leave them public and give=
 them non-action names.</div><div><br></div><div>So, my proposal is to do so=
mething like this in the controller:</div>

<div><br></div><div><font face=3D"courier new, monospace">public function ac=
tion_edit() {</font></div><div><font face=3D"courier new, monospace">&nbsp; $=
form =3D $this-&gt;get_edit_form();</font></div><div><font face=3D"courier n=
ew, monospace">&nbsp; // 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, mon=
ospace">public function action_save() {</font></div><div><font face=3D"couri=
er new, monospace">&nbsp; // 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, mon=
ospace">public function get_edit_form() {</font></div><div><font face=3D"cou=
rier new, monospace">&nbsp; // define and return the form, whose action is s=
ave</font></div>

<div><font face=3D"courier new, monospace">&nbsp; return $form;</font></div>=
<div><font face=3D"courier new, monospace">}</font></div><div><br></div><div=
>Thoughts?</div><div><br></div><div>Take care,</div><div>Shad</div>
</div></blockquote><blockquote type=3D"cite"><div><span>--------------------=
----------------------------------------------------------</span><br><span>P=
recog is a next-generation analytics platform capable of advanced</span><br>=
<span>analytics on semi-structured data. The platform includes APIs for buil=
ding</span><br><span>apps and a phenomenal toolset for data science. Develop=
ers can use</span><br><span>our toolset for easy data analysis &amp; visuali=
zation. Get a free account!</span><br><span><a href=3D"http://www2.precog.co=
m/precogplatform/slashdotnewsletter">http://www2.precog.com/precogplatform/s=
lashdotnewsletter</a></span></div></blockquote><blockquote type=3D"cite"><di=
v><span>__[ g a l l e r y - d e v e l ]_________________________</span><br><=
span></span><br><span>[ list info/archive --&gt; <a href=3D"http://gallery.s=
f.net/lists.php">http://gallery.sf.net/lists.php</a> ]</span><br><span>[ gal=
lery info/FAQ/download --&gt; <a href=3D"http://gallery.sf.net">http://galle=
ry.sf.net</a> ]</span></div></blockquote></body></html>=

--Apple-Mail-E7B487BE-7BE2-4DB5-9403-626455ADB26B--


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