view resolvers discussion (new view factory, added halo_view_InternalResourceViewResolver)

[Beau Simensen]

I took a look at the view resolver handling this evening and I think I've come up with a nice solution.

I added the halo_view_InternalResourceViewResolver to the repository. It is actually very close to aek's initial solution with some spelling changes and abstracting about 95% of it to the halo_view_AbstractResourceViewResolver. I believe this should satisfy your needs, aek?

In testing this worked:

$context->add(array(

    'className' => 'halo_view_InternalResourceViewResolver',

    'properties' => array(

        'prefix' => './WebContent/WEB-INF/views/',

        'suffix' => '.php',

        'viewClass' => 'halo_view_skittle_SkittleUriView',

    ),

    'lazyLoad' => false,

));

You'll note that I created a new skittle view class specifically for this simple purpose. (source can be seen here: http://github.com/dflydev/halo-php/blob/master/lib/halo_view_skittle_SkittleUriView.php ) It extends halo_view_AbstractUriView.

I realized that there was a pretty serious disconnect between some of the ideas I had for view resolving and the intention of some more simple URI based views. Like you said, aek, it hands the off to the view class and hopes for the best. (and error in case of missing is acceptable) While this isn't what I want, I realize this is preferable to some people.

On  my side of things, where maybe I want to do some more advanced configuration of the view class itself, I created halo_view_IViewFactory. This works perfectly for me and is a lot cleaner than the solution I was hacking together last night. The end result in this case is a completely different view class, halo_view_skittle_SkittleResourceLocatorView.

The philosophy here is different. Intention of this view resolver is to only return view objects if the view actually exists. Would adapter be a better name for this than factory? I am hoping that factory better portrays the intention.

$context->add('lithe.views.defaultViewResolver', array(

    'className' => 'halo_view_ViewFactoryResourceViewResolver',

    'constructorArgs' => array(

        'viewFactory' => $context->ref('lithe.views.skittle.viewFactory'),

    ),

    'properties' => array(

        'suffix' => '.php',

    ),

));

$context->add('lithe.views.skittle.viewFactory', array(

    'className' => 'halo_view_skittle_SkittleViewFactory',

    'constructorArgs' => array(

        'resourceLocator' => $context->ref('lithe.views.resourceLocator'),

    ),

));

The new halo_view_ViewFactoryResourceViewResolver follows mostly the same pattern as the internal resource view resolver with the exception that it accepts a view factory instead of a view class. The job of the view factory is to determine whether or not the request can be satisfied by the object the factory is capable of building and then building an instance of the view class for the request.

From halo_view_ViewFactoryResourceViewResolver:

    public function doResolveViewUri($viewUri, $viewName, halo_HttpRequest $httpRequest, halo_HttpResponse $httpResponse) {

        if ( $this->viewFactory->supports($viewUri, $viewName, $httpRequest, $httpResponse) ) {

            return $this->viewFactory->buildView($viewUri, $viewName, $httpRequest, $httpResponse);

        }

        return null;

    }

From halo_view_skittle_SkittleViewFactory:

    public function __construct(substrate_IResourceLocator $resourceLocator) {

        $this->substrateResourceLocatorAdapter = new halo_view_skittle_SubstrateResourceLocatorAdapter($resourceLocator);

    }

    public function supports($viewUri, $viewName, halo_HttpRequest $httpRequest, halo_HttpResponse $httpResponse) {

        if ( $this->substrateResourceLocatorAdapter->find($viewUri) ) {

            return true;

        }

        return false;

    }

    public function buildView($viewUri, $viewName, halo_HttpRequest $httpRequest, halo_HttpResponse $httpResponse) {

        return new halo_view_skittle_SkittleResourceLocatorView($viewUri, $this->substrateResourceLocatorAdapter);

    }

From halo_view_skittle_SkittleResourceLocatorView:

    public function __construct($uri, skittle_IResourceLocator $resourceLocator) {

        parent::__construct($uri);

        $this->resourceLocator = $resourceLocator;

    }

    public function render(array $model, halo_HttpRequest $httpRequest, halo_HttpResponse $httpResponse) {

        $skittle = new skittle_Skittle($this->resourceLocator);

        return $skittle->stringInc($this->uri, $model);

    }

