Halo update

[Beau D. Simensen]

Well, I take it back. I've started to work on updating Halo.

It is still a work in progress but the design is pretty similar to the
original. How views will be handled might change some. I'm currently
working on that. Configuring views (and their helpers) was a lot of
work before and I would like to find a way to allow for that level of
flexibility while also providing an easier and more straightforward
option as an alternative.

I will not update the Google Code Project until things are a bit
further along, but if anyone wants to follow the source check it out
on GitHub:

o http://github.com/dflydev/halo-php

Halo itself is a bit heavy for someone new to Halo. I'm also in the
process of building a reference application that can be used as a
starting point for a Halo based application. This will be similar to
the old examples/single project but so far it is already feeling far
more refined and easier to jump into. The idea here being that someone
can start building a web application right away without really knowing
or caring about Halo, much less Substrate.

[aek]

Hi Beau
I want to know if you consider my suggestion of new classes and
improvements, because right now I have working with a modified version
of some classes in halo and the news that I created. I ask because if
not are planned to be included I need to have a granularity of where
are the changes to adapt every release to my needs.

I will check the changes in halo and substrate.

[Beau D. Simensen]

Yes! I have definitely been paying attention to your feedback. For
instance, take a look at the Resource Locator View Resolver:

o http://github.com/dflydev/halo-php/blob/master/lib/halo_ResourceLocatorViewResolver.php

While not exactly the same implementation, it is very similar to your
halo_InternalResourceViewResolver. It uses a resource locator to
determine whether the view actually exists and then passes the full
path to the file to the view class. If the view file does not exist on
disk, it returns NULL which would allow for potentially another view
resolver to pick up the request.

One thing you'll notice is that with very few exceptions most
everything uses just standard require_once() to get code included. I
wrote some resource locators and class loaders for Substrate and I may
move them to their own project as it might be easier to follow what is
going on. A bring that up because the example I'm including below has
some references to Substrate resource locators.

All in all I've tried to keep things backwards compatible but as it is
currently a moving target I'm not actually paying 100% attention to
that. Once I've worked my way through the view handling stuff (I'm
getting close) I'll be able to focus on seeing what we can do to make
your projects work with the newer code with minimal effort. Where
possible I've actually been writing in deprecated methods and passing
through to the new method calls so that should ease the transition
some.


/**
* View resolver
*/
$context->add('lithe.viewResolver', array(
'className' => 'halo_ResourceLocatorViewResolver',
'constructorArgs' => array(
'resourceLocator' => $context-
>ref('lithe.views.resourceLocator'),
),
'properties' => array(
'viewClass' => '${lithe.views.default.class}',
'suffix' => '${lithe.views.default.suffix}',
'dependencyMap' => array(
'halo_SkittleView' => array(
'lithe.view.skittle.resourceLocator'
),
),
),
));

/**
* Resource locator to find views
*/
$context->add('lithe.views.resourceLocator', array(
'className' => 'substrate_PathResourceLocator',
'constructorArgs' => array(
'paths' => PROJECT_VIEWS_PATH,
),
));

/**
* Resource locator for Skittle view
*
* Used for sub views.
*/
$context->add('lithe.view.skittle.resourceLocator', array(
'className' => 'halo_skittle_SubstrateResourceLocatorAdapter',
'constructorArgs' => array(
'resourceLocator' => $context-
>ref('lithe.views.resourceLocator'),
),
));

[aek]

Im reviewing halo and I notice that there are some changes.

The method set in substrate-context has been deprecated in favor of
add. That's not a real problem for me but the method add implements
the same functionality of the method set. Why not keep with the method
set with the implementation of add?, what is the need of the new
method.

What is the role of the property dependencyMap in
halo_ResourceLocatorViewResolver?. Why halo_SkittleView find stones by
a hand-coded name in the context or the first stone that implements
skittle_IResourceLocator?. If resolve method of
halo_ResourceLocatorViewResolver, find the real path of the view, why
go to find the same path again in stringInc of skittle_Skittle?, maybe
it's outdated?.

