On Mon, Jun 21, 2010 at 11:43 AM, Eugueny Kontsevoy <eugu...@gmail.com> wrote: > ``request.params`` is a dict. FormEncode has a converter to transform >> >> a flat HTML namespace into nested dicts with sub-dicts and sub-lists. >> What else do "neat dictionaries" need? > > That conversion works fine. And that could be a part of core html helpers. > What I would really like to borrow from Rails is the concept of models being > in charge of their own data validation. Is it a good move in theory? Perhaps > not. But after 3 years of Rails I am certain it works great in practice. > > Rails achieves that by tightly coupling their views and models. Pylons is > more modular so that door's closed and it's fine. I, for one, can't come up > with anything smarter than FormEncode to have both validators + decoupled > views/models. And I still do all my validation manually in my models, i.e. > my form classes are just a boilerplate shim which connects model-based data > validation with HTML form parsing/generation. If I had more time to hack for > fun, I would definitely be looking at getting rid of them.
Keep in mind that some of us (me) have never used Rails, so we don't know offhand how it differs from Pylons. There are several interpretations of MVC for the web. MVC was created in a very different context, and its creators have not endorsed any particular interpretation of how it should apply to the web, so all interpretations are equally valid. Pylons assumes the model knows only itself, the controller knows all, and the view (template) knows only what the controller tells it (via 'c'). --Although some users allow the template to look directly in the model for quasi-constants (lookup tables). In other MVC systems, the view instantiates the model. Or the controller passes a model to the view. So pretty much everything is up for grabs. The one thing everybody agrees on is that business logic should be separate from the UI, and framework-specific code should be separate from framework-independent code. Pylons realizes this as: * model = business objects & logic * controller = framework logic * view = UI There are some rough edges. Pylons equates the view with the template, which leaves no place for view logic -- it has to go into either the template or the controller (usually depending on how complex the Python code is). So where do input data and validators fit in? I'd argue that the whole HTML"params" format is part of the UI, and therefore the validators are too. The model should deal only with its native data types -- because you should be able to port the model to a GUI or other non-web UI, where HTML validators would be out of place. But it would be silly to put validators in templates, because Python modules are much easier to debug than templates when Python code raises an exception. That means the best place to invoke validators is in the controllers. The validators themselves can be defined under 'lib' or in their own subpackage under the application level. -- Mike Orr <sluggos...@gmail.com> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
