Re: [Gallery3] Unit test updates

--===============2993289288800417741==
Content-Type: multipart/alternative; boundary=047d7b5d574e808e3004e0172cd2

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

On Mon, Jun 24, 2013 at 3:07 AM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:

> Hey Bharat,
>
> Hmm, I'm not sure I see routing and execution as one inseparable unit.  It
> seems to me that they decided to remove their event handler and instead
> make the cascading file system (which has far less exceptions to rules than
> before) and the config file system beefier to pick up the slack.  For
> example, extending the Controller class as we do is a nice way to split the
> two.  Alternatively, we can just generate the request and wait a tick
> before executing it.
>
> Here's my sketch of the end of index.php:
>
> // Initialize the framework.
> require APPPATH . "bootstrap" . EXT;
>
> // Initialize the Gallery modules.
> register_shutdown_function("Module::event", "shutdown");
> Module::event("gallery_ready");
>
> // Build the initial request.
> $request = Request::factory(true, array(), false);
> Module::event("initial_request_ready");
>
> // Generate and send the response.
> echo $request->execute()
>   ->send_headers(true)
>   ->body();
>

As I understand it, the routing decision happens in Request::execute() so
at the initial_request_ready point in your sketch, routing hasn't happened.
 So modules can't change the route, or at least not the way that we did in
K2.


> The functions Gallery::ready() and Gallery::shutdown() are removed, as
> they were just one-line wrappers around their respective module events.  I
> like this more direct approach.
>

Sounds good.


>
> But, this did show me an odd wrinkle with module events: the module order
> seems weird.
> - active modules list: purifier, high_priority_module,
> low_priority_module, gallery   (same as Kohana's list)
> - current event order: gallery, purifier, high_priority_module,
> low_priority_module   (put gallery first, leave rest as-is)
> - proposed event order: gallery, low_priority_module,
> high_priority_module, purifier   (reverse of active list, same as Kohana's
> config file search)
>
> In other words, I think it should be changed to run the events in reverse
> module order, thereby giving the high-priority modules the last word.  Is
> there a reason we don't already do it this way?
>
> Among other advantages, if we can change this, then the routes get loaded
> in the right order :-).
>
>
What order did we do it in for K2?  I can't recall.  But I had a rationale
for it then and we should try to preserve it (or at least understand it!).
 Sorry for the short reply - I'm travelling and low on time.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, Jun 24, 2013 at 3:07 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> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hey Bharat,<div><br></div><div>Hmm, I&#39;m =
not sure I see routing and execution as one inseparable unit. =A0It seems t=
o me that they decided to remove their event handler and instead make the c=
ascading file system (which has far less exceptions to rules than before) a=
nd the config file system beefier to pick up the slack. =A0For example, ext=
ending the Controller class as we do is a nice way to split the two. =A0Alt=
ernatively, we can just generate the request and wait a tick before executi=
ng it.</div>



<div><br></div><div>Here&#39;s my sketch of the end of index.php:</div><div=
><br></div><div><div class=3D"im"><div><font face=3D"courier new, monospace=
">// Initialize the framework.</font></div><div><font face=3D"courier new, =
monospace">require APPPATH . &quot;bootstrap&quot; . EXT;</font></div>



<div><font face=3D"courier new, monospace"><br></font></div></div><div><fon=
t face=3D"courier new, monospace">// Initialize the Gallery modules.</font>=
</div><div><font face=3D"courier new, monospace">register_shutdown_function=
(&quot;Module::event&quot;, &quot;shutdown&quot;);</font></div>



<div><font face=3D"courier new, monospace">Module::event(&quot;gallery_read=
y&quot;);</font></div><div><font face=3D"courier new, monospace"><br></font=
></div><div><font face=3D"courier new, monospace">// Build the initial requ=
est.</font></div>



<div><font face=3D"courier new, monospace">$request =3D Request::factory(tr=
ue, array(), false);</font></div><div><font face=3D"courier new, monospace"=
>Module::event(&quot;initial_request_ready&quot;);</font></div><div><font f=
ace=3D"courier new, monospace"><br>



</font></div><div><font face=3D"courier new, monospace">// Generate and sen=
d the response.</font></div><div><font face=3D"courier new, monospace">echo=
 $request-&gt;execute()</font></div><div><font face=3D"courier new, monospa=
ce">=A0 -&gt;send_headers(true)</font></div>



<div><font face=3D"courier new, monospace">=A0 -&gt;body();</font></div></d=
iv></blockquote><div><br></div><div style>As I understand it, the routing d=
ecision happens in Request::execute() so at the initial_request_ready point=
 in your sketch, routing hasn&#39;t happened. =A0So modules can&#39;t chang=
e the route, or at least not the way that we did in K2.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div>The functions Gallery::re=
ady() and Gallery::shutdown() are removed, as they were just one-line wrapp=
ers around their respective module events. =A0I like this more direct appro=
ach.</div>

</blockquote><div><br></div><div style>Sounds good.</div><div style>=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">

<div><br></div><div>But, this did show me an odd wrinkle with module events=
: the module order seems weird.</div><div>- active modules list: purifier, =
high_priority_module, low_priority_module, gallery =A0 (same as Kohana&#39;=
s list)</div>



<div>- current event order: gallery, purifier, high_priority_module, low_pr=
iority_module =A0 (put gallery first, leave rest as-is)</div><div>- propose=
d event order: gallery, low_priority_module, high_priority_module, purifier=
 =A0 (reverse of active list, same as Kohana&#39;s config file search)</div=
>



<div><br></div><div>In other words, I think it should be changed to run the=
 events in reverse module order, thereby giving the high-priority modules t=
he last word. =A0Is there a reason we don&#39;t already do it this way?</di=
v>



<div><br></div><div>Among other advantages, if we can change this, then the=
 routes get loaded in the right order :-).</div><div><br></div></blockquote=
><div><br></div><div style>What order did we do it in for K2? =A0I can&#39;=
t recall. =A0But I had a rationale for it then and we should try to preserv=
e it (or at least understand it!). =A0Sorry for the short reply - I&#39;m t=
ravelling and low on time.=A0</div>

</div><br></div></div>

--047d7b5d574e808e3004e0172cd2--


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

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
--===============2993289288800417741==
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 ]
--===============2993289288800417741==--