Remove the setView from Aura Framework AbstractPage.php

[Hari K T]

Hey guys,

I was trying to incorporate Twig with Aura . 

I feel its a good idea to remove the setView from Aura Framework AbstractPage.php . 

And we can extend this class to make any type of view . 

Else I feel it will be binded with Aura.View and Di will try to inject it . As we are using another view , I feel the user don't need Aura.View itself .

If we are not moving that particular method , the users needs to copy almost the same methods .

Is there any better way to do else ?

You can see still a work / try in progress 

https://gist.github.com/2345593

Let me know your thoughts on this . As I don't want to break the API , I feel we can make this AbstractPage as the base itself and add another class as a middle one .

Thanks

Hari K T
M: +91-9388758821 | W: http://harikt.com/blog

[Paul M. Jones]

This is an interesting problem.

As a bit of background, the idea of the Aura.Framework package is to provide the glue between the various Aura packages and bind them into a coherent framework.

Now, I can see where people would want to switch out the view engine and use the one of their choice (e.g. Twig). We could in theory allow for that by changing the signature of `setView()` from `setView(TwoStep $view)` to just `setView($view)`. Then you could extend the AbstractPage and override the `setView()` method, without getting an E_STRICT error about the signature. You'd need to override `render()`, too.

However, I can also see where people would want to use their own signaling mechanism, too. That would mean changing setSignal(), along with all the methods that use a call to `$this->signal`.

And for the router.

And for the inflector.

So, while it seems like we should "make room" for other view engines in Aura\Framework\Web\AbstractPage, it opens the door to a lot of other things that would be difficult to be flexible for.

Maybe the real answer to all this is to extract the routing, inflecting, etc. behaviors to completely separate objects, but that is a level of abstraction that I'm not ready to tackle right now.

I'm happy to continue the discussion, though; I (or someone else) may think of a good solution here.

Hope that all makes sense.

-- pmj

[Hari K T]

Hari K T
M: +91-9388758821 | W: http://harikt.com/blog

On Tue, Apr 10, 2012 at 8:49 AM, Paul M. Jones <pmjo...@gmail.com> wrote:

On Apr 9, 2012, at 7:54 PM, Hari K T wrote:

> Hey guys,
>
> I was trying to incorporate Twig with Aura .
>
> I feel its a good idea to remove the setView from Aura Framework AbstractPage.php .
>
> And we can extend this class to make any type of view .
>
> Else I feel it will be binded with Aura.View and Di will try to inject it . As we are using another view , I feel the user don't need Aura.View itself .
>
> If we are not moving that particular method , the users needs to copy almost the same methods .
>
> Is there any better way to do else ?
>
> You can see still a work / try in progress
>
> https://gist.github.com/2345593
>
> Let me know your thoughts on this . As I don't want to break the API , I feel we can make this AbstractPage as the base itself and add another class as a middle one .

This is an interesting problem.

As a bit of background, the idea of the Aura.Framework package is to provide the glue between the various Aura packages and bind them into a coherent framework.

Now, I can see where people would want to switch out the view engine and use the one of their choice (e.g. Twig).  We could in theory allow for that by changing the signature of `setView()` from `setView(TwoStep $view)` to just `setView($view)`.  Then you could extend the AbstractPage and override the `setView()` method, without getting an E_STRICT error about the signature.  You'd need to override `render()`, too.

But in Twig or may be other templating engines need more stuffs to pass .

For eg :

$loader = new Twig_Loader_Filesystem('/path/to/templates');
$twig = new Twig_Environment($loader, array(
'cache' => '/path/to/compilation_cache',
));

echo $twig->render('index.html', array('name' => 'Fabien'));

We may want to pass loader also . So I can setPaths() to of templates to loader .

So I feel removing 'setView(TwoStep $view)' to 'setView()' doesn't have much affect .
 

However, I can also see where people would want to use their own signaling mechanism, too.  That would mean changing setSignal(), along with all the methods that use a call to `$this->signal`.

And for the router.

And for the inflector.

Yes I understood . But I am not sure whether anyone love to change the Aura router :-) . Anyway that's another use  case .

