A helper object can be used almost identically to a list. Helpers
being able to 'render' themselves and including additional data (to
ensure compliance, etc) is just a bonus for rapid prototyping. If you
*depend* on rendering (and you need to hand that over to a design
person), then you are likely abusing them (just like including html in
your controller response is MVC abuse), but otherwise, there is
minimal difference.
I would seriously like to hear Massimo why he introduced HTML helpers.
I personally find them very useful, but I'm not certain we're all
talking about the same thing here with regard to MVC.
example controller:
return dict(listdata = (('col1', 'col2', 'col3'),('1','2','3'),
('4','5','6')), helperdata = TABLE(TR('col1', 'col2', 'col3'), TR
('1','2','3'), TR('4','5','6')))
example view (I know this can be written in a more compact manner, but
let's keep things simple for designers):
Oldschool:
<TABLE>
{{for row in listdata:}}
<TR>
{{for cell in row:}}
<TD>{{=cell}}</TD>
{{pass}}
</TR>
{{pass}}
</TABLE>
Rapid prototype (designers can also use CODE, BEAUTIFY, .xml(), etc):
{{=helperdata}}
Oldschool, but based on helper data:
<TABLE>
{{for row in helperdata.components:}}
<TR>
{{for cell in row:}}
{{for data in cell:}}
<TD>{{=data}}</TD>
{{pass}}
{{pass}}
</TR>
{{pass}}
</TABLE>
See ? It's the almost the same thing, helpers are just custom objects,
you can do with them as you please.
On Feb 18, 2:52 pm, carlo <[email protected]> wrote:
> everything is debatable: only side thing I can argue is that helpers
> are objects related to markup and I do not like them mingled with
> logic. But that's philosophy I agree.
>
> The main real point is that if you want to share your work with html
> designers, you can not use helpers at all. Your designer gives you
> markup and style: the more you have this separated from your logic the
> better integraton ease.
>
> carlo
>
> On 18 Feb, 01:58, AchipA <[email protected]> wrote:
>
> > One of the returning moments on this list is that when I say helpers
> > in controllers, people hear 'html in code'. The two have (almost)
> > nothing in common, even though it's possible to overuse/abuse helpers
> > (just as you can put html in strings in controllers - obviously bad).
> > Then again, maybe it's just me having an awkward POV on helpers :)
>
> > My main question is - why do people consider transferring only stock
> > variable/list/dictionary python objects to the views 'cleaner' than
> > transferring any other python object to it (helper objects, or even
> > your own) ? Helpers create *objects* which are just data wrappers.
> > They are *NOT* strings and have nothing in common with HTML until the
> > point they get rendered.
>
> > On Feb 18, 12:03 am, carlo <[email protected]> wrote:
>
> > > On 17 Feb, 23:39, AchipA <[email protected]> wrote:
>
> > > > web2py gives quite some latitude with regard to doing things... I
> > > > understand there are major no-nos, but is there a best way ? We had
>
> > > Sorry but I would be more narrow minded about this: from my point
> > > there *should* be never a good reason to put html in controllers: it
> > > makes code difficult to debug, to read and to share with designers.
> > > Isn't this one of the reasons for php and java servlets failure in the
> > > enterprise?
>
> > > carlo
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" 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/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
