Re: how (Tosca)Widgets fits into MVC concept
Thanks for feedback! New google groups interface seems not to have accepted my reaction from yesterday :( Just testing now... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: how (Tosca)Widgets fits into MVC concept
On Jan 25, 2007, at 12:42 PM, Ksenia wrote: On Jan 25, 11:31 am, Ksenia [EMAIL PROTECTED] wrote: Thanks for feedback! New google groups interface seems not to have accepted my reaction from yesterday :( Just testing now... (Ok, seems to work :) After reading al your helpfull reactions I see that my confusion with TG/TW widgets is more about it's implementation: - general widgets like TinyMCE, grids, js trees, select shuttle, etc. belong to the concept of helpers. I dont care how they made, where they are installed on the system - I just want to use them. So the egg system and TW are great for that. - domain-specific widgets, like product info, is something that I see as a template that should be in the products view directory. It makes more sense to me to see those widgets as clever templates with some extra python code in it. TW/TG widgets feels upside down for this use. Just the matter of taste I guess. Of course. It's up to you to decide which views are general enough to deserve encapsulation in a reusable component or could benefit from being clever templates (being clever meaning they know what static resources (js, css, images...) they need for rendering and pull them automatically when they're used in a page). But keep in mind, TW widgets are a superset of form widgets. Depends on your taste and style but widgets can be used for other things apart from validation (a js drop-down menu, for example). From a user's perspective they're just objects you can instantiate setting some initial state that affects how they behave and then be call them in a template to generate a chunk of markup. To sum up: they are equivalent of a template function but that can take care pulling static files and be encapsulated with all it's baggage into a reusable component. TW is just an API to create them, in fact, twForms ATM is more of a proof of concept which provides *very* basic widgets, they could be much enhanced with client-side scripting, styling, etc... Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: how (Tosca)Widgets fits into MVC concept
On 1/21/07, Ksenia [EMAIL PROTECTED] 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 :) Before we get too carried away, perhaps you'll enjoy this: http://jjinux.blogspot.com/2005/04/mvc-cargo-cult.html Happy Hacking! -jj -- http://jjinux.blogspot.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-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
how (Tosca)Widgets fits into MVC concept
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 :) Thanks! Ksenia. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: how (Tosca)Widgets fits into MVC concept
On 1/21/07, Ksenia [EMAIL PROTECTED] wrote:
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...
This always comes up with MVC: cases that don't clearly fit into any
of the categories. I have a search module in one (Quixote) project
that contains widgets, validators, searching code, etc, and I wanted
it all together in one module. I put it under 'controllers' at first,
then decided I wanted only true controllers there and moved it to the
top level alongside the 'controllers', 'model', and 'templates'
packages.
I haven't used ToscaWidgets, but assuming it's similar to Quixote
widgets, you can consider its rendering as a default rendering. In
other words, you don't have to use it if you have specialized layout
needs. In my organization, management gets these whims about how
exactly they want a widget to look like and where it should go, so I
make an initial template with semi-hardcoded widgets and give it to my
project manager to tweak. Widgets have five or six pieces of state
information:
- field name
- initial value (overridden by submitted value if we're
redisplaying the form)
- error message (empty if none)
- hint (e.g., Hyphens are optional, mm/dd/, This is the
number on your mailing label)
- options (for select widgets)
- required?
With Quixote widgets (which I've thought about porting to Pylons), it
would look like this:
tdMy Label: ${w.render_content()} ${w.error} ${w.hint}/td
.render_content takes care of all the other parts, rendering just the
input tag without the fancy div's that .render would put around
it. I set the CSS class and any custom HTML attributes in the widget
constructor, which is a bit of intrusion from the view, but only a
little bit.
Not sure about non-form widgets or subrequests. I would probably use
reusable template snippets for the former (#def methods in Cheetah),
and handle the latter in the controller. If the controller chooses a
different template than usual, it looks to the user like a completely
different page, so it has the same effect as a subrequest. In Pylons
the controller chooses and calls the template directly, but TurboGears
has this bit of syntactic sugar:
# TG example, syntax may be wrong.
@expose(default_template)
def foo(self):
if NO_DATA:
return {template: no_data_template}
return {key1: [DATA_RECORDS], key2, value2}
--
Mike Orr [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
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
-~--~~~~--~~--~--~---
