Re: [Gallery3] Unit test updates

--===============1997812286050059897==
Content-Type: multipart/alternative; boundary=001a11c1de30f13d9604e01c5ac6

--001a11c1de30f13d9604e01c5ac6
Content-Type: text/plain; charset=UTF-8

Hey Bharat,

(replying inline and snipping a bit...)

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.
>

Different than K2, yes, but it actually works pretty well here.  There are
a few steps to routing:
- Run gallery_ready.  Here, we define the routes, which are how we parse
URIs into controller, action, etc.
- Run Request::factory(), return a Request object.  This builds the
request, gets the URI, but does *not* actually parse it and get controller,
action, etc.
- Run initial_request_ready.   Here, we can change the URI as our hearts
desire, before anyone else has gotten a chance to do anything with it.
- Run ->execute(), return a Response object.  This parses the URI, loads up
a controller, runs it, and returns its Response.

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.
>
>
It turns out this was a slightly deeper rabbit hole than I originally
thought... see other email chain.

No worries on being low on time!  Bon voyage :-)

Take care,
Shad

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

Hey Bharat,<div><br></div><div>(replying inline and snipping a bit...)</div=
><div><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">

<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div>Here&#39;s my sketch of the end of index.php:</div><div><br>=
</div>

<div><div><div><font face=3D"courier new, monospace">// Initialize the fram=
ework.</font></div><div><font face=3D"courier new, monospace">require APPPA=
TH . &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">=C2=A0 -&gt;send_headers(true)</font></div>





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

</div></div></div></blockquote><div><br></div><div>Different than K2, yes, =
but it actually works pretty well here. =C2=A0There are a few steps to rout=
ing:</div><div>- Run gallery_ready. =C2=A0Here, we define the routes, which=
 are how we parse URIs into controller, action, etc.</div>

<div>- Run Request::factory(), return a Request object. =C2=A0This builds t=
he request, gets the URI, but does *not* actually parse it and get controll=
er, action, etc.</div><div>- Run initial_request_ready. =C2=A0 Here, we can=
 change the URI as our hearts desire, before anyone else has gotten a chanc=
e to do anything with it.</div>

<div>- Run -&gt;execute(), return a Response object. =C2=A0This parses the =
URI, loads up a controller, runs it, and returns its Response.</div><div><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>But, this did show me an odd wrinkle with m=
odule events: the module order seems weird.</div>

<div>- active modules list: purifier, high_priority_module, low_priority_mo=
dule, gallery =C2=A0 (same as Kohana&#39;s list)</div>



<div>- current event order: gallery, purifier, high_priority_module, low_pr=
iority_module =C2=A0 (put gallery first, leave rest as-is)</div><div>- prop=
osed event order: gallery, low_priority_module, high_priority_module, purif=
ier =C2=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. =C2=A0Is there a reason we don&#39;t already do it this way?<=
/div>





<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>What order did we do it in for K2? =C2=A0I can&#39;t r=
ecall. =C2=A0But I had a rationale for it then and we should try to preserv=
e it (or at least understand it!). =C2=A0Sorry for the short reply - I&#39;=
m travelling and low on time.=C2=A0</div>



</div><br></div></div>
</blockquote></div><br></div><div>It turns out this was a slightly deeper r=
abbit hole than I originally thought... see other email chain.</div><div><b=
r></div><div>No worries on being low on time! =C2=A0Bon voyage :-)</div><di=
v>

<br></div><div>Take care,</div><div>Shad</div>

--001a11c1de30f13d9604e01c5ac6--


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