Im glad to see a different implementation of method __construct in
halo_HttpRequest that can feet more with my needs, I will see what
happens when update all the frameworks to their current versions.

Check the use of regular expression in url handler mappings, I use
Apache Ant regular expression, but other user can use another style.
In my case is useful for the MultiActionController, I recommend you to
include it. It's a powerful feature. I will find a way to upload a
complete example of what I am doing with your frameworks, you'll glad.
Currently I don't have a way to upload anything to any site or public
repository due to the proxies of the Internet connection at work. My
project hole-security (Spring Security port to PHP, in the first
version for halo-php) don't know the light yet due to the same problem.

[Beau Simensen]

The method set in substrate-context has been deprecated in favor of add. That's not a real problem for me but the method add implements the same functionality of the method set. Why not keep with the method set with the implementation of add?, what is the need of the new method.

We could keep both set() and add() and just remove the deprecated flag on set(). I'll think on this more. After looking at the contexts it started to feel to me like you are adding stones to the context, not setting them. This is particularly true in the case of anonymous stones.

For instance, this feels more natural to me:

  $context->add(array('className'=>'SomeRandomResolver'));

... than calling set...

  $context->set(array('className'=>'SomeRandomResolver'));

But I am flexible on this.

What is the role of the property dependencyMap in halo_ResourceLocatorViewResolver?. Why halo_SkittleView find stones by a hand-coded name in the context or the first stone that implements skittle_IResourceLocator?.

I am still struggling with this, to be honest. The handoff from the dispatcher to the view class is kinda rough as there is very little context that can be passed and the view classes are currently instantiated directly and not loaded through a Substrate context. I have a similar issue with the View Helpers...

halo_SkittleView does actually search the context for all stones that implement skittle_IResourceLocator, but they have to be instantiated first. I was experimenting with a configuration that would allow for switching the view rendering technology by configuration (i.e., could set lithe.views.default.class to "halo_SmartyView" or something).

This is where the (experimental) dependency map came into play. Depending on which class is loaded it might want to trigger some additional stones to be loaded.

I could have accomplished something similar with turning lazyLoad to false for lithe.view.skittle.resourceLocator but then it would be loaded in all cases, even if Skittle view class was not used. (i.e., smarty was setup instead) Unfortunately in PHP land we cannot afford to fire up all stones to see what interfaces they implement.

This dependency map was designed to basically say, "if this view class is used, make sure to load the following stones to support it."

This is all a work in progress. :) It might change.

If resolve method of halo_ResourceLocatorViewResolver, find the real path of the view, why go to find the same path again in stringInc of skittle_Skittle?, maybe it's outdated?

Good question!

The resource locator view resolver first checks to see if the view actually exists. This gives other view resolvers the chance to accept it if the view does not actually exist on disk. I'm not sure how useful this is, but it is similar to how url handler mappings work.

Skittle can't know for certain that whatever is passed to it actually exists so it checks on its own. Resource locator view resolver should be passing in a full path that it knows exists, so the resource locator should be smart enough to check if it exists first and return the input path immediately in that case. This should not be another search path hit.

The bigger reason for getting this resolver to Skittle is that it needs to be able to locate files for sub views. For instance, "product/category" view might resolve to "product/category.php" and resource locator would find product/category.php at /path/to/WEB-INF/product/cateogry.php. If home.php has an include like <? $s->inc('common/box.php'); ?> it should load common/box.php from /path/to/WEB-INF/common/box.php. Without some context ( like the resource locator that found the original product/category.php view ) this would be extremely difficult for Skittle.

I'm still not sure this is the best way to do it but I'm still working on it. :)

And again, this is all a work in progress. Especially the view stuff. I'm pretty close to it right now so your feedback is hugely helpful in keeping things in perspective. :)

--

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.

[Beau Simensen]

I need to look more closely at your Multi Action Controller but at this point I think I can work on getting it included.

From the looks of it I think I have done something similar in Lithe. I'd probably be more likely to use your implementation than the Lithe implementation for Halo, though, since yours makes a lot less assumptions about how the thing will be used.

