On Jan 21, 2007, at 1:04 PM, Ksenia wrote:
> > Hi, > > I am playing with Pylons several weeks now and it's been a big joy to > use. Everything just fits together and I think because of Pylons I > finally start to get what MVC is all about and see the advantage of > clear separation. > The piece that I am not sure where it should go, are widgets. The DRY > is great, boring error handling is great, but: AFAIK the validation > belons to the Model, but the UI belongs in the View, and the "gluing" > of M with V belongs to Controller. So the widgets go right through all > of the layers... Ok, I can live with that :) But than there is not > anymore "only one way to do it". Where ends widget and starts the page > template? Is it just form rendering? No, grid with records can also be > a widget.... or should I just render it in the template file? Should I > only make into a widget something that I want to reuse? I saw the > thread about portlet-style site > (http://groups.google.com/group/pylons-discuss/browse_frm/thread/ > 2a52b3a490f5d211). > Wow, I can even use subrequests. Than I don't need widgets at all - I > can just collect all those /doc/view/123, /news/latest, /user/list, > /user/view/myid into one page. But on the other hand, I can make > all of > them into child_widgets and create one big page widget to display > them... > > I wonder what other think about widgets in relation to MVC in general > and Pylons in particular :) Hi Ksenia, (Tosca)Widgets should belong in the view layer of MVC. If a particular widget is doing much more than that they're probably better refactored. While it's true that some logic is being done in TW's "update_params", that logic should be limited to massage the parameters passed to "display" in every request and those parameters fixed at construction time so they're easier to handle in the template (to remove as much logic as possible from the template). TW aims to provide a way to create encapsulated UI components. You should be able to pack into an EGG all glue code, client-side scripting and graphic elements which compose a single UI element. One good semi-complex example of this is twTinyMCE. But TW is not only about form elements. I use them to create "views" for my model's objects. Using a generic function I monkey-patch my model classes with a display_for method so when, for example, I pass a list of e-shop products to a template, I do something like <py:for each="product in products"> <div py:content="product.display_for(action='summary_view')"> Product's summary </div> </py:for> If I ever need to show a products summary in another place, for example, the main pages' sidebar, then I can reuse the little widget that displays a single product. I do the same for action = "edit" to show a form to edit a single product in a bigger page when javascript is not available or send it in a single response to edit a product in an overlay when javascript is available. That particular chunk of markup also carries along it's needed JS code and CSS so I don't need to bother about including it (in the right order along with it's dependencies) in every page template that needs it. Form widgets are a little bit different in the sense that they also take care of coercing and validating input so they must have some knowledge about the model. This mixing of responsibilities is there mainly to reduce boiler-plate code and for DRYness, that way all information needed to build a form can be kept in a single Form subclass (or a module) and defined in a declarative way. There are ways to decouple the model and widgets too, for example, TG's FastData uses a generic function to create FormField widgets on demand for SO or SA mapped classes. That way you can keep all model related information in the model (including validators). For example, twTinyMCE encapsulates all the js code needed by the client-side code, it's css, and the glue code to provide a nice interface between python and js. Once installed and TW properly configured, every page that includes a form with a TinyMCE will automatically "pull" all required static resources (served by TW's middleware, one thing less to worry about...). twTinyMCE is a good example to see the advantage because you can have as many apps as you want in the same server that need a TinyMCE and only install it once (along with it's 1M of js code) To sum app, TWidgets are about: 1) creating reusable "V" components, 2) reducing boiler-plate 3) reducing boiler-plate ;) Alberto --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