Also I am not sure whether people need more Signals than the one currently we have . Not sure , again it can be another use case .
 

So, while it seems like we should "make room" for other view engines in Aura\Framework\Web\AbstractPage, it opens the door to a lot of other things that would be difficult to be flexible for.

Maybe the real answer to all this is to extract the routing, inflecting, etc. behaviors to completely separate objects, but that is a level of abstraction that I'm not ready to tackle right now.

I'm happy to continue the discussion, though; I (or someone else) may think of a good solution here.

Hope that all makes sense.


-- pmj

Yes understood . I was just thinking about the view at the time, and thought of it .

Also about the getContentType()

$this->response->setContentType($this->view->getContentType());

May be every view need to create the getContentType() also . Lets see :-)

Thank you

Hari K T

[Hari K T]

Hi Guys,

Lately we discussed about incorporating Twig . May be you are interested in Mustache or Smarty or Dwoo ;-) or something new .

I thought for a while with the ideas of Paul M Jones and looking through some other stuffs and reading I got some idea . The base idea is as what pmjones has mentioned itself .

This is an interesting problem.

As a bit of background, the idea of the Aura.Framework package is to provide the glue between the various Aura packages and bind them into a coherent framework.

Now, I can see where people would want to switch out the view engine and use the one of their choice (e.g. Twig).  We could in theory allow for that by changing the signature of `setView()` from `setView(TwoStep $view)` to just `setView($view)`.  Then you could extend the AbstractPage and override the `setView()` method, without getting an E_STRICT error about the signature.  You'd need to override `render()`, too.

However, I can also see where people would want to use their own signaling mechanism, too.  That would mean changing setSignal(), along with all the methods that use a call to `$this->signal`.

And for the router.

And for the inflector.

So, while it seems like we should "make room" for other view engines in Aura\Framework\Web\AbstractPage, it opens the door to a lot of other things that would be difficult to be flexible for.

Maybe the real answer to all this is to extract the routing, inflecting, etc. behaviors to completely separate objects, but that is a level of abstraction that I'm not ready to tackle right now.

So this is what I am thinking from the thoughts as of now .

namespace Aura\Framework;

interface View
{
    public function addInnerPath();
    public function addOuterPath();
    public function setFormat()
    public function setInnerData(array $data)
    public function render()
}


namespace Aura\Framework;
class TwigView implements View
{
   
}

namespace Aura\Framework;
class MustacheView implements View
{
   
}

And also same with an interface for Router, Signal and Inflect.

Thoughts?

I feel this helps people not to create another framework package itself :-) .

 

[Hari K T]

aah once again myself :-)

The problem I noticed now is we need object of FormatTypes

But currently its in Aura.View .  So that makes it dependent on Aura.View .

If we copy it to Aura.Framework , it breaks the KISS when we are using Aura.View .

May be we want to keep it as another package itself?

Or do we want to make a branch for each rendering Aura.Framework package ?

[Hari K T]

Hey Guys ,

I did something creating a new Package ;) .

The other way I don't feel it will work out . It has some limitations . So I feel a new package is good and it has no issues for system :) .

May be if anyone interested , have a look 

https://github.com/harikt/Hari.Render

Still more to do , but I am happy to hear your suggestions , thoughts on this . If anyone has a good idea to make it more better I welcome you to provide some suggestions .

If anyone has earlier worked with mustache has some insights / thoughts I am interested to hear , how we can make use of this . 

Currently I have added the stuffs I feel is needed for both .

Anyway you are free to criticize / suggest . I will hear you .

Hari K T
M: +91-9388758821 | W: http://harikt.com/blog

[Paul M. Jones]

On May 30, 2012, at 1:50 AM, Hari K T wrote:

> Hi Guys,
>
> Lately we discussed about incorporating Twig . May be you are interested in Mustache or Smarty or Dwoo ;-) or something new .

Here's a random thought:

Maybe what we need here is a RenderStrategy class (this would be a new class in the Web package). By default, it does nothing. Then instead of setView() and a render() method, we have a setRenderStrategy() in the controller, and pass in a RenderStrategy object of our choosing. The render() method then just calls the RenderStrategy and hands off to it entirely. Voila: you can have an AuraViewRender, a TwigRender, a MustacheRender, etc.

