On Jan 11, 2007, at 8:25 PM, Lee McFadden wrote:
On 1/11/07, Alberto Valverde [EMAIL PROTECTED] wrote:
It's a good idea, however, I would not bother too much with patching
the trunk with this ATM because (apart that you'll probably lose much
hair ;) decorators are going to be rewritten in
On 1/11/07, Lee McFadden [EMAIL PROTECTED] wrote:
On 1/11/07, Alberto Valverde [EMAIL PROTECTED] wrote:
If you want something extensible, create a function that does all the
heavy lifting and returns your data how you want it, then use an
exposed method to wrap it. That way you can use
On Jan 12, 2007, at 3:32 PM, Jorge Vargas wrote:
On 1/11/07, Tim Lesher [EMAIL PROTECTED] wrote:
On 1/11/07, Joseph Tate [EMAIL PROTECTED] wrote:
So, hanging out on #turbogears someone asked how you instantiate a
widget in a Genshi template. The resulting answer was You
instantiate
Tim Lesher wrote:
Unless I'm really misreading you, this is already the way most people
work with TG 1.0 and Kid. What is different in the Genshi case?
Yes, the only currently documented way to use Widgets is to instantiate
in the controller, but at least with kid you can move the
Alberto Valverde wrote:
I don't see why widgets violate MVC at all, they're just
encapsulating view logic after all.
If they're doing more than that, then the widget in question needs
redesign.
--~--~-~--~~~---~--~~
You received this message because you are
Lee McFadden wrote:
I *don't* think it's a good idea. Controllers are exposed for a
reason, they're supposed to be called by the web and at no point will
you want your exposed method to return python objects - the browser
will not know how to deal with it (and neither will cherrypy for that
On 1/12/07, Joseph Tate [EMAIL PROTECTED] wrote:
Alberto Valverde wrote:
I don't see why widgets violate MVC at all, they're just
encapsulating view logic after all.
yes that is why I said in a purist approach there is no such thing has
view logic but that in practice is irrelevant.
Joseph Tate wrote:
Lee McFadden wrote:
I *don't* think it's a good idea. Controllers are exposed for a
reason, they're supposed to be called by the web and at no point will
you want your exposed method to return python objects - the browser
will not know how to deal with it (and neither
Jorge Vargas wrote:
or it was just the fact that genshi currently doesn't has a ?python?
The fact that the widget would have to be instantiated and returned in
the controller (blurring the line between view and controller). I can
instantiate widgets in kid templates, which conforms to MVC.
On 1/12/07, Joseph Tate [EMAIL PROTECTED] wrote:
Jorge Vargas wrote:
or it was just the fact that genshi currently doesn't has a ?python?
The fact that the widget would have to be instantiated and returned in
the controller (blurring the line between view and controller). I can
On 1/12/07, Joseph Tate [EMAIL PROTECTED] wrote:
Jorge Vargas wrote:
or it was just the fact that genshi currently doesn't has a ?python?
The fact that the widget would have to be instantiated and returned in
the controller (blurring the line between view and controller). I can
On 1/12/07, Joseph Tate [EMAIL PROTECTED] wrote:
That's the paradigm that I have to have in my application. Almost
every method could be called via GET/POST, JSONRPC or XMLRPC, so the
default paradigm should not be changed so that you have to return
something not-marshalable by json/xmlrpc
Alberto Valverde wrote:
On Jan 11, 2007, at 3:55 PM, Robin Bryce wrote:
On 11/01/07, Alberto Valverde [EMAIL PROTECTED] wrote:
On Jan 11, 2007, at 1:17 PM, Robin Bryce wrote:
The obvious thing to do would be to patch
turbogears.view.base.load_engines, adding another genshi
variable to
On 1/12/07, Joseph Tate [EMAIL PROTECTED] wrote:
You're missing the point. This is not about what json can and can't
do, it's making the controller know about the output format for the
data. What if we come up with a new CSV output format? What if it's
RSS? What about XMLRPC? The point
Lee McFadden schrieb:
The above issue is one of the reasons I make sure none of my Widgets
require JS that can't be added to the template by hand - I instantiate
all my widgets outside of controllers and add them to the default
providers so they don't have to be passed by a controller for
This is ugly but appears to work (that is, it looks like the rest of the
config code):
def _load_engines():
if engines: return
from turbogears.util import get_project_config
this_project = os.path.basename(os.getcwd()) + '.'
cfg_file = get_project_config()
config_obj
16 matches
Mail list logo