http://github.com/dflydev/lithe-php/blob/master/lib/lithe_DefaultHandlerMapping.php

 * Assuming URI is /account/admin/5/sorted

 * Determines controller to be 'account'

 * Determines method to be 'admin'

 * Determines arguments are array(5, 'sorted')

 * First looks to see if 'accountController' stone exists, uses that for controller if found

 * Second looks to see if 'AccountController.php' resource exists, instantiates one if found

 * If controller stone exists or controller class instance is instantiated, sets method name param and arguments on request

Rather than building an implementation of halo_IController I opted to create lithe_IController (empty) and put the logic of determining which method to call in the hands of lithe_ControllerHandlerAdapter. (there is a bug in that generateHaloModelAndView is expected but not actually defined in any interface :) )

http://github.com/dflydev/lithe-php/blob/master/lib/lithe_ControllerHandlerAdapter.php

It is still experimental and I'm not sure I'm 100% sold on it. I'm at a point where I need to start allowing for configuration of paths ( i.e., something other than /controller/method/arg/list ) so it would be a good time to look into what you contributed for the path matching via ant style patterns.

First major goal for Lithe is to make basic web application that someone can start using with very little knowledge of Substrate or Halo. I want it to be as simple as "Create YourController.php, put it in this specific directory, and start making requests to /your/method" and it should "just work."

Second major goal for Lithe is to keep all of the flexibility of Substrate and Halo available so people can expand on it once they get comfortable working in the environment.

--

Beau D. Simensen


Dragonfly Development Inc
http://dflydev.com/

[aek]

Some topics of how to work in PHP frameworks still are unknown to me.
One could be the performance cost of the deprecated or duplicated
functionalities to be backward compatible, due to the need to load all
the nesessary classes for every request. I think that there is no much
difference between loading a class than loading the same class with a
few more methods, but Im not sure at all. Maybe it's something to
watch closely for a Web framework. The add method feels good just like
the former set, but if both do the same maybe the set method can
dissapear.

I have others points about Views and ViewResolvers. The normal flow
for rendering view that I know is:
1- Each ViewResolver is asked about if can resolve the viewName. Here
a Resource Bundle ViewResolver can say 'No', or an Stone Based View
Resolver.
2- If one ViewResolver can resolve the view name, he must proceed to
use a View Class to render the view. If the View Class is template
based, it need to find the real path for the template to make it
simply for the view class, if the template no exist, he could said
'No' as response to if he can resolve a view or raise an exception
3- The View Class only need to load the template if it's a template
based View Class and render the model.

Another feature that in my opinion the View Class need to handle is
errors of variable not found in model, to simply do nothing without
raise an error. If the variable is found but not contain a property or
a method especified in the view file, then an error must be raised to
inform about that malformed query to the variable in the model. This
avoid the abuse of 'if' and 'isset' in views to know if a variable is
found in the model or not.

What about lithe, it's halo or a frontend to halo. Why a sepparated
project, the functionalities of lithe couldn't live on halo project
without be an external project that need to maintain?.

About Url Patterns
I modified a little halo_SimpleUrlHandlerMappings to check if the url
is not found directly unsure that the url mapped did not match as a
pattern of the url.

[Beau Simensen]

2- If one ViewResolver can resolve the view name, he must proceed to use a View Class to render the view. If the View Class is template based, it need to find the real path for the template to make it simply for the view class, if the template no exist, he could said 'No' as response to if he can resolve a view or raise an exception

3- The View Class only need to load the template if it's a template based View Class and render the model.

Yes, in the case of 2) this is more or less what is happening. The problem comes into 3), at least for Skittle, since Skittle is capable of loading sub views. I need to find a way to configure Skittle's resource locator for its own internal use *after* it has been given the full path to the initial template by the ViewResolver.

I think I have enough feedback from you on the fact that this isn't really a nice solution in your opinion. And I pretty much agree. It was experimental but it worked at least to get me to where I am now but I knew I wanted to find a better solution.

I think that I am going to try and experiment with a view factory, maybe as an alternative to viewClass? i.e., for a simple view 'viewClass' => 'someViewClass' might work, but 'viewFactory' => $context->ref('mySkittleViewFatory').

if ( $this->viewClass ) {

    return new $this->viewClass($viewName, $viewUri);

} elseif ( $this->viewFactory ) {

    $viewFactory = $context->get($this->viewFactory);

    // halo_IViewFactory should have create($viewName, $viewUri) with @return halo_IView

    return $viewFactory->create($viewName, $viewUri);

}

This way I could create halo_SkittleViewFactory and configure it like:

$context->add('mySkittleViewFactory', array(

    'className' => 'halo_SkittleViewFactory',

    'constructorArgs' => array(

        'resourceLocator' => $context->ref('myViewResourceLocator'),

    ),

));

What about lithe, it's halo or a frontend to halo. Why a sepparated project, the functionalities of lithe couldn't live on halo project without be an external project that need to maintain?.

Many people in PHP land have never used anything like Substrate or Halo. Of all of the people who have downloaded both (I'd say there have been 200-500 downloads) there have been only two or three people who ever even asked me questions about them. You're the only person (to the best of my knowledge) who really understood it (or knew what to look for) to try and make it work.

Someone like you can use Halo as it is in your own project. And you probably like that a lot. You sort of took the basic example of a single site and ran with it. Tweaked it to make it look like you wanted because you dug into the code and had previous knowledge of some of the things I modeled this after.

The things I intend to do in Lithe would potentially not be things that would work well for your specific project(s). Many things turned on by default, preconfigured, things in specific places... For instance, I know you initially wanted your projects to be structured with resources in WEB-INF/, etc. I may want to nudge people in the direction of using Repose for ORM. Maybe another lite data access layer as well for hand coding SQL queries. These things are not appropriate, in my opinion, to be included in Halo itself.

One of the big strengths I see in both Substrate and Halo is that unlike almost ever other web framework in PHP land they are very open to allow the developer to do whatever they want, however they want. As long as you like to work in IoC/DI type containers and work in interfaces, that is. I think people would like it eventually, but it is not easy to jump into. People in PHP land generally don't like getting a /lib/ folder full of halo_* libraries... what are they going to do with that?

That is where Lithe would come in. It would come with Substrate and Halo, of course, but tucked away in a vendors folder. The main code ( lib/, controllers/, views/, etc. ) would all be standardized and mostly empty. It would all be based on a Substrate context but that would not be really very important to anyone using Lithe just as a simple web application framework. However, once they move behind the default Lithe configuration (like they want to do something super specific), they'd be able to leverage the fact that they can create their own handler mappings, view resolvers, handler adapters, etc., not to mention all of the benefits of the IoC/DI container.

So yeah, Lithe is really just a reference implementation of a webapp written around Halo. A starting point/example. Since there are going to be some hardcoded things that will make the overall application less flexible (at least out of the box) I want to keep it separate from Halo.

I'm showing you some Lithe things now because there are examples that fit some of what we're talking about. Where it makes sense, stuff I've done for Lithe may be put into Halo itself. But only if it is considered generic enough and doesn't impose any specific design principles on users of Halo.

Does that make more sense?

I hope to have Lithe "Single Site" implementation completed soon. I'll share that when it is done.

Thanks again for all of your feedback. I really do appreciate it!

--

Beau D. Simensen


Dragonfly Development Inc
http://dflydev.com/

[aek]

Well, lithe is something like what I am doing. I will update all of
your frameworks, and make the necessary changes to send to you by
email, the work with your frameworks in my software architecture in
PHP. I just waiting for the next changes to rebuilding, advice me when
there is an release candidate of each of them, or make a release in
every project site to know with what version I am working. I will
continue the develop of the security framework to show you together
with the architecture.

[Beau Simensen]

I feel like I'm getting close to a point where I can create a new release for Substrate and Halo. I want to make sure I have met some of your basic requirements where possible. So far I have been working on your Internal Resource View Resolver (might rename it to Internal Resource Uri View Resolver) and I plan to work on the Multi Action Controller. Are there other major things you see needing to happen to Halo core that would make your life easier? I think there was something about a URI Mapping that was Ant path based?

If you could post your current solutions for any of these things on Gist and send link to the group I can start looking at those and seeing how they fit in.

Did you do much with View Helpers? I haven't started to touch those yet and to be honest I'm a little worried about them. :) I was never particularly happy with the previous implementation so I'm not sure how far out those will be. If you've been using them as-is, I'll need to probably just start with the current implementation and then change it later rather than trying to work out a better solution before releasing everything. 

--

Beau D. Simensen


Dragonfly Development Inc
http://dflydev.com/

[aek]

I don't use view helpers at all, I don't see how this could be useful.
Maybe for resolve an internationalized message or theme support.
Here is the change for halo_SimpleUrlHandlerMapping to add the support
for a pathMatcher strategy.
http://gist.github.com/632647

Implemented halo_AntPathMatcher at
http://gist.github.com/632545

[Beau Simensen]

Initially Skittle was a huge project with a lot of things built into it. With Halo I wanted to be able to provide some of these features to other views (Smarty, etc.) and not focus strictly on Skittle. Especially for things like the URI view helper.

So you do not use any view helpers in your projects? Not even the URI view helper? How do you generate URI from page to page in your views? I'd love to see what you're using there.

I actually like to be able to build tools to help doing some tasks inside of views. I know many people like to keep logic completely out of the view layer, but I find that to be pretty restricting. Actual application logic? Not in the view. Something to help manage Javascript dependencies that only the view layer knows about? I think that someone should definitely be able to write code in that case.

Anyway, view helpers are not a requirement in Halo so it is not critical. I finished my implementation on it lat night and I'm going to let it sit for a bit to see how it feels in another few days. The current solution required only one line to be added in halo_Dispatcher so it is pretty unobtrusive.

 o http://github.com/dflydev/halo-php/commit/5c153a02b85fc852a545a51ba2f5020e36625d9b#diff-0

--

Beau D. Simensen


Dragonfly Development Inc
http://dflydev.com/

--

[aek]

> So you do not use any view helpers in your projects? Not even the URI view
> helper? How do you generate URI from page to page in your views? I'd love to
> see what you're using there.

I don't know much yet about view helpers, maybe I can use URI view
helper to omit the front controller part of the relative url. My front
Controller is the ArcheType.php that you saw in the gist
Example of my Urls:
../ArcheType/common/listUser.htm
../ArcheType/common/listAction.htm

[Beau Simensen]

So in your HTML you would do something like <a href="../ArcheType/common/listUser.htm">User List</a> ?

I migrated away from the idea of View Helpers to simply Helpers since some of these things might be useful in more than just views. I'm sure you've seen this before (if you looked at old example setup), but this is a really simple example of how to use the current URI helper in a view:

http://gist.github.com/632927

It can be super useful for creating complex URI. It is backed by a dd_configuration_IConfiguration so you can do complex things like link between sites. For instance, a pattern I use is to have admin site, website, maybe a site specifically for feed, etc. Can easily create a link to another site like:

<?php print $uri->getSite('feed', 'atom.xml'); ?>

<?php print $uri->getSite('static', 'css/main.css'); ?>

Depending on how URI properties file is configured, it would know how to construct full URL to feed ( maybe feed.myproject.com in production but mymachine.localdomain/projects/myproject/sites/feed/docroot/ in development ).

I also use this for a static content site as well (for css, js, static image assets). All static content can live at static.myproject.com ( which in production might be a CloudFront distribution ) but in dev it might be mapped to mymachine.localdomain/projects/myproject/sites/static/docroot

--

Beau D. Simensen


Dragonfly Development Inc
http://dflydev.com/

--

[aek]

I use ExtJS so I use relative url in my views, so there is no need of
a dinamic url. The parameters are setted in ExtJS way. The only issue
that I notice is that I need to prefix the url with the front
controller script and there is no validation about if some code can be
run in the template without error, something like if exist a variable
will use to if not nothing happens, somthing like:

<?php echo $command->getName();?>

if $command not exist nothing happens, if exist and have a method
getName will be called, if not an error will be raised