|
|||||||
 |
|
|
Thread Tools |
|
#31
10-28-2009, 08:06 PM
|
|||
|
|||
Dan,
Whilst I think that the plugin you have created is superb. It does it's job very well indeed, however, I would like to stress a point - and I feel passionately strong about it. I think removing the template layer of the framework really destroys the doctrine of the framework. Returning a variable and not a template is not good practice. I would like to keep the presentation layer to format the data and then return that as an extdirect response, otherwise, all I will have is actions and no templates and of course that takes away the whole consistency of the framework and renders (no pun intended) sfPHPView useless and obselete. I don't like that the plugin is treating an action as two layers instead of one. And using partials, although it's a quick solution is not very good in the long run as it takes away alot of the functionality that the symfony framework has dedicated to ensuring a clean MVC design pattern. And to be honest, i'm a bit of a stickler for clean hierarchiral architecture design. Would you object to me adding an extra doc comment parameter of '@usetemplate' (or something similar) and then extending the result adapter to render the template content as the result instead of the 'result' variable? Of course, It is your plugin and I would very much appreciate your opinions, criticisms, objections etc. to what i've proposed. I thank you for the time you've put into the project. Jamie 
|
|
#32
10-29-2009, 03:08 AM
|
||||
|
||||
|
Hi Jamie,
Thank you for your comments. I want to start out with your claim that the current approach renders sfPhpView useless - you're correct (for Ext.Direct requests). But it's important to understand that in a web service application the "View Layer" is shifted to the client-side instead of relying on the server side. Thus, in the conext of Ext.Direct your understanding of an MVC framework has to change slightly. To be 100% accurate, there's still "technically" a server-side view layer, it's just that it's JSON-RPC instead of HTML - so including sfPhpView in dsExtDirectPlugin would actually require an MVVC framework.  Here's my explaination on why the plugin works the way it does: The Ext.Direct spec is a JSON-RPC implementation which is designed to return data to Ext components like the grid, tree, XTemplate, etc. This data is always going to be in array/hash/scalar format. That said, returning raw template data is an exception to the rule, at best - and in general not good practice. Moreover, getting the symfony templating layer involved in Ext.Direct requests would come at a performance cost that would negate the spirit of high-performance AJAX apps users have come to expect. And if dsExtDirect was modified to return full symfony templates, it would include the entire <html></html> document which would in turn cause unexpected behavior in Ext. That said, your request for full template support is not as clear-cut as it might seem. It's still perfectly acceptable to return HTML as a scalar in your response, but relying 100% on a templated view in an RPC context negates the point of using RPC in the first place and you should instead rely on a regular HTTP request. I hope that clears some things up for you. There's still plenty of room to be an MVC purist - it just works a little different for web services. . I'd be more than happy to hear more about what kind of application you're writing and offer some advice on the best way to go about it. I've written several large apps using Ext.Direct and I haven't come across an instance where getting symfony's template layer involved seemed like the best way to go. And I've never been tempted to mix view logic in the action layer - since the JSON rendering logic is handled by the plugin there's still good separation and the action layer does not have to serve a dual role.I appreciate you reading my perspectives and I welcome your thoughts. I'm committed to continually improving the plugin so your comments are very welcome. Cheers, Dan
|
|
#33
11-03-2009, 10:30 AM
|
||||
|
||||
|
How do we populate the "message" and "where" return results when a symfony action has errors or fails due to application logic, etc.? The return result looks something like {"type":"exception",...,"message":null,"where":null} - I can add my own json parameters, however, I'm wondering if there was a way to do this "natively". Thanks for the help!
|
|
#34
11-03-2009, 01:40 PM
|
||||
|
||||
|
Quote:
To generated errors you wish the client to see (ex: form validation errors, authentication errors, etc) I use the following response format: {
"type":"rpc",
"tid":2,
"action":"myAction",
"method":"myMethod",
"result":{
"success":false,
"message":"Operation failed.",
"data":[
]
}
}
Hope that helps. Cheers, Dan
|
|
#35
11-03-2009, 02:09 PM
|
||||
|
||||
|
Thats what I ended up doing anyways - was simply returning my own set of "results" and having the client handle them on the basis of "success" or not. Just wondering if there was some other more "native" way to do things, but as it seems, I was doing the same thing you're doing all along.
Working good so far. This + doctrine has shaved a lot of dev time off of things. I'm beginning to pump out components left and right.
|
|
«
Previous Thread
|
Next Thread
»
| Thread Tools | |
|
|
All times are GMT -5. The time now is 10:04 AM.