--

Beau D. Simensen


Dragonfly Development Inc
http://dflydev.com/

[aek]

>I added the halo_view_InternalResourceViewResolver to the repository. It is
>actually very close to aek's initial solution with some spelling changes and
>abstracting about 95% of it to the halo_view_AbstractResourceViewResolver. I
>believe this should satisfy your needs, aek?

Yeah, Im happy to see that my contributions are goods, now I can be on
the standards of halo, the only thing that I notice is what is the
order to ask about if a view resolvers can resolve a view. In the
halo_view_InternalResourceViewResolver the resolve of the view didn't
allow to others view resolver to have a chance if he cannot resolve
the real path of the template successful

Another topic about views is that role of the viewResolver can be get
a configured stone of a view class that know everything about how to
render the response even when the view is uri path based or is some
other type of view such as a PDF, XML or any other view format that is
need to return as a response, that deals or not with a path Uri.

[Beau Simensen]

Yeah, Im happy to see that my contributions are goods

They are! I know I haven't been super fast at bringing them into the fold so I appreciate your patience. :) My first goal was to get a working system w/ new Substrate ( HTTP Request -> Substrate -> Halo -> (Lithe) -> Controller -> Skittle view -> Rendered HTML ) so that I knew everything was in place. Now I can start tightening things up and looking into things like your multi action controller.

the only thing that I notice is what is the order to ask about if a view resolvers can resolve a view. In the halo_view_InternalResourceViewResolver the resolve of the view didn't allow to others view resolver to have a chance if he cannot resolve the real path of the template successful

I'm not sure I am following what you are saying here, but I think it is one or both of the following:

How does Halo know which order to query the View Resolvers? This is a bug in the current implementation. The Dispatcher already tries to order them but the current View Resolver interface doesn't define the ordering. Remind me about this again in the next few days and I'll try to get the code updated so this will actually work. Basically, it leverages substrate_stones_IOrderedStone interface to get a setOrder()/order() method. This will allow you to specify (optionally) the order in which the things of that type will be sorted.

How does a View Resolver pass on resolving a view request / the Internal Resource View Resolver won't ever pass on resolving a request? If View Resolver passes back null, it has passed on resolving the view and that will let other View Resolvers have a chance at it. If you use something like Internal Resource View Resolver it will *always* pass back a view. So if you want to mix / chain View Resolvers you should make sure any View Resolver that does this would be ordered to run last.

Another topic about views is that role of the viewResolver can be get a configured stone of a view class that know everything about how to render the response even when the view is uri path based or is some other type of view such as a PDF, XML or any other view format that is need to return as a response, that deals or not with a path Uri.

Actually, this brings up a good point. I created Abstract Uri View for the base of Skittle Uri View and Skittle View Factory View as they both share the common theme of being URI based. Right now Internal Resource View Resolver is setup specifically to handle this type of view (it always assumes a URI is being pased) so what would you think about this:

Rename Internal Resource View Resolver to Internal Resource URI View Resolver ( halo_view_InternalResourceUriViewResolver ). I think this would be more clear. Would you have any objection to this? Or would "internal resource" be enough to indicate that it is likely a path URI being specified?

[aek]

InternalResourceViewResolver is the name in Spring MVC for a subclass
of UrlBasedViewResolver. The name isn't an issue for me. The internal
part of the name, seems to me that he know what kind of view use,
configured as a viewClass. I have no objection to the rename, just a
suggestion. What will make halo more attractive to future users is the
similarity with Spring MVC, that's how I found it.

> How does Halo know which order to query the View Resolvers?

That's what Im saying, the order of the viewResolvers is an very
important point.

[Beau Simensen]

OK, I'll stick with it!

--

Beau D. Simensen


Dragonfly Development Inc
http://dflydev.com/

--
You received this message because you are subscribed to the Google Groups "Halo General Discussion" group.
To post to this group, send email to halo...@googlegroups.com.
To unsubscribe from this group, send email to halo-php+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/halo-php?hl=en.