SitePoint Sponsor |
|
User Tag List
Results 76 to 100 of 384
-
Jul 12, 2005, 05:31 #76
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
PHP Code:interface IInputRule
{
/**
* Validate DataObject. Return true for success. Report errors to Logger.
* @param object DataObject
* @param object ILogger
* @return boolean is valid
*/
public function validate(DataObject $data, ILogger $logger);
}
class InputController implements IInputRule
{
(...)
}
class InputValidator implements IInputRule
{
(...)
}
Originally Posted by Overunner
For clarity, here's FlowController modified to my InputController:PHP Code:class FlowController implements IHandler
{
/**
* @var object IHandler
*/
protected $success = NULL;
/**
* @var object IHandler
*/
protected $failure = NULL;
/**
* @var object IInputRule
*/
protected $validator = NULL;
public function __construct(IHandler $success, IHandler $failure)
{
$this->success = $success;
$this->failure = $failure;
$this->validator = new InputController;
}
public function execute(Request $request, Response $response)
{
$logger = new Logger;
if ($this->validator->validate($request, $logger))
{
$this->success->execute($request, $response);
}
else
{
$this->request->set('errors', $logger->getMessages());
$this->failure->execute($request, $response);
}
}
public function addFilter($filter)
{
$this->validator->addFilter($filter);
}
public function addRule($rule)
{
$this->validator->addRule($rule);
}
}
I repeat, my InputController isn't a flow controller. If you want InputController to have those abilities - I don't - then you should rename mine and have your class use it: the input filtering and validation part definitely needs to be a in separate class. Actually I'd be glad to have suggestions for a new name, as the current one is admittedly confusing.
-
Jul 12, 2005, 06:42 #77
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Umm...
PHP Code:...
public function execute(Request $request, Response $response)
{
$logger = new Logger;
if ($this->validator->validate($request, $logger))
{
$this->success->execute($request, $response);
}
else
{
$this->request->set('errors', $logger->getMessages());
$this->failure->execute($request, $response);
}
}
...
So you can still continue to execute either success or failure... You don't then have the overhead of having to pass around the Request and Response objects no? ie
PHP Code:public function execute( $factory )
{
$logger = new Logger;
if ($this->validator->validate($request, $logger))
{
// what does success do? I see no class method for this 'success' ??
$this->factory->onSuccess();
}
else
{
$this->request->set('errors', $logger->getMessages());
$this->factory->onFailure();
}
}
-
Jul 12, 2005, 07:04 #78
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Dr Livingston
PHP Code:public function execute(Request $request, Response $response)
{
$this->request = $request;
$this->response = $response;
$logger = new Logger;
if ($this->validator->validate($request, $logger))
{
$this->factory->onSuccess();
}
else
{
$this->request->set('errors', $logger->getMessages());
$this->factory->onFailure();
}
}
Originally Posted by Dr Livingston
-
Jul 12, 2005, 07:11 #79
- Join Date
- Jul 2005
- Posts
- 194
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Any place where I can get the latest version of this project? I am using PHP 4.
-
Jul 12, 2005, 07:16 #80
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Dr Livingston > That would mean that FlowController was the only controller which didn't implement the IHandler interface. However, we might want to replace the execute(Request $request, Response $response) with execute(DataSpace $context) making $context a registry for request/response. The danger is that this may become a MagicContainer.
It would solve a problem I ran into, with the following line in FlowController :
PHP Code:$this->request->set('errors', $logger->getMessages());
Originally Posted by wdeboer
There is one version here and another one here
See my comparison of the two in post #75Last edited by kyberfabrikken; Jul 12, 2005 at 07:39. Reason: linked to #75
-
Jul 12, 2005, 07:28 #81
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
This, I feel, is important - what do others think about it?
-
Jul 12, 2005, 07:52 #82
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Ezku
PHP Code:class InputValidator
{
(...)
public function validate(DataObject $data, ILogger $logger)
{
$valid = TRUE;
foreach ($this->rules as $rule)
{
$valid = $rule->validate($data, $logger) && $valid;
}
return $valid;
}
}
Off Topic:
btw. I still think IRule is way cooler than IInputRule.
-
Jul 12, 2005, 07:52 #83
- Join Date
- Jul 2005
- Posts
- 194
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Yes, the Context object seems reasonable to have.
-
Jul 12, 2005, 08:12 #84
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
If rules and InputValidator are to share the same interface (IInputRule), the rules should also take a Logger as argument.
Off Topic:
-- IRule is way cooler than IInputRule., but at this stage we have to be a bit more specific in our naming conventions. Calling it IRule instead of IInputRule would mean we'd have a corresponding IFilter, which, you'll surely realize, just won't do. "Input" explicitly communicates what the interface is related to.
-
Jul 12, 2005, 08:47 #85
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
Christopher
-
Jul 12, 2005, 09:07 #86
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
I think the reason kyberfabrikken started using the Logger is because he wasn't involved in the the InputController code which itself is a Logger (the errors are held in each Parameter). My problem with the Logger is that it isn't a response to the question: how will the error strings be accessed and used? For example, a Form Controller wants to redisplay the values with associated error messages. It may also want to highlight the inputs with errors. The problem with the Logger as implemented is that we loose any association of the error to a specific parameter. You can add that to the Logger, but then you are back to the InputController (but without the other Parameter info all together in a Value Object).Christopher
-
Jul 12, 2005, 09:25 #87
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
-
Jul 12, 2005, 09:27 #88
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
There has never been any attempt at passing a logger to the Filter class btw.
Originally Posted by arborint
You seem to be making an assumption here that a rule applies to a single parameter btw, which isn't always true.
While we're at the details-part, it seems that DataSource vs. DataSpace is a tie with 2 vs. 2. I wouldn't rule out HashMap completely, and it could be a compromise. Does anybody have anything in particular against HashMap ?
Once we settle on the name, I would like to update the cvs (frontcontroller code) with a DataSpace/DataSource/HashMap and accordingly update Request, which has some serious issues in the current implementation.
Originally Posted by arborint
Originally Posted by Ezku
-
Jul 12, 2005, 10:23 #89
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
Originally Posted by kyberfabrikken
My point is that the error messages are already logged individually by each InputControllerParameter. Each InputControllerParameter is a Logger. That is where you want the error messages because they are associated with other parameter info like the value.
Originally Posted by kyberfabrikken
Originally Posted by kyberfabrikken
Christopher
-
Jul 12, 2005, 12:25 #90
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
About relating error messages to fields - we could have the Rule classes log an Error, that hosts conflicting field names and error messages. Simple and doable.
Would you mind posting the latest version of your approach?
-
Jul 12, 2005, 13:02 #91
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Ezku
It's funny, but clumsy is my reaction to the Logger. It takes organized information and dumps it into a single hopper. You are now proposing turning it into a DataSource by adding field information which is just copying the InputControllerParameter.Christopher
-
Jul 12, 2005, 13:54 #92
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
After Ezku had some work done on it, I really like the FlowController-design.
Originally Posted by arborint
Originally Posted by ezku
I have updated the code I posted earlier with ezku's suggestions, which makes it much cleaner, so I thought I would post it here for the sake of comparing it against the StateMachine design.
I have added a context-object in the same go, though I'm still a bit lukewarm about that. I have also made some changes to the Request-object, which had some serious issues. I'd like some feedback on that, since I'm quite happy with that and think it should go into the frontcontroller-package (skeleton-thread).
-
Jul 12, 2005, 14:55 #93
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
I really like the FlowController-design.
Even without the Logger-class I don't think it's a good idea to have seperate interfaces for the Rules and the Validator. Returning an array from Validator, but only a single message from the Rule is an interface mismatch.
I have added a context-object in the same go, though I'm still a bit lukewarm about that.
I have also made some changes to the Request-object, which had some serious issues. I'd like some feedback on that, since I'm quite happy with that and think it should go into the frontcontroller-package (skeleton-thread).PHP Code:function & getInstance() {
static $instance = Array();
if (count($instance) == 0) {
$instance[0] =& new Request();
}
return $instance[0];
}
PHP Code:function & getInstance() {
static $instance = NULL;
if (!isset($instance)) {
$instance =& new Request();
}
return $instance;
}
Originally Posted by arborint
-
Jul 12, 2005, 15:02 #94
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Ezku
Originally Posted by Ezku
So a POST and GET request aren't equal to each other. The POST extends the GET and adds something additional to it.
-
Jul 12, 2005, 15:31 #95
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Ezku
The FormController on the other hand is limited to a single form.
-
Jul 12, 2005, 15:38 #96
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
The thing is, that even if the method is POST, you may want to access the $_GET data. For example, the applicationcontroller may be concerned with the POST data, while the requestmapper is looking at the GET data.
Originally Posted by kyberfabrikken
-
Jul 12, 2005, 15:39 #97
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Ezku
Originally Posted by Ezku
Christopher
-
Jul 12, 2005, 15:44 #98
- Join Date
- Mar 2004
- Location
- Sweden
- Posts
- 180
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Kyber: Why have you applied the singleton pattern for the request class, and not for the response and errorLogger?
Ragarding the Input Controller, which is basically an request filter/validator (as it is now atleast)...in what parts of the framework should that class be used?
-
Jul 12, 2005, 16:00 #99
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Overunner
Ragarding the Input Controller, which is basically an request filter/validator (as it is now atleast)...in what parts of the framework should that class be used?
Perhaps we could have an ApplicationController that creates states and transitions by means of FlowController chaining. I'll look into it tomorrow.
-
Jul 12, 2005, 16:03 #100
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
Originally Posted by Overunner
Response and errorLogger aren't singletons. You could make local copies. Could be useful for composite views.
Originally Posted by arborint
Edit:
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.
I'm a bit in doubt whether the class should refer $_REQUEST or $_GET|$_POST (depending on method).
As of now - If you don't care if the params come from GET or POST, you can just use $request->get('param') (like you would use $_REQUEST without a Request-class). On the other hand if you're specifically interested in the POST-data, you can use $request->POST->get('param').
If we let the default getter select from $_GET|$_POST you don't have a I-dont-care-about-the-protocol way of getting a param.
Both designs would make sense, but I made it that way, because that's how native php works.
Bookmarks