Might be a good idea, might not.


-- pmj

[Hari K T]

Hey ,

Maybe what we need here is a RenderStrategy class (this would be a new class in the Web package).  By default, it does nothing.  Then instead of setView() and a render() method, we have a setRenderStrategy() in the controller, and pass in a RenderStrategy object of our choosing.  The render() method then just calls the RenderStrategy and hands off to it entirely.  Voila: you can have an AuraViewRender, a TwigRender, a MustacheRender, etc.

But I wonder about the FormatTypes class . Currently its looking for the format from that which is in Aura.View and which we cannot move for its already view related .

Anyway I look forward for the way you are implementing it .
 

[Hari K T]

Hey Guys, 

I did some experiments today .. Probably not the best, but still something interesting :-)

Not sure @pmjones did told to do this way or may be there is better way .

Its currently in render branch 

https://github.com/harikt/Aura.Web/tree/render

https://github.com/harikt/Aura.Framework/tree/render

https://github.com/harikt/Hari.Blog

Currently only Twig I have written , for the other Aura.View in mind , and all other can be incorporated easily .

If you have any other suggestions I can also try that way, else we can move fwd this way .

Thoughts ?

Hari K T
M: +91-9388758821 | W: http://harikt.com/blog

[Hari K T]

Hey Guys, 

It seems I did some interesting stuffs ( probably a different idea / thought ) for rendering. But there is some issue I am facing , so not sure whether we can call an interesting stuff :D .

The idea is to incorporate different rendering in different package .

I have 

Hari.Contact , Hari.Blog as samples .

Hari.Contact uses Twig to Render 

Hari.Blog is trying to use Aura.View .

I made a vague , not that much good , but still something where Twig works fine . 

The only issue currently is Aura.View TwoStep object seems setting in setRenderEngine twice .

So this creates a problem , we are first setting the inner data and getting innerdata there is no issues. But when calling render, the innerdata is empty .

If anyone can help me trace it , then it seems awesome to go ? No ?

https://github.com/harikt/Hari.Blog/commit/db495edc34a0cf4d55bfe65172cb5ba249aa7d7d

https://github.com/harikt/Aura.Web/commit/b6d132ae5781666a74a68ded304381b6e0fc4560

https://github.com/harikt/Aura.Framework/commit/de442fdafa5b050064fb9879a5cb2333689dff4e

[Hari K T]

Hey Guys, 

Good news :-) . All works in a charm , it was an issue with as previously noted , but not fixed in

https://github.com/auraphp/Aura.Framework/issues/6

https://github.com/auraphp/Aura.Framework/pull/8

I spend a lot of time wondering it was issue with something else .

Now play with 

https://github.com/harikt/Aura.Framework/tree/render

https://github.com/harikt/Aura.Web/tree/render

https://github.com/harikt/Hari.Blog

https://github.com/harikt/Hari.Contact

I feel its ok, any different thougts or a better implementation I am happy to hear .

I also loved if we can move this to next Beta release .

This way we can set a new view without having any issues to controller code .

If you don't love twig at some point you can switch to Aura.View, Mustache implementation easily. Also this brings a new flexibility of using different rendering engine in a package :-)

Let me know your comments / concerns / critism .

Thanks

[Hari K T]

Not sure but I was wondering whether we need traits here ?

[Hari K T]

Not sure how many of you got time to look into it .

So I created a review for it at

https://codetique.com/OAs1NovY

If you have any issues with the classes , naming convention , methods etc , you can comment on it anonymously . Throw some stone at me guys :-) . I welcome feedback :D .

[Hari K T]

So I was thinking what will happen when the accept header asks for json ?

That means our view script name needs some change or probably a different way .

For eg :

public function actionHello()
{
}

May need to render json , html , xml or any format .

So the render() probably need to have

viewname.<format>.php ,
viewname.<format>.twig ,
viewname.<format>.mustache

Or may be a different way ?

Wondering !

Sorry for mailing frequently . This makes an end :-) until I hear / come up with new implementation .

Hari K T
M: +91-9388758821 | W: http://harikt.com/blog