Extending formats
11 views
Skip to first unread message
Chris Boden
Mar 26, 2011, 7:13:17 PM3/26/11
to Alloy
I would like to be able to handle more formats than what Alloy accepts
by default (.html, .json, .xml).
For example, if I'm doing a PHP tutorial site I'd want the ability for
the user to add .phps to the end of a page to see the source code of
the page/example.
I believe technically the Layout Plugin isn't part of the Alloy core,
so there's nothing wrong with modifying it on my own?
I was thinking something along the lines of adding a layout
"app.phps.php" to format said extension would be the most elegant
solution (not doable at the point in time).
Thoughts on the issue/solution?
by default (.html, .json, .xml).
For example, if I'm doing a PHP tutorial site I'd want the ability for
the user to add .phps to the end of a page to see the source code of
the page/example.
I believe technically the Layout Plugin isn't part of the Alloy core,
so there's nothing wrong with modifying it on my own?
I was thinking something along the lines of adding a layout
"app.phps.php" to format said extension would be the most elegant
solution (not doable at the point in time).
Thoughts on the issue/solution?
Vance Lucas
Mar 28, 2011, 1:12:02 PM3/28/11
to allo...@googlegroups.com
Yes, a solution is to make your own Plugin to handle the display for that particular extension type.
It does seem like the Layout plugin should wrap other generic response types as well though. Currently it explicitly checks if the format is html, and doesn't wrap a layout if it's not.
--
Vance Lucas
http://vancelucas.com
Chris Boden
Mar 28, 2011, 9:12:24 PM3/28/11
to Alloy
Hey, this doesn't work. Let me have leave a detailed response with
all the logical information required to fix it!
Merge this pull request: https://github.com/alloyphp/alloy/pull/10
Specifically commit: https://github.com/cboden/alloy/commit/e817eabd0a96d878fa42d19d7504343f6cd13416
I've removed the hard code html/json/xml checks and abstracted them
into their own layout wrapper files. I've altered the layout plugin
to check and use the appropriate layout if found. I added a new
method (verify()) to the Template class to check if the file (layout
or view) exists first.
An exception is thrown when an invalid format is called. This also
fixed another issue I had where my dispatch_exception didn't filter.
P.S. Sorry for the 4 garbage commits...I was trying to get our
changes from Kernel::dispatchRequest into my fork and it took me 4
commits for some reason. Git is still new to me.
On Mar 28, 1:12 pm, Vance Lucas <va...@vancelucas.com> wrote:
> Yes, a solution is to make your own Plugin to handle the display for that
> particular extension type.
>
> It does seem like the Layout plugin should wrap other generic response types
> as well though. Currently it explicitly checks if the format is html, and
> doesn't wrap a layout if it's not.
>
> --
> Vance Lucashttp://vancelucas.com
all the logical information required to fix it!
Merge this pull request: https://github.com/alloyphp/alloy/pull/10
Specifically commit: https://github.com/cboden/alloy/commit/e817eabd0a96d878fa42d19d7504343f6cd13416
I've removed the hard code html/json/xml checks and abstracted them
into their own layout wrapper files. I've altered the layout plugin
to check and use the appropriate layout if found. I added a new
method (verify()) to the Template class to check if the file (layout
or view) exists first.
An exception is thrown when an invalid format is called. This also
fixed another issue I had where my dispatch_exception didn't filter.
P.S. Sorry for the 4 garbage commits...I was trying to get our
changes from Kernel::dispatchRequest into my fork and it took me 4
commits for some reason. Git is still new to me.
On Mar 28, 1:12 pm, Vance Lucas <va...@vancelucas.com> wrote:
> Yes, a solution is to make your own Plugin to handle the display for that
> particular extension type.
>
> It does seem like the Layout plugin should wrap other generic response types
> as well though. Currently it explicitly checks if the format is html, and
> doesn't wrap a layout if it's not.
>
> --
Vance Lucas
Mar 29, 2011, 10:20:32 AM3/29/11
to allo...@googlegroups.com
Nice work!
I see you saw my tweet earlier :).
That particular tweet of frustration was mostly at the Android Market. "This app crashes on a Galaxy Tab that isn't even supported by the app. 1 star!". "This sucks, doesn't so everything I want. 1 star!". Certainly none of that was aimed towards Alloy or the community here :).
As for the actual code, like I said - nice work. I was thinking of doing almost the same thing - adding a template exists check and an exception as a way of allowing multiple formats. The only thing I might add is a new Exception class specifically for a non-existing format so that it can be caught and handled with the filter system to allow dynamic type conversions or outputs.
I'll look it over a bit more and do some testing with it myself later today. I have a few meetings this morning that will tie me up a bit.
Chris Boden
Mar 29, 2011, 10:37:04 AM3/29/11
to Alloy
hahaha, I wasn't sure! My thinking was either a) "Well, I didn't
think I was being that unhelpful, but I'm happy to contribute with a
little direction" or b) "Maybe tweet was about something else and
he'll get a kick out of this comment".
Good suggestion about a different Exception, I like it. I was getting
frustrated in my application when I would do a try/catch around a
verify() and my `dispatch_exception` filter was handling the error
instead of my catch block! Your suggestion should fix that.
I think my code is a good start, we can improve, refine and polish
it. I'm going to wait until you've moved/modified any of it into your
repository till I do any more work on it. Let me know if you'd like
me to make any adjustments to it.
> I see you saw my tweet earlier :).http://twitter.com/vlucas/status/52471792450805760
think I was being that unhelpful, but I'm happy to contribute with a
little direction" or b) "Maybe tweet was about something else and
he'll get a kick out of this comment".
Good suggestion about a different Exception, I like it. I was getting
frustrated in my application when I would do a try/catch around a
verify() and my `dispatch_exception` filter was handling the error
instead of my catch block! Your suggestion should fix that.
I think my code is a good start, we can improve, refine and polish
it. I'm going to wait until you've moved/modified any of it into your
repository till I do any more work on it. Let me know if you'd like
me to make any adjustments to it.
> I see you saw my tweet earlier :).http://twitter.com/vlucas/status/52471792450805760
>
> That particular tweet of frustration was mostly at the Android Market. "This
> app crashes on a Galaxy Tab that isn't even supported by the app. 1 star!".
> "This sucks, doesn't so everything I want. 1 star!". Certainly none of that
> was aimed towards Alloy or the community here :).
>
> As for the actual code, like I said - nice work. I was thinking of doing
> almost the same thing - adding a template exists check and an exception as a
> way of allowing multiple formats. The only thing I might add is a new
> Exception class specifically for a non-existing format so that it can be
> caught and handled with the filter system to allow dynamic type conversions
> or outputs.
>
> I'll look it over a bit more and do some testing with it myself later today.
> I have a few meetings this morning that will tie me up a bit.
>
> --
> Vance Lucashttp://vancelucas.com
> That particular tweet of frustration was mostly at the Android Market. "This
> app crashes on a Galaxy Tab that isn't even supported by the app. 1 star!".
> "This sucks, doesn't so everything I want. 1 star!". Certainly none of that
> was aimed towards Alloy or the community here :).
>
> As for the actual code, like I said - nice work. I was thinking of doing
> almost the same thing - adding a template exists check and an exception as a
> way of allowing multiple formats. The only thing I might add is a new
> Exception class specifically for a non-existing format so that it can be
> caught and handled with the filter system to allow dynamic type conversions
> or outputs.
>
> I'll look it over a bit more and do some testing with it myself later today.
> I have a few meetings this morning that will tie me up a bit.
>
> --
>
>
>
> On Mon, Mar 28, 2011 at 8:12 PM, Chris Boden <cbo...@gmail.com> wrote:
> > Hey, this doesn't work. Let me have leave a detailed response with
> > all the logical information required to fix it!
>
> > Merge this pull request:https://github.com/alloyphp/alloy/pull/10
> > Specifically commit:
> >https://github.com/cboden/alloy/commit/e817eabd0a96d878fa42d19d750434...
>
>
> On Mon, Mar 28, 2011 at 8:12 PM, Chris Boden <cbo...@gmail.com> wrote:
> > Hey, this doesn't work. Let me have leave a detailed response with
> > all the logical information required to fix it!
>
> > Merge this pull request:https://github.com/alloyphp/alloy/pull/10
> > Specifically commit:
Vance Lucas
Mar 30, 2011, 7:38:12 PM3/30/11
to allo...@googlegroups.com
Sorry I have not had much of a chance to respond. It has been answer unexpectedly busy week. I should be able to test this and update tomorrow.
On Mar 29, 2011 9:37 AM, "Chris Boden" <cbo...@gmail.com> wrote:
hahaha, I wasn't sure! My thinking was either a) "Well, I didn't
think I was being that unhelpful, but I'm happy to contribute with a
little direction" or b) "Maybe tweet was about something else and
he'll get a kick out of this comment".
Good suggestion about a different Exception, I like it. I was getting
frustrated in my application when I would do a try/catch around a
verify() and my `dispatch_exception` filter was handling the error
instead of my catch block! Your suggestion should fix that.
I think my code is a good start, we can improve, refine and polish
it. I'm going to wait until you've moved/modified any of it into your
repository till I do any more work on it. Let me know if you'd like
me to make any adjustments to it.
On Mar 29, 10:20 am, Vance Lucas <va...@vancelucas.com> wrote:
> Nice work!
>
> I see you saw my tw...
> Vance Lucashttp://vancelucas.com
>
>
>
> On Mon, Mar 28, 2011 at 8:12 PM, Chris Boden <cbo...@gmail.com> wrote:
> > Hey, this doesn't...
> >https://github.com/cboden/alloy/commit/e817eabd0a96d878fa42d19d750434...
>
> > I've removed the hard code html/json/xml checks and abstracted them
> > into their own layout ...
Chris Boden
Mar 31, 2011, 10:42:56 AM3/31/11
to Alloy
No problem. I've encountered a hiccup with my proposed PR (pull
request). Scenario:
http://localhost/test.txt. A successful route_match and
dispatch_content are called, the Module attempts to create and returns
a Template. The view file "test.txt.php" does exist. The "/app/
layout/app.txt.php" does not exist. An "global" exception is
thrown.
Because when Event::filter('dispatch_content', 'alloy_layout_wrap') is
called, if an exception is thrown inside the filter call the event
handler does not re-throw the exception, it returns the exception;
thus a try/catch block in the original Module will not work.
So, given the first paragraph scenario, what SHOULD happen? If a view
format exists but not a layout, should the system treat it as an error
or should the application work. Next, assuming you're going to
determine it should work; should the application be aware there is not
layout wrapper for that format; as in, should an exception be thrown
back or silently fail?
Before my PR, this scenario worked, now it doesn't for above reason.
So, after typing this all out, I've realized I answered my own
question: that my PR broke a piece of functionality; I think I
understand how it SHOULD work, now a solution needs to be found on how
to MAKE it work.
Flow:
/www/index.php (85) -> $content from Module is gravy
/www/index.php (96): -> $content is an Exception
Ok. I've updated my PR with another commit so that the layout Plugin
returns $content if the wrapper isn't found, instead of throwing an
exception.
Problem solved. Sorry for my rant, I was trying to explain a problem
I had trouble figuring out, and ended up solving it as I typed it.
request). Scenario:
http://localhost/test.txt. A successful route_match and
dispatch_content are called, the Module attempts to create and returns
a Template. The view file "test.txt.php" does exist. The "/app/
layout/app.txt.php" does not exist. An "global" exception is
thrown.
Because when Event::filter('dispatch_content', 'alloy_layout_wrap') is
called, if an exception is thrown inside the filter call the event
handler does not re-throw the exception, it returns the exception;
thus a try/catch block in the original Module will not work.
So, given the first paragraph scenario, what SHOULD happen? If a view
format exists but not a layout, should the system treat it as an error
or should the application work. Next, assuming you're going to
determine it should work; should the application be aware there is not
layout wrapper for that format; as in, should an exception be thrown
back or silently fail?
Before my PR, this scenario worked, now it doesn't for above reason.
So, after typing this all out, I've realized I answered my own
question: that my PR broke a piece of functionality; I think I
understand how it SHOULD work, now a solution needs to be found on how
to MAKE it work.
Flow:
/www/index.php (85) -> $content from Module is gravy
/www/index.php (96): -> $content is an Exception
Ok. I've updated my PR with another commit so that the layout Plugin
returns $content if the wrapper isn't found, instead of throwing an
exception.
Problem solved. Sorry for my rant, I was trying to explain a problem
I had trouble figuring out, and ended up solving it as I typed it.
Vance Lucas
Mar 31, 2011, 2:42:13 PM3/31/11
to allo...@googlegroups.com
Thanks for your work on this. I merged in your code with my own:
I will do some additional testing on it shortly.
Chris Boden
Mar 31, 2011, 2:51:16 PM3/31/11
to Alloy
My pleasure.
I made a small adjustment to your adjustments (https://github.com/
alloyphp/alloy/pull/11).
I will do more testing when I get some time as well.
On Mar 31, 2:42 pm, Vance Lucas <va...@vancelucas.com> wrote:
> Thanks for your work on this. I merged in your code with my own:https://github.com/alloyphp/alloy/commit/06cfd3f3f044ac937fece02dbf31...
I made a small adjustment to your adjustments (https://github.com/
alloyphp/alloy/pull/11).
I will do more testing when I get some time as well.
On Mar 31, 2:42 pm, Vance Lucas <va...@vancelucas.com> wrote:
> Thanks for your work on this. I merged in your code with my own:https://github.com/alloyphp/alloy/commit/06cfd3f3f044ac937fece02dbf31...
>
> I will do some additional testing on it shortly.
>
> --
> Vance Lucashttp://vancelucas.com
> I will do some additional testing on it shortly.
>
> --
Vance Lucas
Mar 31, 2011, 3:44:45 PM3/31/11
to allo...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages