The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

It springs to my mind that if the Request-class does strip slashes, it actually should be a singleton, to prevent stripping from happening twice.

Just include it as a procedural snippet at the bottom of the file which you put the Request class in. It will only ever be run once, because if you try to include the file twice, you will get "Request class already defined" errors.

I have added a context-object in the same go, though I'm still a bit lukewarm about that.

I just had the idea - wouldn't it make sense to put the errorlogger in the Response-object ? In that case, we don't need the Context-object.
(Well, actually I was reading the wact sources, and they do this.)

Originally Posted by Ezku

Suddenly, my sarcasm-scanner activated, emitting a faint *blip*.

Actually I weren't. I can't think of a situation where you would need that option. Except maybe that we could use it to apply some lazy-loading.

The trick is that if you pass the Delegate a Handle object, the actual class can be lazy-loaded nicely upon triggering the event. Don't know if this is cool or YAGNI, but I couldn't resist when you brought it up.

Considering lazy loading; WACT had this nice idea of triggering events to invoke Delegates that wrap an object. (...) The trick is that if you pass the Delegate a Handle object, the actual class can be lazy-loaded nicely upon triggering the event. Don't know if this is cool or YAGNI, but I couldn't resist when you brought it up.

I think it's both cool and YAGNI. Form a FormController, the overhead of creating a few Handlers, that aren't going to execute is dimminishingly small. I actually think it would add up to introducing a lazy-load mechanism. I believe we came to the same conclusion about RequestMappers in the frontcontroller package.

Originally Posted by Ezku

I believe I've already expressed my wish to rename the InputController. Sanitizer won't quite do, but I'd be glad to have further suggestions!

I agree that it should be renamed. It's the only class named Controller, which doesn't implement IHandler. I'm not keen on InputSanitizer. Perhaps InputProcessor ?

I agree that it should be renamed. It's the only class named Controller, which doesn't implement IHandler. I'm not keen on InputSanitizer. Perhaps InputProcessor ?

That's a good suggestion.

Regarding Context: wouldn't it be a nice place to store Session objects and the like? I was about to start stuffing Session, Cookie etc. to the Request when I realized that Context would probably be where they really belong. Context could also be used as a messaging service between layers (along the lines of $context->data->set('errors', $logger->getMessages());). It would prevent cluttering both Request and Response. Is this A Bad Idea (TM)?

I know how to manipulate xml with php. It's not the problem.
But I don't know exactly how and where to add my code without breaking the MVC approach.
I imagine a class which will retrieve xml data with specifics methods and will call "$this->addRule(...)"

What do you think about that ?

That's a good idea. There were a brief suggestion by me and ezku to create a factory-class which would do something like this. We just haven't come to that yet.
I reckon we could rely on the ConfigReader classes from the skeleton-thread.

Originally Posted by tharos

And now when the form is submitted, how to save fields values into a database. Same probleme here
I don't see how and where to integrate my classes with yours. How to make these links.

Basically, you would want to substitute the ServerPage("page/formdone.php") with an Action that handles the submit. It could be along the lines of :

Regarding Context: wouldn't it be a nice place to store Session objects and the like? I was about to start stuffing Session, Cookie etc. to the Request when I realized that Context would probably be where they really belong.

Yes and no. I'm a bit afraid of the context-object as I mentioned earlier. Session stuff definately doesn't belong in the request object IMHO. I like to see session as sort of persistence and thus clearly belonging to the Model-layer. Cookies might belong in the Request-object - I'm not sure about that.

Originally Posted by Ezku

Context could also be used as a messaging service between layers (along the lines of $context->data->set('errors', $logger->getMessages()).

Yes, but I think this is where we get very close to MagicContainer. I'd rather have that Controllers use the Model-layer to communicate with each-other if they need to.

I won't rule out a Context as a ServiceLocator alltogether, but I'd rather wait to implement it when we actually need it. And I don't think we do quite yet.

flowcontroller0.4.zip
Here's a minor update to the code, which removes the context-object again, and places the errorLogger in the respose-object.
I also renamed InputController to InputProcessor as agreed.
I have updated tests and added a test for DataSpace. Still need to port the tests for rules (if we decide to stay with the Logger ...)
Lastly I added magic-fix back to the Request code in the way that DougBTX suggested (copy&paste from WACT)

About the naming. Since InputController have been renamed to InputProcessor, maybe we should rename FlowController to InputController ? Would that make sense ?

I think it's both cool and YAGNI. Form a FormController, the overhead of creating a few Handlers, that aren't going to execute is dimminishingly small. I actually think it would add up to introducing a lazy-load mechanism.

This is less a reply to kyberfabrikken, who's probably seen WACT stuff before, if only by way of explanations in Selkirk's posts. Newer readers may have a greater interest.

With WACT, it gets better than that. The handlers inside delegates need not be instantiated objects, but so-called 'Handles'. If the particular Delegate wrapping that Handle is invoked, the Handle is instantiated as the handler object.

Yes, but I think this is where we get very close to MagicContainer. I'd rather have that Controllers use the Model-layer to communicate with each-other if they need to.

I won't rule out a Context as a ServiceLocator alltogether, but I'd rather wait to implement it when we actually need it. And I don't think we do quite yet.

The Context could be implemented in a more strict manner, providing getters and setters for pre-defined specific objects (Request, Response, Messages, User, Session, etc), not just any key/value pair. In that case, a MagicContainer would not be a bad place to start; let it eat everything and later on, when things clear up (what can and what can't be in it), one could (and should) refactor it to a more strict context class.

The Context could be implemented in a more strict manner, providing getters and setters for pre-defined specific objects (Request, Response, Messages, User, Session, etc), not just any key/value pair. In that case, a MagicContainer would not be a bad place to start; let it eat everything and later on, when things clear up (what can and what can't be in it), one could (and should) refactor it to a more strict context class.

I wouldn't object (no pun intended) to that. The fact is we do have quite a load of objects to be passed around in the Handlers. They can't all go in Request/Response.

auricle: My thoughts exactly. As for my relating code above, I was just guessing based on the description at WACT. It's probably quite different in reality.

The fact is we do have quite a load of objects to be passed around in the Handlers. They can't all go in Request/Response.

They could go into the request, they do in rails. The logic of such an approach depends on how you want to define the term "request"; the narrow definition would include only what's in the POST, GET and the URI itself, a broader definition would include Cookies, Sessions, etc. A possiblity would be to rename the object to something more inclusive, like Context, and within it place the Request, Cookies, Sessions, etc.. passing it around in the handlers.

Or do you mean passing around Context and Response, as opposed to just Context? What's the point in that?

There's some sort of logic in Context=>input and Response=>output.

The thing which I don't like about having a Context-object is that it makes it harder for newcomers to understand the codebase. The benefits of such a container lies in the scalability of the system, but it's at the price of simplicity. Depending on the system you are building with it this may be good or bad.

How about an InputContext with an OutputContext? InputContext with, say, Request and Session and OutputContext with Response, Logger and whatnot. If you browsed the linked article, there's talk about separating the Context object into bits like this. I think it'd be pretty logical, but does that pose the same problem with understandability? I'd concern that pretty minuscule however. Does it radically differ from having the necessary stuff embedded in Request/Response?

The thing which I don't like about having a Context-object is that it makes it harder for newcomers to understand the codebase. The benefits of such a container lies in the scalability of the system, but it's at the price of simplicity. Depending on the system you are building with it this may be good or bad.

To be honest, I don't think that's much of an issue, considering there are other parts of the codebase that are much more complex. It seems to me that the main goal so far has been flexibility, rather than simplicity...

That could work, and it would provide a place for logging and errors, as you mention.

Now we're just changing the names aren't we ? I mean ... Context implies a global span, which would include both input and output. If we are having seperate objects for in/out, why not keep the names Request/Response ?
I'd want to have either one Context object or a Request + a Response.

Originally Posted by Ezku

Assuming I refactor my code to Context+Response, where do Logger or the error messages go?

Now we're just changing the names aren't we ? I mean ... Context implies a global span, which would include both input and output. If we are having seperate objects for in/out, why not keep the names Request/Response ?

Alright, how about if the current Request and Response would be stored at $request->http and $response->http respectively? There's a nice logic and it allows for a clean context object.

/**
* Get Logger. If one doesn't exist, a basic Logger will be created by the given name and returned.
* @param string Logger name
*/
public function & __get($key)
{
if(!isset($this->logs[$key]))
{
$this->logs[$key] = new Logger;
}
return $this->logs[$key];
}
}

Changed Request to HttpRequest and put it in a new Request-context, the same for Response. Created a LogManager as a place to store Loggers, put it in Response.

While I can't really conjure up rational arguments, I'm still not keen on changing the signature of IHandler->execute()
Regarding you latest post, I think the LogManager may be overkill. Why would we need multiple logs ?

If we are going to pass all sort of stuff (such as $_FILES, $_SERVER and LogManager) around, I'd prefer a single ServiceLocator (Context) rather than split it into two. For example, the Loggers are output to some scripts, but input to others, which makes them odd to put in the right spot. (Though Response is possible better than Request)

Maybe we could give it a rest and bring it back up in a while ?

I'd be much more interested in peeking into a form-factory class as the one tharos was calling for. For a start, I suppose that we could just extend the FormController class ?